--- highlight: a11y-light --- #### 一、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[（原文链接）](https://blog.csdn.net/qq_25623257/article/details/90473859/) > - 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() [更多详情请查看官方文档](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) 设置 meta 标签的方式 ``` ``` 2、转义字符 (可以采用htmlencode) > ``` > function escape(str) { > str = str.replace(/&/g, '&') > str = str.replace(/ 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

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

▼防御策略

##### 1、[SameSite](https://blog.csdn.net/weixin_44269886/article/details/102459425)( 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”参数，也是一笔不小的开销 [原文链接](https://blog.csdn.net/Saladbobo/article/details/90393019?utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control&dist_request_id=&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control)

#### 三、点击劫持原理：用户在登陆 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/ ### 参考文献 [基于timestamp和nonce的防重放攻击 ](https://blog.csdn.net/Saladbobo/article/details/90393019?utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control&dist_request_id=&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control) [HTTP协议安全头部X-Content-Type-Options引入的问题](https://blog.csdn.net/tornadojava/article/details/55191981) [web安全csrf防御和攻击](https://blog.csdn.net/xishining/article/details/79863437)