关于 Web 安全：CSRF 攻击 和 XSS 攻击

Question

CSRF 攻击：跨站请求伪造

攻击者盗用了你的身份，以你的名义发送恶意请求，容易造成个人隐私泄露以及财产安全。

原因：SRF 攻击时源于 WEB 的隐式身份验证机制！WEB 的身份验证机制虽然可以保证一个请求是来自某个用户的浏览器，但无法保证该请求是经过用户批准发送的。

攻击的对象：攻击者所能做的就是给服务器发送请求，以执行请求中所描述的命令，在服务器端直接改变数据的值，而非窃取服务器中的数据。所以，我们要保护的对象是那些可以直接产生数据改变的服务，而对于读取数据的服务，则不需要进行 CSRF 的保护。例如 GET请求，不需要进行CSRF的保护。查询余额是对金额的读取操作，不会改变数据，CSRF 攻击无法解析服务器返回的结果（由于浏览器同源策略的限制，黑客也无法进行解析），无需保护。

如何防御：

• 关键操作只接受 POST 请求
• 验证码
• 检测 Referer
• Token

验证码：CSRF 攻击的过程，往往是在用户不知情的情况下发生的，在用户不知情的情况下构造网络请求，所以如果使用验证码，那么每次操作都需要用户进行互动，从而简单有效地防御了 CSRF 的攻击。 验证码一般只出现在特殊操作里面，或者在注册时候使用。多了严重影响用户体验。

检测 Referer：根据 HTTP 协议，在 HTTP 请求头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站，比如需要访问 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory， 用户必须先登陆 bank.example，然后通过点击页面上的按钮来触发转账事件。如果 Referer 是其他网站的话，则有可能是黑客的 CSRF 攻击，拒绝该请求。这种方法的显而易见的好处就是简单易行，网站的普通开发人员不需要操心 CSRF 的漏洞，只需要在最后 给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。
缺点：每个浏览器对于 Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞（有些可篡改 Referer 值）。另外，Referer 值会记录下用户的访问来源，有些用户认为这样会侵犯到他们自己的隐私权，用户自己可以设置浏览器使其在发送请求时不再提供 Referer。

Token：目前主流的做法是使用 Token 防御 CSRF 攻击。
CSRF 攻击要成功的条件在于攻击者能够准确地预测所有的参数从而构造出合法的请求，所以根据不可预测性原则，我们可以对参数进行加密从而防止 CSRF 攻击，可以保存其原有参数不变，另外添加一个参数 Token，其值是随机的，这样攻击者因为不知道 Token 而无法构造出合法的请求进行攻击，所以我们在构造请求时候只需要保证：

Token 要足够随机，使攻击者无法准确预测
Token 是一次性的，即每次请求成功后要更新 Token，增加预测难度
Token 要主要保密性，敏感操作使用 POST，防止 Token 出现在 URL 中

注意：过滤用户输入的内容不能阻挡 CSRF 攻击，我们需要做的是过滤请求的来源，因为有些请求是合法，有些是非法的。所以 CSRF 防御主要是过滤那些非法伪造的请求来源。

XSS 攻击（跨站脚本攻击）

原理：攻击者向有 XSS 漏洞的网站中输入恶意的 HTML 代码，当其它用户浏览该网站时候，该段 HTML 代码会自动执行，从而达到攻击的目的，如盗取用户的 Cookie，破坏页面结构，重定向到其它网站等。

如：
某论坛的评论功能没有对 XSS 进行过滤，那么我们可以对其进行评论

<script>
while(true) {
    alert('你关不掉我');
}
</script>

在发布评论中含有 JS 的内容文本，这时候如果服务器没有过滤或转义掉这些脚本，作为内容发布到页面上，其他用户访问这个页面的时候就会运行这段脚本。也可以发布恶意代码盗取你的 Cookie 或者其它信息。

如何防御：过滤用户的输入 / 对用户的输入进行转义。