前端网络防御攻略

CSRF

CSRF：Cross Site Request Forgery，跨站请求伪造 本质是：恶意网站把正常用户作为媒介，通过模拟正常用户的操作，攻击其登录过的站点。

它的原理如下：

1. 用户访问正常站点，登录后，获取到了正常站点的令牌，以cookie的形式保存。
2. 用户访问恶意站点，恶意站点通过某种形式去请求了正常站点（请求伪造），迫使正常用户把令牌传递到正常站点，完成攻击。

防御

现在很多浏览器都支持禁止跨域附带的cookie，只需要把cookie设置的SameSite设置为Strict即可
SameSite有以下取值：

• Strict：严格，所有跨站请求都不附带cookie，有时会导致用户体验不好
• Lax：宽松，所有跨站的超链接、GET请求的表单、预加载连接时会发送cookie，其他情况不发送
• None：无限制 这种方法非常简单，极其有效，但前提条件是：用户不能使用太旧的浏览器,页面中的二次请求都会附带referer或Origin请求头，向服务器表示该请求来自于哪个源或页面，服务器可以通过这个头进行验证。但某些浏览器的referer是可以被用户禁止的，尽管这种情况极少
  这种做法是要求每次请求需要在请求体或请求头中附带token，请求的时候：authorization: token
  这种做法是要求每个要防止CSRF的请求都必须要附带验证码，不好的地方是容易把正常的用户逼疯。
  这种做法是服务端渲染时，生成一个随机数，客户端提交时要提交这个随机数，然后服务器端进行对比，该随机数是一次性的
  流程：

1. 客户端请求服务器，请求添加学生的页面，传递cookie

2. 服务器

   1. 生成一个随机数，放到session中
   2. 生成页面时，表单中加入一个隐藏的表单域<input type="hidden" name="hash" value="<%=session['key'] %>">

3. 填写好信息后，提交表单，会自动提交隐藏的随机数

4. 服务器

   1. 先拿到cookie，判断是否登录过
   2. 对比提交过来的随机数和之前的随机数是否一致
   3. 清除掉session中的随机数

二次验证

当做出敏感操作时，进行二次验证

XSS

XSS：Cross Site Scripting 跨站脚本攻击

存储型XSS

1. 恶意用户提交了恶意内容到服务器
2. 服务器没有识别，保存了恶意内容到数据库
3. 正常用户访问服务器
4. 服务器在不知情的情况下，给予了之前的恶意内容，让正常用户遭到攻击

反射型

1. 恶意用户分享了一个正常网站的链接，链接中带有恶意内容
2. 正常用户点击了该链接
3. 服务器在不知情的情况，把链接的恶意内容读取了出来，放进了页面中，让正常用户遭到攻击

DOM型

1. 恶意用户通过任何方式，向服务器中注入了一些dom元素，从而影响了服务器的dom结构
2. 普通用户访问时，运行的是服务器的正常js代码

防御

非持久型

1. Web 页面渲染的所有内容或者渲染的数据都必须来自于服务端。
2. 不要从 URL，document.referrer，document.forms 等这种 DOM API 中获取数据直接渲染
3. 不要使用 eval, document.write()，document.writeln()等可执行字符串的方法。
4. 过滤不必要的HTML标签，例如：iframe alt script和特殊字符。过滤一些事件onClcik onfocus。
5. 对涉及 DOM 渲染的方法传入的字符串参数做 escape 转义

持久型

1. CSP

CSP 本质上就是建立白名单。设置 HTTP Header 中的 Content-Security-Policy

• default-src : 定义针对所有类型（js/image/css/font/ajax/iframe/多媒体等）资源的默认加载策略，如果某类型资源没有单独定义策略，就使用默认的。
• script-src : 定义针对 JavaScript 的加载策略。
• style-src : 定义针对样式的加载策略。
• img-src : 定义针对图片的加载策略。
• font-src : 定义针对字体的加载策略。

2. 转义字符 (可以采用htmlencode)

3. 设置白名单或者黑名单

显示富文本建议采用白名单过滤，因为黑名单需要过滤的标签太多

4. HttpOnly

禁止通过document.cookie的方式获取cookies