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

攻击篇

Cross-Site Scripting （XSS）

跨站脚本攻击：攻击者在网站上注入恶意的客户端代码。若受害者运行这些恶意代码，攻击者就可以突破网站的访问限制并冒充受害者。

主要利用：

用户的盲目信任
前端开发人员直接将用户输入转换为DOM【没有过滤掉恶意代码的动态内容被发送给 Web 用户。】

特点：

难以从UI感知
窃取用户信息（cookie/token）
绘制UI（如弹窗），诱骗用户点击/填写表单

XSS通常都会将cookies 或其他隐私信息发送给攻击者，将受害者重定向到由攻击者控制的网页，或是经由恶意网站在受害者的机器上进行其他恶意操作。

分类：

存储型XSS：恶意脚本被存在数据库中。一旦访问页面从数据库中读取数据，就会被攻击。危害最大，对全部用户可见。
反射型XSS：不涉及数据库，从url上完成攻击。恶意脚本在服务端进行注入。
基于DOM的XSS：不需要服务器的参与，恶意攻击的发起和执行，全部在浏览器中完成。
基于Mutation的XSS攻击：利用浏览器渲染DOM的特性，按浏览器进行攻击。
```
<noscript> <p title="</noscript><img src=x onerror=alert(1)">
```
上述片段src的属性不符合规范，触发onerror事件，然后执行XSS攻击，在chrome浏览器中被渲染成：
```
<noscript><p title="</noscript>
<img src="x" onerror="alert(1)">
```

Cross-site request forgery（CSRF）

跨站伪造请求：

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

进行跨站伪造请求最常见的方式是GET请求

<a href="https://bank.com/transfer?to=hacker&amount=100">点击抽奖</a>

<img style="display:none;" src="https://bank.com/transfer?to=hacker&amount=100">

Injection

最常见的注入攻击：SQL注入

SQL注入具体流程：SQL参数恶意注入HTTP请求，请求到达服务器端，服务器端从请求中读取参数，构造出SQL语句，执行SQL语句，操作数据。

其他injection：

CLI 命令行
OS command
Server-Side Request Forgery（SSRF）：服务端伪造请求

Denial of Service（DoS）

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

正则表达式的贪婪模式：最大可能匹配，即匹配到下一个字符不满足匹配规则为止。

非贪婪模式：最小可能匹配。只要一发现匹配，就返回结果，不要往下检查。将贪婪模式改为非贪婪模式，可以在量词符后面加一个问号。

ReDos：基于正则表达式的DoS

n次不行，试试n-1次——回溯，会使响应时间大大增加，接口吞吐量大大降低。

DDoS：Distributed DoS

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

攻击特点

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

SYN Flood示例

基于传输层的攻击

中间人攻击

中间人可能是恶意的网页、路由器、甚至是因特网服务提供商。中间人攻击有以下三个特点：

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

防御篇

XSS的防御

防御措施：永远不相信用户的提交内容，不要将用户提交内容直接转换为DOM。

防御XSS的现成工具：

对于前端而言：
- 主流框架都默认防御XSS
- google-closure-library
服务端（Node）
- DOMPurify

如果需求里面必须动态生成DOM：

string->DOM：需要对string进行转义
上传svg：对svg文件进行扫描，避免其中插入script标签
自定义跳转链接：过滤，避免链接传递js代码
自定义样式：避免css中传入js代码

同源策略 Same-origin Policy：两个url的协议、域名、端口号相等。一般而言对于HTTP请求，同源情况下🆗，但是不同源就涉及跨域问题，要看服务器配置

内容安全策略 Content Security Policy：哪些源（域名）被认为是安全的，来自安全源的脚本可以执行，否则直接抛错。服务器相应头部：

CSRF的防御

思路

1. 利用Origin+Refer 在请求头部判断伪造请求的来源是否异常，异常就限制（拒绝）其请求。因为同源请求中GET和HEAD请求不发送Origin字段，所以Refer字段应用更广泛

注意！CSRF中的iframe攻击是同源请求，防御方法：在服务器设置响应头部X-Frame-Options: DENY/SAMEORIGIN

2. token标识符

token往往和具体用户进行绑定。攻击者也可以是注册用户，避免被攻击者利用。

token应该确定一个过期时间【前向保密】

3. SameSite Cookie避免用户信息被携带

Chrome 51 开始，浏览器的 Cookie 新增加了一个SameSite属性限制第三方Cookie，用来防止 CSRF 攻击和用户追踪。

限制的是Cookie的domain属性和当前页面域名能否匹配 第三方Cookie和第一方Cookie

解决依赖Cookie的第三方服务： Set-Cookie: SameSite=None; Secure;

SameSite vs CORS

防御CSRF的正确方式：中间件

注入相关的防御

找到项目中查询SQL的地方，使用prepared statement，将SQL语句提前编译，导致攻击不能完成。

对其他注入的防御

DoS的防御

基于正则表达式的DoS：完善代码、代码扫描+正则性能测试、拒绝用户提供的正则

DDoS

传输层的防御

防御中间人

HTTP+TLS=HTTPS

HTTPS的特性：

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

TLS 1.2握手流程：

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

攻击篇