基于NodeJS的前后端分离的思考与实践（四）安全问题解决方案_node.js(3)

时间:2014-09-27 16:18来源:网络整理作者:网络点击: 次

分享到：

除了对页面中输出的普通数据和富文本数据，一些场景中也还包含其他可能需要转义的情况，Midway提供了如下几个常用的转义方法，供开发者使用： esca

除了对页面中输出的普通数据和富文本数据，一些场景中也还包含其他可能需要转义的情况，Midway提供了如下几个常用的转义方法，供开发者使用：

escapeHtml 过滤指定的HTML中的字符，防XSS漏洞
jsEncode 对输入的String进行JavaScript 转义对中文进行unicode转义，单引号，双引号转义
escapeJson 不破坏JSON结构的escape函数，只对json结构中name和vaule做escapeHtml处理
escapeJsonForJsVar 可以理解就是jsEncode+escapeJson
例子如下

复制代码代码如下:

var jsonText ="{\"<script>\":\"<script>\"}";

console.log(SecurityUtil.escapeJson(jsonText));// {"<script>":"<script>"}

var jsonText ="{\"你好\":\"<script>\"}";

console.log(SecurityUtil.escapeJsonForJsVar(jsonText));//{\"\u4f60\u597d\":\"<script>\"}

var str ="alert(\"你好\")";

console.log(SecurityUtil.jsEncode(str));// alert(\"\u4f60\u597d\")

跨站请求伪造攻击(CSRF)的预防

问题及解决思路

名词解释：表单：泛指浏览器端用于客户端提交数据的形式；包括a标签、ajax提交数据、form表单提交数据等，而非对等于HTML中的form标签。

跨站请求伪造（CSRF，Cross-site request forgery）是另一种常见的攻击。攻击者通过各种方法伪造一个请求，模仿用户提交表单的行为，从而达到修改用户的数据或执行特定任务的目的。

为了假冒用户的身份，CSRF攻击常常和XSS攻击配合起来做，但也可以通过其它手段：例如诱使用户点击一个包含攻击的链接。

解决CSRF攻击的思路分如下两个步骤

1.增加攻击的难度。GET请求是很容易创建的，用户点击一个链接就可以发起GET类型的请求，而POST请求相对比较难，攻击者往往需要借助JavaScript才能实现；因此，确保form表单或者服务端接口只接受POST类型的提交请求，可以增加系统的安全性。
2.对请求进行认证，确保该请求确实是用户本人填写表单或者发起请求并提交的，而不是第三者伪造的。

一个正常用户修改网站信息的过程如下

用户请求修改信息(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和客户端之间进行转发，本身不做实际的校验工作。流程如下：