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

攻击篇

Cross-Site Scripting(XSS)跨站脚本攻击

主要利用了盲目信任用户提交的内容 string->DOM

特点：

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

XSS类别

Stored XSS

• 恶意脚本被存储在数据库中
• 访问页面->读数据=被攻击
• 危害最大，对全部用户可见 Reflected XSS
• 不涉及数据库
• 从URL上攻击 DOM-based XSS
• 不需要服务器的参与
• 恶意攻击的发起 + 执行，全在浏览器完成

Reflected XSS VS DOM-based XSS

• Reflected XSS完成脚本注入的地方在服务端
• DOM-based XSS完成脚本注入的地方在浏览器

Mutation-based XSS

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

Cross-site request forgery(CSRF)

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

Injection(注入)

SQL Injection

• SQL参数(恶意注入)
• 参数->SQL，运行SQL code
• 获取其他数据，修改数据，删除数据

injection其他方式

• CLI
• OS command
• Server-Side Request Forquest(SSRF)，服务端伪造请求，严格而言，SSRF不是Injection，但是原理类似

Denial of Server(Dos)服务拒绝

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

ReDos：基于正则表达式的Dos

Distributed Dos(DDos)

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

传输层

中间人攻击

• 明文传输
• 信息篡改不可知
• 对方身份未验证

防御篇

XSS

• 永远不信任用户的提交内容
• 永远不要将用户提交内容直接转换成DOM，当成String

工具

前端：

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

服务端(Node)： DOMPurify

Content Security Policy(CSP)

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

CSRF

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

CSRF-token

其他方式

• if(请求来自合法页面)
• then(服务器接收过页面请求)
• then(服务器可以标识)

CSRF-iframe

解决： X-frame-Options:DENY/SAMEORIGIN

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

Injection

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

Dos

• 不用贪婪匹配
• 代码扫描+正则性能测试
• 不用用户提供的正则表达式