Jian‘s blog

# 前端网络安全

  1. 正则表达式的攻击原理 (opens new window)
  2. CSRF攻击 (opens new window)
  3. Redos测试网站 (opens new window)

# 1、浏览器

  • XSS、CSRF、HTTPS

  • csp：内容安全策略，可以禁止加载外域代码，禁止外域的提交，Content-Security-Policy｜X-XSS-Protection

  • HSTS：强制客户端使用HTTPS与服务端建立连接

  • X-Frame-Options：控制当前页面是否可以别嵌入到iframe中

    • DENY：表示该页面不允许在frame中展示，即便是在相同域名的页面中嵌套也不允许
    • SAMEORIGIN：表示该页面可以在相同域名页面的frame中展示
    • ALLOW-FROM uri：表示该页面可以在指定来源的frame中展示

  • SRI（subresource intergrity 子资源的完整性）：请求cdn子资源的完整性

    • jian-xdfs-da-daaa.js：注入到index.html，并且上传至cdn
    • 用户在请求的时候，根据jian-xdfs-da-daaa.js去请求，而这个文件可能被篡改
    • 打包的时候根据js文件内容生成一个hash值，并且把hash值作为intergrity属性注入到script上，前端可以⽤webpack-subresource-integrity插件实现。

  • Referer-Policy：控制referer的携带策略

# 1、XSS

聊一下xss？思路：概念、攻击类型、如何防范、自己工作中是否遇到？如何解决？

# 1、概念

Cross Site Script，xss垮站脚本攻击，攻击者想尽一切办法把可执行代码注入到网页中

# 2、攻击类型

外在表现上，都有哪些攻击场景：

  1. 评论区植入js代码（即可输入的地方）
  2. url上拼接js代码

技术角度上，有哪些类型的xss攻击：

  1. 存储型Server：服务端存在数据库

    论坛发帖，商品评价，用户私信等这些用户保存数据的网站

    攻击步骤：

    • 攻击者将恶意代码提交到目标网站的数据库中
    • 用户打开目标网站的时候，服务端将评论（恶意代码）从数据库中取出，拼接到html返回给浏览器
    • 用户浏览器收到html后，混在其中的恶意代码就会执行
    • 窃取用户数据，发放到攻击者网站

  2. 反射型Server：拼接在url上

    攻击者结合各种手段，诱导用户点击恶意url，通过url传参数的功能，比如网站的搜索或跳转等。

    攻击步骤：

    • 攻击者构造出自己的恶意url
    • 直接执行可执行的恶意代码

  3. Dom型 Browser

    取出和执行恶意代码的操作，由浏览器完成，属于前端 JavaScript ⾃身的安全漏洞，⽽其他两种 XSS 都属于服务端的安全漏洞。

    攻击步骤：

    • 攻击者构造出特殊的 URL，其中包含恶意代码。

    • ⽤户打开带有恶意代码的 URL。

    • ⽤户浏览器接收到响应后解析执⾏，前端 JavaScript 取出 URL 中的恶意代码并执⾏。

    • 恶意代码窃取⽤户数据并发送到攻击者的⽹站，或者冒充⽤户的⾏为，调⽤⽬标⽹站的接⼝执⾏攻击者指定的操作。

# 3、防范攻击

主旨：防止攻击者提交恶意代码，防止浏览器执行恶意代码

  1. 对数据进行严格的输入编码：

    • html元素的编码、js编码、css编码、url编码等；
    • 避免拼接html，eg：Vue/React技术栈，避免使用v-html/dangerouslyHtml

  2. CSP：http header，即Content-Security-Policy，旧浏览器可以设置X-XSS-Protection

    • default-src 'self'：所有内容均来⾃站点的同⼀个源（不包括其⼦域名）
    • default-src ‘self’ *.trusted.com：允许内容来⾃信任的域名及其⼦域名 (域名不必须与CSP设置所在的域名相同)
    • default-src https://baidu.com：该服务器仅允许通过HTTPS⽅式并仅从lubai.com域名来访问⽂档

  3. 输入验证：phone，url，电话号码，邮箱做校验判断

  4. 开启浏览器的XSS防御：http only Cookie，禁止js读取cookie值，完成xss注入也无法窃取cookie，eg：set-cookie，httponly

  5. 验证码

