用户请求修改信息(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校验的时候，发现不一致，则直接拒绝此次请求。
Midway解决方案
禁用GET提交表单
如果服务端不接受GET方式提交的表单数据，那么将会给攻击者带来非常大的难度；因为在页面上构造一个a标签href属性或者img标签src属性来构造一个请求是非常容易的，但是如果要POST提交，就必须要通过脚本才可以实现。
用CSRF token验证请求
因为Midway不涉及到淘宝分布式session及token校验这一层面逻辑，所以在Midway框架中，只将token在server和客户端之间进行转发，本身不做实际的校验工作。流程如下：
后续：在Midway中，Node.js和淘宝的分布式session对接后，可以考虑在Midway这一层自动进行token校验；毕竟安全校验越早进行，成本也会更低。
建议：在Midway中，可以判断是否request中有token的值，如果一个修改操作，没有token，可以直接在Midway层认为是不安全的，将请求丢弃掉。
其他安全问题
关于常见的Web安全问题，还有如下几种，这里只做一些简介，后续会持续继承到Midway framework中。
HTTP Headers安全
CRLF Injection 攻击者想办法在响应头中注入两个CRLF特殊字符，导致响应数据格式异常，从而注入script等
拒绝访问攻击 每个请求因为都会默认带上cookie，而服务器一般都会限制cookie的大小，这就导致了，如果用户客户端cookie被设置成了超过某个阀值，那么用户就再也无法访问网站了
cookie防窃取 一般cookie窃取都是通过JavaScript(XSS漏洞)获取到的，所以尽量将cookie设置成http only，并且加上cookie过期时间
关于cookie的安全问题，之前WebX已经有较好的解决方案；此次Midway不负责cookie的设置和校验等工作，只负责转发到WebX层面进行check
关于Node.js
XSS等注入性漏洞是所有漏洞中最容易被忽略，占互联网总攻击的70%以上；开发者编写Node.js代码时，要时刻提醒自己，永远不要相信用户的输入。
比如如下几个例子。
var mod = fs.readFileSync('path'); 如果path来源于用户输入，那么假设用户输入/etc/password，则会读取到不应该读取的内容，造成密码泄漏风险
var result = eval(jsonVal); 一定要确保jsonVal是json，而不是用户的输入
…… 其他可能包含用户输入的地方，一定要确认用户的输入是我们期望的值
总结
前后端分离模式下，可以让传统的前端开发人员开始编写后端代码，虽然从架构上讲，只负责模板这一层，但也会接触大量的后端代码；所以安全对于前端来说，这是一个不小的挑战。
您可能感兴趣的文章: