第3章 跨站脚本攻击（XSS）

简介

XSS攻击，通常指黑客通过 "HTML" 注入的方式插入了恶意的脚本（也就是我们所说的XSS payload），从而在用户浏览网页时，控制用户浏览器的一种攻击。

分类

反射性XSS

• 用户可以请求浏览器返回数据，所以一般通过黑客诱惑用户点击攻击连接，里面做的可能是事情是请求资源
• XSS 利用的是网站对用户（输入）的信任，CSRF 利用的是网站对用户网页浏览器的信任

存储性XSS

• 黑客把恶意的脚本保存到服务器端，所以这种XSS攻击就叫做“存储型XSS”。

DOM Based XSS

• 通过修改页面的DOM节点形成的XSS，称之为DOM Based XSS。
• 比如说像用户属于数据，我们通过 innnerHtml 的方式插入到某个节点上面

防御措施

HttpOnly

• 浏览器禁止页面 JS 访问带有 HttpOnly 属性的 Cookie

输入检查

• 过滤敏感字符

输出检查

• 在做像innerHeml等操作时注意通过 HTMLEncode、JavaScriptEncode 编码输出，经过浏览器解析后只会是普通的字符串，即便这个字符串有标签存在

总结

XSS 漏洞虽然复杂，但是我觉得前端开发者了解了它的一个攻击模式，就不用怕它，去针对不同的场景使用不同的方法，现在有很多的开源库给我们参考和使用

第4章 跨站点请求伪造（CSRF）

简介

CSRF 的全名 Cross Site Requet Forgery，翻译成中文就是跨站点请求伪造。它的一个攻击模式基本就是诱使用户访问一个页面，然后利用浏览器会默认发送 cookie 这样的一个特性去伪造用户身份进行操作（前提是用户在这个时间点登陆黑客要攻击的页面）。

tips：浏览器持有的 cookie 分为两种：一种是 “Session Cookie”，又称“临时 cookie”（没有指定Expire时间），另一种是“Third-party Cookie”, 也称为“本地 cookie”（指定了过期时间/Expire）；在浏览网站的过程中，若是一个网站设置了Session Cookie，那么在浏览器进程的生命周期内，即使浏览器新打开了Tab页，Session Cookie也都是有效的。Session Cookie保存在浏览器进程的内存空间中；而Third-party Cookie则保存在本地。

防御措施

验证码

CSRF攻击的过程，往往是在用户不知情的情况下构造了网络请求。而验证码，则强制用户必须与应用进行交互，才能完成最终请求。因此在通常情况下，验证码能够很好地遏制CSRF攻击。但是验证码并非万能。很多时候，出于用户体验考虑，网站不能给所有的操作都加上验证码。因此，验证码只能作为防御CSRF的一种辅助手段，而不能作为最主要的解决方案。

Referer Check（跨域就 orgin Check）

常见的互联网应用，页面与页面之间都具有一定的逻辑关系，这就使得每个正常请求的Referer具有一定的规律。但是这种方式一个比较大的缺点我们必须去组织页面与页面之间这种逻辑关系的一个映射表，在页面较多的情况下使用起来并不方便，所以 Referer Check 也不能作为防御 CSRf 的手段，不过我们利用它来监控 CSRF 行为，倒也是一种不错的方案！

Anti CSRF Token

Token 的话是 CSRF 一种比种比较妥当的防御方案，为什么这样说呢？首先我们要知道CSRF为什么能够攻击成功？其本质原因是重要操作的所有参数都是可以被攻击者猜测到的。攻击者只有预测出URL的所有参数与参数值，才能成功地构造一个伪造的请求；反之，攻击者将无法攻击成功。出于这个原因，可以想到一个解决方案：把参数加密，或者使用一些随机数，从而让攻击者无法猜测到参数值。Token 防御CSRF正是利用了这种不可预测性原则！