# 2、CSRF

# 1、概念

Cross-Site request forgery，跨站请求伪造：攻击者诱导受害者进⼊恶意⽹站，在第三⽅⽹站中，向被攻击⽹站发送跨站请求。利⽤受害者在被攻击⽹站已经获取的注册凭证，绕过后台的⽤户验证，达到冒充⽤户对被攻击的⽹站执⾏某项操作的⽬的。

攻击步骤：

  1. 受害者登录a.com，并且保留了登录凭证cookie
  2. 攻击者诱导受害者访问b.com
  3. b.com向a.com发送请求，a.com/xxxx，浏览器就会直接带上a.com的cookie
  4. a.com收到了请求，验证通过后，执行相应操作
  5. 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作

# 2、攻击类型

  1. GET型：如在⻚⾯的某个 img 中发起⼀个 get 请求

  2. POST型：通过⾃动提交表单到恶意⽹站

# 3、如何防范

CSRF一般发生在第三方域名，攻击者无法获取到cookie信息，只是利用浏览器机制使用cookie

  1. 同源策略
    • 通过检查request header中的origin、referer、host等，判断请求站点是否是自己允许的站点。
      • host：任何请求携带，域名和端口号
      • origin：一般存在于跨域请求中，协议和域名，和Access-Control-Allow-Origin一起存在
      • referer：告知服务器原始url，其用于所有类型的请求，并且包括：协议+域名+查询参数
    • Referrer-Policy：可设置携带referer头，eg：Referrer-Policy: no-referrer｜same-origin等。
  2. Cookie SameSite
    • Strict：完全禁止第三方cookie，⽐如a.com的⻚⾯中访问 b.com 的资源，那么a.com中的cookie不会被发送到 b.com服务器，只有从b.com的站点去请求b.com的资源，才会带上这些Cookie
    • Lax：在跨站点的情况下，从第三⽅站点链接打开和从第三⽅站点提交 Get⽅式的表单这两种⽅式都会携带Cookie。但如果在第三⽅站点中使⽤POST⽅法或者通过 img、Iframe等标签加载的URL，这些场景都不会携带Cookie
    • None：任何情况下都会发送 Cookie数据
  3. CSRF Token：提交请求时携带额外信息
    • 用户打开页面的时候，服务器生成一个token
    • 每次页面加载的时候，加到所有的能发请求的html元素上, ⽐如form, a
    • 每次前端发起请求, 都携带Token参数
    • 服务端每次接收请求, 都校验Token的有效性

# 2、node相关

  • 本地文件操作相关，路径拼接导致的文件泄露
  • ReDos
  • 时序攻击
  • ip origin referrer等request headers的校验

# 1、文件泄露

问题描述：静态文件服务，用户可通过输入路径获取私密文件

解决方法：

  • express：static
  • koa：中间件koa-static
  • npm包：resolve-path

# 2、ReDos

问题描述：正则表达式攻击，服务器经常会有正则去匹配⼀些传⼊的参数, 所以攻击者就可以利⽤正在表达式的这个特性, 来⼀直占⽤服务器运算资源, 造成服务器宕机。

正则表达式⼀般情况下会去匹配第⼀种可能性，直接匹配到最后发现成功了, 耗时就很短；每当⼀次匹配不成功, 就会尝试回溯到上⼀个字符, 看看能不能有其他的组合来匹配到这个字符串.

# 3、时序攻击

根据服务器的响应时间来碰撞出realArray的值。

Last Updated: 10/3/2021, 9:23:14 PM