前端安全-XSS攻击、CSRF攻击

先来玩一个小游戏，输入一定的值，令到XSS攻击成功，执行alert(1)的代码

https://alf.nu/alert1

1. warmup，第一题很简单，直接");alert(1);("就能过
2. adobe，第二题对"进行了转义，但可以用\令到转义字符\失效，之后再加上alert(1)即可过关。参考答案\");alert(1);//
3. json，第三题尝试把输入数据转换为JSON，但没有对<做特殊处理，输入
4. callback, to be continued

---

XSS Cross Site Script 恶意用户将代码注入到网页中，令其他用户在观看网页时，发起跨站请求

CSRF Cross Site Request Forgery 冒充用户发起请求
参考

https://tech.meituan.com/2018/10/11/fe-security-csrf.html
https://tech.meituan.com/2018/09/27/fe-security.html

---

XSS

分为三类

1. 反射型，url参数或post表单中有恶意代码，服务器未处理返回给前端执行脚本
2. 存储型，如论坛发帖等，恶意代码未经处理，存储在数据库，显示给其他用户执行脚本
3. DOM型，这个与后台无关，比如前端的DOM要从url参数获取数据，但未处理好，执行了脚本

CSRF

Cross-site request forgery，诱导受害者进入第三方网站，向被攻击网站发送跨站请求，由于受害者在被攻击网站已经获取注册凭证，就能达到冒充用户对被攻击的网站执行某项操作的目的。

1. GET类型，自动发出get请求
2. POST类型，隐藏的自动提交的表单
3. 链接类型，用户点击才触发，比如在论坛发布的图片中嵌入恶意链接
   由于是从第三方网站发起，所以被攻击网站无法防范。

可以这样防护：

1. 禁止外域访问
   服务器可以从请求头Origin Header、Referer Header获取来源域名。这两个值也可能获取不到。
2. 提交时附加本域才能获取的信息
   1. 用户打开页面时，服务器生成token生成到页面（而不是cookie！），隐藏着。当提交请求时，带上这个token，服务器验证token是否有效。在大型网站，可能有多台服务器，不同请求可能落到不同服务器，服务器保存token就可能变得复杂。这时token可以是一个根据UserID、时间戳等计算生成的一个结果，再经过加密，这样token就不需要存储，只需要每次计算一下。
   2. 验证码或者密码也可以
3. 双重cookie验证
   第二种方法比较繁琐，不能通用的拦截，每个请求都得带上token，很麻烦。
   CSRF不能获取cookie，这时可以把cookie作为第二种方法里的token，放到请求参数里。服务器校验cookie与请求里的参数是否一致即可。
   但这样有风险：
   1. 用户访问a.com，后段api域名是api.a.com,在a.com下拿不到api.a.com的cookie
   2. 任何自娱都可以读取、修改a.com下的cookie，如果子域名存在漏洞被XSS攻击，改了cookie的话，那攻击者就可以在请求参数里加上自己写的cookie了。
4. Samesite Cookie
   从浏览器层面保证，Cookie不能作为第三方Cookie，比如从百度进入淘宝，淘宝是不会收到Cookie的。