一、web安全（xss/csrf）简单攻击原理和防御方案（理论篇）

一、XSS（Cross-Site Scripting） 跨站脚本攻击

原理：恶意攻击者往 Web 页面里插入恶意可执行网页脚本代码，当用户浏览该页之时，嵌入其中 Web 里面的脚本代码会被执行，从而可以达到攻击者盗取用户信息或其他侵犯用户安全隐私的目的。

1.非持久型 XSS（反射型 XSS ）

▼防御策略

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

2.持久型 XSS（存储型 XSS）

原理：持久型 XSS 漏洞，一般存在于 Form 表单提交等交互功能，如文章留言，提交文本信息等，黑客利用的 XSS 漏洞，将内容经正常功能提交进入数据库持久保存，当前端页面获得后端从数据库中读出的注入代码时，恰好将其渲染执行

▼防御策略

1、CSP：CSP 本质上就是建立白名单，开发者明确告诉浏览器哪些外部资源可以加载和执行。我们只需要配置规则，如何拦截是由浏览器自己实现的。我们可以通过这种方式来尽量减少 XSS 攻击。

设置 HTTP Header 中的 Content-Security-Policy（原文链接）

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

CSP 指令值

name	价格
'*'	允许加载任何内容
‘none‘	不允许加载任何内容
‘self‘	允许加载相同源的内容
www.a.com	允许加载指定域名的资源
*.a.com	允许加载 a.com 任何子域名的资源
https://a.com	允许加载 a.com 的 https 资源
https：	允许加载 https 资源
data：	允许加载 data: 协议，例如：base64编码的图片
‘unsafe-inline‘	允许加载 inline 资源，例如style属性、onclick、inline js、inline css等
‘unsafe-eval‘	允许加载动态 js 代码，例如 eval()

更多详情请查看官方文档

设置 meta 标签的方式

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

function escape(str) {
  str = str.replace(/&/g, '&')
  str = str.replace(//g, '>')
  str = str.replace(/"/g, '&quto;')
  str = str.replace(/'/g, ''')
  str = str.replace(/`/g, '`')
  str = str.replace(/\//g, '/')
  return str
}

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

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

const xss = require('xss')
let html = xss('
XSS Demo
')
// -> 
XSS Demo
<script>alert("xss");</script>
console.log(html)

4、HttpOnly （最有效的防御手段）

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

二、CSRF 跨站点伪造

原理： 诱导用户打开黑客的网站，在黑客的网站中，利用用户登录状态发起跨站点请求。

▼防御策略

1、SameSite( Chrome 51开始支持)

可以对 Cookie 设置 SameSite 属性。该属性表示 Cookie 不随着跨域请求发送，可以很大程度减少 CSRF 的攻击，但是该属性目前并不是所有浏览器都兼容。

• Strict：所有从当前域发送出来的非同域请求都不会带上cookie
• Lax：就是在GET方式提交表单时会携带cookie，post、iframe/img等标签加载时不会携带cookie。
• None：关闭SameSite，不过，前提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。

Set-Cookie: CookieName=CookieValue; SameSite=Strict;
//这个规则过于严格，可能造成非常不好的用户体验。比如，当前网页有一个 GitHub 链接，用户点击跳转就不会带有 GitHub 的 Cookie，跳转过去总是未登陆状态。

Set-Cookie: CookieName=CookieValue; SameSite=Lax;
//Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。

Set-Cookie: widget_session=abc123; SameSite=None; Secure

2.Referer Check(referer可以伪造，Referer记录了请求来源的地址，Origin只包含了域名信息，并没有具体的URL)

HTTP Referer是header的一部分，当浏览器向web服务器发送请求时，一般会带上Referer信息告诉服务器是从哪个页面链接过来的，服务器籍此可以获得一些信息用于处理。可以通过检查请求的来源来防御CSRF攻击。正常请求的referer具有一定规律，如在提交表单的referer必定是在该页面发起的请求。所以通过检查http包头referer的值是不是这个页面，来判断是不是CSRF攻击。

3. Token(前比较完善的解决方案)

即发送请求时在HTTP 请求中以参数的形式加入一个随机产生的token，并在服务器建立一个拦截器来验证这个token。服务器读取浏览器当前域cookie中这个token值，会进行校验该请求当中的token和cookie当中的token值是否都存在且相等，才认为这是合法的请求。否则认为这次请求是违法的，拒绝该次服务。

4. 验证码

5. 基于timestamp和nonce的防重放攻击

• 基于timestamp的方案

每次HTTP请求，都需要加上timestamp参数，然后把timestamp和其他参数一起进行数字签名。因为一次正常的HTTP请求，从发出到达服务器一般都不会超过60s，所以服务器收到HTTP请求之后，首先判断时间戳参数与当前时间相比较，是否超过了60s，如果超过了则认为是非法的请求。

一般情况下，黑客从抓包重放请求耗时远远超过了60s，所以此时请求中的stime参数已经失效了。
如果黑客修改stime参数为当前的时间戳，则sign参数对应的数字签名就会失效，因为黑客不知道token值，没有办法生成新的数字签名。

==缺点==：如果在60s之后进行重放攻击，那就没办法了，所以这种方式不能保证请求仅一次有效

• 基于nonce的方案

nonce的意思是仅一次有效的随机字符串，要求每次请求时，该参数要保证不同，所以该参数一般与时间戳有关，我们这里为了方便起见，直接使用时间戳的16进制，实际使用时可以加上客户端的ip地址，mac地址等信息做个哈希之后，作为nonce参数。
我们将每次请求的nonce参数存储到一个“集合”中，可以json格式存储到数据库或缓存中。
每次处理HTTP请求时，首先判断该请求的nonce参数是否在该“集合”中，如果存在则认为是非法请求。

==缺点==：存储nonce参数的“集合”会越来越大，验证nonce是否存在“集合”中的耗时会越来越长。我们不能让nonce“集合”无限大，所以需要定期清理该“集合”，但是一旦该“集合”被清理，我们就无法验证被清理了的nonce参数了。也就是说，假设该“集合”平均1天清理一次的话，我们抓取到的该url，虽然当时无法进行重放攻击，但是我们还是可以每隔一天进行一次重放攻击的。而且存储24小时内，所有请求的“nonce”参数，也是一笔不小的开销

原文链接

三、点击劫持

原理：用户在登陆 A 网站的系统后，被攻击者诱惑打开第三方网站，而第三方网站通过 iframe 引入了 A 网站的页面内容，用户在第三方网站中点击某个按钮（被装饰的按钮），实际上是点击了 A 网站的按钮。

▼防御策略

1.X-FRAME-OPTIONS

X-FRAME-OPTIONS是一个 HTTP 响应头，在现代浏览器有一个很好的支持。这个 HTTP 响应头 就是为了防御用 iframe 嵌套的点击劫持攻击。

该响应头有三个值可选，分别是

• DENY，表示页面不允许通过 iframe 的方式展示
• SAMEORIGIN，表示页面可以在相同域名下通过 iframe 的方式展示
• ALLOW-FROM，表示页面可以在指定来源的 iframe 中展示

服务端输出header头

X-Frame-Options: SAMEORIGIN  #仅允许被同域名页面引入

nginx配置

add_header X-Frame-Options SAMEORIGIN #server或者http上下文中设置

实战演示请看下一篇 https://juejin.cn/post/6953059119561441287/