Web开发的安全之旅 | 青训营笔记

Q7Q
98 阅读4分钟

这是我参与「第四届青训营 」笔记创作活动的第6天

两个角度看web安全

  • 假如你是一个hacker——攻击
  • 假如你是一个开发者——防御

1.攻击篇

1.1.XSS（Cross-Site Scripting）

  • 在我们的一个开发维护页面中，攻击者通过一种方式把他的恶意脚本注入进来。当用户访问这个页面时，这些恶意脚本就会被执行，进而完成攻击；造成的后果是用户隐私泄露，也有可能用户的机器被当成一个挖矿的机器。

  • XSS主要利用了：

    1. 作为开发者，盲目信任用户提交的内容
    2. 作为前端工程师，直接把用户提交的字符串转化为DOM（没有将用户提交内容进行过滤/转义）

  • XSS的一些特点

    • 通常难以从UI上感知（暗地执行脚本）
    • 窃取用户信息（cookie/token）
    • 绘制UI（例如弹窗），诱骗用户点击/填写表单

XSS可以分为几大类：

1.1.1 Stored XSS

  • 存储型的XSS攻击

    • 恶意脚本被存在数据库中
    • 访问页面 -> 读数据 的 ≡ 被攻击
    • 危害最大，对全部用户可见

  • image.png

1.1.2 Reflected XSS

  • 特点

    • 不涉及数据库
    • 从URL上攻击

image.png

1.1.3 DOM-based XSS

  • 特点

    • 不需要服务器的参与
    • 恶意攻击的发起+执行，全在浏览器完成

image.png url完全没变，执行环境变化：在浏览器中执行

  • 与Reflected XSS 最大的区别：完成注入脚本的地方

    反射型在服务端注入，DOM由浏览器完成

1.1.4 Mutation-based XSS

  • 特点：

    • 利用了浏览器渲染DOM的特性（独特优化）
    • 不同浏览器，会有区别（按浏览器进行攻击）

  • 最难防御的一种攻击

1.2.CSRF

  • 特点：

    • 在用户不知情的前提下
    • 利用用户权限cookie
    • 构造指定HTTP请求，窃取或修改用户敏感信息

image.png

  • 最常见的是get请求方式

image.png

  • 还可以构建其他请求

image.png

1.3.Injection

1.3.1 SQL Injection

image.png

1.3.2 Injection不止于SQL

  • 还包括：

    • CLI

    • OS command

    • Server-side Request Forgery（SSRF），服务端伪造请求

      • 严格而言，SSRF不是injection，但是原理类似

  • 删除：

image.png

  • 读取 + 修改：

image.png

  • SSRF的demo：

1.4.DoS（Denial of Service）

image.png

  • 通过某种方式（构造特定请求），导致服务器资源被显著消耗，来不及响应更多请求，导致请求挤压，进而雪崩效应。

1.4.1 ReDoS：基于正则表达式的DoS

  • 正则表达式——贪婪模式：重复匹配时，满足“一个”即可vs尽量多

image.png 攻击者可以利用这一点，完成基于正则表达式的DoS；比如说服务器端写了个贪婪的正则表达式，攻击者可以传入一个容易发生回溯行为的字符串，来对我们进行攻击，会导致响应时间大大增加，接口吞吐量大大下降，响应用户的请求不断降低。

1.4.2 DDoS（Distributed DoS）

  • 短时间内，来自大量僵尸设备的请求流量，服务器不能及时完成全部请求，导致请求堆积，进而雪崩效应，无法响应新请求。

  • 攻击特点：

    • 直接访问IP
    • 任意API
    • 消耗大量带宽（耗尽）

  • 洪水攻击：

    攻击者不会返回第三次ACK，三次握手没完成，连接数不能被释放

1.5.基于传输层的攻击方式

  • 最常见的：中间人攻击

image.png

2.防御篇

2.1.针对XSS攻击

  • 永远不信任用户的提交内容

    • 不要将用户提交内容直接转换成DOM

  • 现成工具

    • 前端

      • 主流框架默认防御XSS
      • google-closure-library

    • 服务端（node）

      • DOMPurify

  • 但是，如果用户需求必须动态生成DOM，需要注意

    • string --> DOM

      • 需要对string进行转译

    • 上传svg

      • 对svg文件进行扫描

    • 自定义跳转链接

      • 尽量不要让用户做自定义跳转链接，如果要，则做好过滤

    • 自定义样式

补充：Same-origin Policy

  • 同源策略：确保两个url上的协议、域名、端口统统相等，才叫同源
  • HTTP请求：同源可以，跨域有问题（看服务器的设置）

2.2.CSP(Content Security Policy)

  • 允许开发者定义哪些源（域名）被认为是安全的，来自安全源的脚本可以执行，否则直接抛错；对eval + inline script 拒绝

2.3.CSRF的防御

  • Origin和Referer的形式：

  • token：

  • iframe攻击

  • CSRF anti-pattern

    既能获取数据，也能修改数据

  • 避免用户信息被携带

HTTPS的一些特性：

  • 可靠性：加密
  • 完整性：MAC验证
  • 不可抵赖性：数字签名
avatar
文章
阅读
粉丝