前言
在做前后端分离时，第一个关注到的问题就是 渲染，也就是 View 这个层面的工作。
在传统的开发模式中，浏览器端与服务器端是由不同的前后端两个团队开发，但是模版却又在这两者中间的模糊地带。因此模版上面总不可避免的越来越多复杂逻辑，最终难以维护。
本文
渲染这块工作，对于前端开发者的日常工作来说，佔了非常大的比例，也是最容易与后端开发纠结不清的地方。
回首过去前端技术发展的这几年， *View *这个层面的工作，经过了许多次的变革，像是：
- Form Submit 全页刷新 => AJAX局部刷新
- 服务端续染 + MVC => 客户端渲染 + MVC
- 传统换页跳转 => 单页面应用
可以观察到在这几年，大家都倾向将 渲染 这件事，从服务器端端移向了浏览器端。
而服务器端则专注于 服务化 ，提供数据接口。
浏览器端渲染的好处
浏览器端渲染的好处，我们都很清楚，像是
- 摆脱业务逻辑与呈现逻辑在Java模版引擎中的耦合与混乱。
- 针对多终端应用，更容易以接口化的形式。在浏览器端搭配不同的模版，呈现不同的应用。
- 页面呈现本来就不仅是html，在前端的渲染可以更轻易的以组件化形式 (html + js + css)提供功能，使得前端组件不需依赖于服务端产生的html结构。
- 脱离对于后端开发、发佈流程的依赖。
- 方便联调。
浏览器端渲染造成的坏处
但是在享受好处的同时，我们同样的也面临了 浏览器端渲染 所带来的坏处，像是：
- 模版分离在不同的库。有的模版放在服务端 (JAVA)，而有的放在浏览器端 (JS)。前后端模版语言不相通。
- 需要等待所有模版与组件在浏览器端载入完成后才能开始渲染，无法即开即看。
- 首次进入会有白屏等待渲染的时间，不利于用户体验
- 开发单页面应用时，前端Route与服务器端Route不匹配，处理起来很麻烦。
- 重要内容都在前端组装，不利于SEO
跨站脚本攻击(XSS)的防御
问题及解决思路
跨站脚本攻击（XSS，Cross-site scripting）是最常见和基本的攻击Web网站的方法。攻击者可以在网页上发布包含攻击性代码的数据，当浏览者看到此网页时，特定的脚本就会以浏览者用户的身份和权限来执行。通过XSS可以比较容易地修改用户数据、窃取用户信息以及造成其它类型的攻击，例如：CSRF攻击。
预防XSS攻击的基本方法是：确保任何被输出到HTML页面中的数据以HTML的方式进行转义（HTML escape）。例如下面的模板代码：
<textarea name="description">$description</textarea>
这段代码中的$description为模板的变量（不同模板中定义的变量语法不同，这里只是示意一下），由用户提交的数据，那么攻击者可以输入一段包含”JavaScript”的代码，使得上述模板语句的结果变成如下的结果：
<textarea name="description">
<script>alert('hello')'</script>
</textarea>
上述代码，在浏览器中渲染，将会执行JavaScript代码并在屏幕上alert hello。当然这个代码是无害的，但攻击者完全可以创建一个JavaScript来修改用户资料或者窃取cookie数据。
解决方法很简单，就是将$description的值进行html escape，转义后的输出代码如下
<textarea name="description">
</textarea><script>alert("hello!")</script>
</textarea>
以上经过转义后的HTML代码是没有任何危害的。
跨站请求伪造攻击(CSRF)的预防
问题及解决思路
名词解释： 表单：泛指浏览器端用于客户端提交数据的形式；包括a标签、ajax提交数据、form表单提交数据等，而非对等于HTML中的form标签。
跨站请求伪造（CSRF，Cross-site request forgery）是另一种常见的攻击。攻击者通过各种方法伪造一个请求，模仿用户提交表单的行为，从而达到修改用户的数据或执行特定任务的目的。
为了假冒用户的身份，CSRF攻击常常和XSS攻击配合起来做，但也可以通过其它手段：例如诱使用户点击一个包含攻击的链接。
解决CSRF攻击的思路分如下两个步骤
1.增加攻击的难度(禁用GET提交表单)。GET请求是很容易创建的，用户点击一个链接就可以发起GET类型的请求，而POST请求相对比较难，攻击者往往需要借助JavaScript才能实现；因此，确保form表单或者服务端接口只接受POST类型的提交请求，可以增加系统的安全性。
2.对请求进行认证(用CSRF token验证请求)，确保该请求确实是用户本人填写表单或者发起请求并提交的，而不是第三者伪造的。
一个正常用户修改网站信息的过程如下
用户请求修改信息(1) -> 网站显示用户修改信息的表单(2) -> 用户修改信息并提交(3) -> 网站接受用户修改的数据并保存(4)
而一个CSRF攻击则不会走这条路线，而是直接伪造第2步用户提交信息
直接跳到第2步(1) -> 伪造要修改的信息并提交(2) -> 网站接受攻击者修改参数数据并保存(3)
只要能够区分这两种情况，就能够预防CSRF攻击。那么如何区分呢？ 就是对第2步所提交的信息进行验证，确保数据源自第一步的表单。具体的验证过程如下：
用户请求修改信息(1) -> 网站显示用于修改信息的空白表单，表单中包含特殊的token同时把token保存在session中(2) -> 用户修改信息并提交，同时发回token信息到服务端(3) -> 网站比对用户发回的token和session中的token，应该一致，则接受用户修改的数据，并保存。
这样，如果攻击者伪造要修改的信息并提交，是没办法直接访问到session的，所以也没办法拿到实际的token值；请求发送到服务端，服务端进行token校验的时候，发现不一致，则直接拒绝此次请求。
建议：在中间层中，可以判断是否request中有token的值，如果一个修改操作，没有token，可以直接在Midway层认为是不安全的，将请求丢弃掉。毕竟安全校验越早进行，成本也会更低。
其他安全问题
关于常见的Web安全问题，还有如下几种，这里只做一些简介。
HTTP Headers安全
CRLF Injection 攻击者想办法在响应头中注入两个CRLF特殊字符，导致响应数据格式异常，从而注入script等
拒绝访问攻击 每个请求因为都会默认带上cookie，而服务器一般都会限制cookie的大小，这就导致了，如果用户客户端cookie被设置成了超过某个阀值，那么用户就再也无法访问网站了
cookie防窃取 一般cookie窃取都是通过JavaScript(XSS漏洞)获取到的，所以尽量将cookie设置成http only，并且加上cookie过期时间
UA 探测
进行多终端适配首先要解决的是 UA 探测问题，对于一个过来的请求，我们需要知道这个设备的类型才能针对对它输出对应的内容。现在市面上已经有非常成熟的兼容大量设备的 User Agent 特征库和探测工具，这里有 Mozilla 整理的一个列表。其中，既有运行在浏览器端的，也有运行在服务端代码层的，甚至有些工具提供了 Nginx/Apache 的模块，负责解析每个请求的 UA 信息。
实际上我们推荐最后一种方式。基于前后端分离的方案决定了 UA 探测只能运行在服务器端，但如果把探测的代码和特征库耦合在业务代码里并不是一个足够友好的方案。我们把这个行为再往前挪，挂在 Nginx/Apache 上，它们负责解析每个请求的 UA 信息，再通过如 HTTP Header 的方式传递给业务代码。
这样做有几点好处：
- 我们的代码里面无需再去关注 UA 如何解析，直接从上层取出解析后的信息即可。
如果在同一台服务器上有多个应用，则能够共同使用同一个 Nginx 解析后的 UA 信息，节省了不同应用间的解析损耗。
来自天猫分享的基于 Nginx 的 UA 探测方案值得一提的是，选用 UA 探测工具时必须要考虑特征库的可维护性，因为市面上新增的设备类型越来越多，每个设备都会有独立的 User Agent，所以该特征库必须提供良好的更新和维护策略，以适应不断变化的设备。
评论区