web安全之XSS和CSRF

XSS
XSS 简单点来说，就是攻击者想尽一切办法将可以执行的代码注入到网页中。
分为反射型和持久型
反射型
XSS代码出现在URL中，服务端解析响应后，XSS代码随响应内容一起传回给浏览器，最后浏览器解析执行XSS代码。
img标签 src为空 onerror

<img src="" alt="" onerror="alert(1)">

持久型
持久型也就是攻击的代码被服务端写入进数据库中，比如用户提交评论，将包含XSS代码的内容提交，然后服务端将内容保存数据库中。之后其他用户查看评论的时候都会取出内容展示的时候就会执行这些恶意代码。

XSS的防御
1、使用 XSS Filter
针对用户提交的数据进行有效的验证，只接受我们规定的长度或内容的提交，过滤掉其他的输入内容。比如：
1.表单数据指定值的类型：年龄只能是 int 、name 只能是字母数字等。
2.过滤或移除特殊的 html 标签：

const xss = require('xss')
let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>')
// -> <h1>XSS Demo</h1>&lt;script&gt;alert("xss");&lt;/script&gt;
console.log(html)

以上示例使用了 js-xss 来实现，可以看到在输出中保留了 h1 标签且过滤了 script 标签

4.设置httpOnly 防止客户端获取cookie信息

5.开启CSP
通常可以通过两种方式来开启 CSP：
设置 HTTP Header 中的 Content-Security-Policy
设置 meta 标签的方式
这里以设置 HTTP Header 来举例
只允许加载本站资源
Content-Security-Policy: default-src ‘self’
只允许加载 HTTPS 协议图片
Content-Security-Policy: img-src https://*
允许加载任何来源框架
Content-Security-Policy: child-src ‘none’

CSRF
CSRF 中文名为跨站请求伪造。原理就是CSRF攻击者在用户已经登录目标网站之后，诱使用户访问一个攻击页面，利用目标网站对用户的信任，以用户身份在攻击页面对目标网站发起伪造用户操作的请求，达到攻击目的。

防御
1.验证 HTTP Referer 字段
它记录了该 HTTP 请求的来源地址。比如说点击一个按钮提交信息，这个请求的referer就是这个按钮所在的页面的URL，如果是别的第三方的网站的请求，那这个referer就是第三方网站的URL。所以只需要添加一个拦截器来接检查Referer的值就可以，简单易行。但是个浏览器对于 Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。事实上，对于某些浏览器，比如 IE6 或 FF2，目前已经有一些方法可以篡改 Referer 值。况且对于最新的浏览器，黑客已经不能改referer的值了，不过因为refer会记录用户的访问来源，有些用户会认为这样侵犯隐私，因此可以设置请求不提供referer。那么接收的网站就可能会认为是CSRF攻击。
2.使用token验证
CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。
这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对，但这种方法的难点在于如何把 token 以参数的形式加入请求。对于 GET 请求，token 将附在请求地址之后，这样 URL 就变成 http://url?csrftoken=tokenvalue。 而对于 POST 请求来说，要在 form 的最后加上 ，这样就把 token 以参数的形式加入请求了。但是，在一个网站中，可以接受请求的地方非常多，要对于每一个请求都加上 token 是很麻烦的，并且很容易漏掉，通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。
该方法还有一个缺点是难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。不过，即使这个 csrftoken 不以参数的形式附加在请求之中，黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。
3.SameSite Cookie
Set-Cookie 响应头新增 SameSite 属性，它用来标明这个 cookie 是个“同站 cookie”，同站 cookie 只能作为第一方 cookie，不能作为第三方 cookie。SameSite 有两个属性值，分别是 Strict 和 Lax
Strict
禁止发送所有第三方链接的 cookies，默认情况下，如果添加了 SameSite 关键字，但是没有指定 value（Lax or Stict），那么默认为 Strict
Lax
允许发送安全 HTTP 方法（GET, HEAD, OPTIONS, TRACE）第三方链接的 cookies
必须是 TOP-LEVEL 即可引起地址栏变化的跳转方式，例如 <a>, <link rel="prerender">, GET 方式的 form 表单，此外，XMLHttpRequest, 等方式进行 GET 方式的访问将不会发送 cookies
但是禁止发送不安全 HTTP 方法（POST, PUT, DELETE）第三方链接的cookies