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

攻击篇

一.XSS 的一些特点

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

二.XSS 分类

Stored XSS

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

Reflected XSS

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

DOM-based XSS

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

Reflected vs DOM-based

区别在于完成注入脚本的地方,Reflected是在服务端,DOM-based是在浏览器进行完成

Mutation-based XSS

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

Cross-site request forgery(CSRF)

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

Denial of Service(DoS)

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

Distributed DoS(DDoS)

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

中间人攻击

防御篇

一.针对Xss攻击

• 永远不信任用户的提交内容
• 不要将用户提交内容直接转换成 DOM XSS一一现成工具 前端
• 主流框架默认防御XSS
• google-closure-library 服务端(Node)
• DOMPurify

PS: 如遇到必须动态生成Dom

注意string->DOM 我们需要对string进行转译

注意上传SVG 我们需要对SVG文件进行一次扫描

注意Blob 动态生成 script

注意自定义样式

Content Security Policy(CSP)

• 哪些源(域名)被认为是安全的
• 来自安全源的脚本可以执行，否则直接抛错
• 对 eval + inline script 拒绝

CSRF 的防御

• if伪造请求=异常来源
• then 限制请求来源->限制伪造请求
• Origin
• 同源请求中，GET + HEAD 不发送
• Referer

避免用户信息被携带:SameSite Cookie

Injection

• 找到项目中查询SOL的地方使用
• prepared statement Injection beyond SQL

防御 DoS

Regex DoS

DDoS

传输层一一防御中间人

HTTPS的一些特性

• 可靠性:加密
• 完整性:MAC 验证
• 不可抵赖性:数字签名