常见网络攻击

常见的网络攻击主要包括**跨站脚本攻击**（XSS）、**注入攻击**、**模糊测试**、**零日攻击**、**路径（目录）遍历攻击**、**分布式拒绝服务攻击**（DDos）、**中间人攻击**、**暴力破解攻击**、**使用未知代码或第三方代码攻击**、**网络钓鱼攻击**。

## 1 跨站脚本攻击（XSS）

### 1.1 含义

1. 跨站脚本攻击，Cross-Site Scripting，简称 XSS，是**一种代码注入攻击**，**攻击者通过在目标网站上注入恶意脚本**，**使之在用户的浏览器上运行**，**利用这些恶意脚本**，**攻击者可获取用户的敏感信息如 Cookie**、**SessionID 等**，**进而危害数据安全**。
2. XSS 的本质是**恶意代码未经过滤**，**与正常的代码混在一起**，**浏览器无法分辨哪些脚本是可信的**，**导致恶意脚本被执行**，而**由于直接在用户的终端执行**，**恶意代码能够直接获取用户的信息**，**或者利用这些信息冒充用户向网站发起攻击者定义的请求**。
3. **在部分情况下**，**由于输入的限制**，**注入的恶意脚本比较短**，**但可以通过引入外部的脚本**，**并由浏览器执行**，**来完成比较复杂的攻击策略**。
4. 在处理输入时，以下内容都不可信：
   1. **来自用户的 UGC 信息**。
   2. **来自第三方的链接**。
   3. **URL 参数**。
   4. **POST 参数**。
   5. **Refer**（可能来自不可信的来源）。
   6. **Cookie**（可能来自其他子域注入）。

### 1.2 分类

根据攻击的来源，XSS 攻击可分为**存储型**、**反射型**和**DOM 型**三种。

#### 1.2.1 存储型 XSS

1. 存储型 XSS 的攻击步骤为：
   1. **攻击者将恶意代码提交到目标网站的数据库中**。
   2. **用户打开目标网站时**，**网站服务端将恶意代码从数据库取出**，**拼接在 HTML 中返回给浏览器**。
   3. **用户浏览器接收到响应后解析执行**，**混在其中的恶意代码也被执行**。
   4. **恶意代码窃取用户数据并发送到攻击者的网站**，**或者冒充用户的行为**，**调用目标网站接口执行攻击者指定的操作**。
2. 这种攻击**常见于带有用户保存数据的网站功能**，如**论坛发帖**、**商品评论**、**用户私信**等。

#### 1.2.2 反射型 XSS

1. 反射型 XSS 的攻击步骤为：
   1. **攻击者构造特殊的 URL**，其中**包含恶意代码**。
   2. **用户打开带有恶意代码的 URL 时**，**网站服务端将恶意代码从 URL 中取出**，**拼接在 HTML 中返回给浏览器**。
   3. **用户浏览器接收到响应后解析执行**，**混在其中的恶意代码也被执行**。
   4. **恶意代码窃取用户数据并发送到攻击者的网站**，**或者冒充用户的行为**，**调用目标网站接口执行攻击者指定的操作**。
2. 反射型 XSS 和存储型 XSS 的区别是**存储型 XSS 的恶意代码在数据库里**，**反射型 XSS 的代码在 URL 里**。
3. 反射型 XSS 漏洞**常见于通过 URL 传递参数的功能**，如**网站搜索**、**跳转**等，由于**需要用户主动打开恶意的 URL 才能生效**，**攻击者往往会结合多种手段诱导用户点击**。
4. **POST 的内容也可以触发反射型 XSS**，**只不过其触发条件比较苛刻**（需要构造表单提交页面，并引导用户点击），**所以非常少见**。

#### 1.2.3 DOM 型 XSS

1. DOM 型 XSS 的攻击步骤为：
   1. **攻击者构造特殊的 URL**，其中**包含恶意代码**。
   2. **用户打开带有恶意代码的 URL**。
   3. **用户浏览器接收到响应后解析执行**，**前端 JavaScript 取出 URL 中的恶意代码并执行**。
   4. **恶意代码窃取用户数据并发送到攻击者的网站**，**或者冒充用户的行为**，**调用目标网站接口执行攻击者指定的操作**。
2. DOM 型 XSS 跟前两种 XSS 的区别是**DOM 型 XSS 攻击中**，**取出和执行恶意代码由浏览器前端完成**，**属于前端 JavaScript 自身的安全漏洞**，而**其他两种 XSS 都属于服务端的安全漏洞**。

### 1.3 预防

通过前面的介绍可以得知，XSS 攻击有两大要素：

1. **攻击者提交恶意代码**。
2. **浏览器执行恶意代码**。

#### 1.3.1 输入过滤

1. 针对第一个要素，我们是否能够在用户输入的过程，过滤掉用户输入的恶意代码呢：
   1. **在用户提交时**，**由前端过滤输入**，**然后提交到后端**，这样做是否可行呢：
      1. 答案是**不可行**的，因为**一旦攻击者绕过前端过滤**，**直接构造请求**，**就可以提交恶意代码了**。
   2. 那么，换一个过滤时机，**后端写入数据库前**，**对输入进行过滤**，**然后把安全的内容返回给前端**，这样是否可行呢：
      1. 我们举一个例子，一个正常的用户输入了`5 < 7` 这个内容，在写入数据库前，被转义，变成了`5 &alt; 7`。
      2. 问题是，在提交阶段我们并不确定内容要输出到哪里：
         1. **用户输入的内容可能同时是提供给前端和客户端**，而**一旦经过了 `escapeHTML()`**，**客户端显示的内容就变成了乱码**（`5 &alt; 7`）。
         2. **在前端中**，**不同的位置所需的编码也不同**：
            1. 当`5 &alt; 7`**作为 HTML 拼接页面**时，**可以正常显示**。
            2. 当`5 &alt; 7`**通过 Ajax 返回**，然后**赋值给 JavaScript 的变量**时，**前端得到的字符串就是转义后的字符**，这个内容**不能直接用于 Vue 等模板的展示**，**也不能直接用于内容长度计算**，**不能用于标题**、等。
2. 所以，**输入侧过滤能够在某些条件下解决特定 XSS 问题**，**但会引入很大的不确定性和乱码问题**，**在防范 XSS 攻击时应避免此类方法**。

#### 1.3.2 防止浏览器执行恶意代码

既然输入过滤并非完全可靠，我们就要通过**防止浏览器执行某些恶意代码**来防范 XSS，这部分分为两类：

1. **防止 HTML 出现注入**。
2. **防止 JavaScript 执行时**，**执行恶意代码**。

##### 1.3.2.1 防止存储型和反射型 XSS

1. 存储型和反射型 XSS 都是**在服务端取出恶意代码后**，**插入到响应 HTML 里的**，**攻击者刻意编写的数据被内嵌到代码中**，**被浏览器所执行**。
2. 预防这两种漏洞，有两种常见做法：
   1. **改成纯前端渲染**，**把代码和数据分隔开**。
   2. **对 HTML 做充分转义**。

###### 1.3.2.1.1 纯前端渲染

1. 纯前端渲染的过程为：
   1. **浏览器先加载一个静态 HTML**，此**HTML 中不包含任何跟业务相关的数据**。
   2. 然后**浏览器执行 HTML 中的 JavaScript**。
   3. **JavaScript 通过 Ajax 加载业务数据**，**调用 DOM API 更新到页面上**。
2. **在前端渲染过程中**，我们**会明确的告诉浏览器下面要设置的内容是文本**（`.innerText`），**还是属性**（`.setAttribute`），**还是样式**（`.style`）等等，**浏览器不会被轻易的欺骗**，**执行预期外的代码了**。
3. 但**纯前端渲染还需注意避免 DOM 型 XSS 漏洞**（例如`onload` 事件和`href` 中的`javascript:xxx` 等）。
4. 在很多**内部**、**管理系统**中，**采用纯前端渲染是非常合适的**，但**对于性能要求较高**，或**有 SEO 需求的页面**，我们**仍然要面对拼接 HTML 的问题**。

###### 1.3.2.1.2 转义 HTML

1. 如果**拼接 HTML 是必要的**，就需要**采用合适的转义库**，**对 HTML 模板的各处插入点进行充分的转义**。
2. **常用的模板引擎**，如`doT.js`、`ejs`、`FreeMarker` 等，对于 HTML 转义通常只有一个规则，就是把`&`、`<`、`>`、`"`、`'`、`/` 这几个字符转义掉，确实**能起到一定的 XSS 防护作用**，**但并不完善**。
3. 所以要完善 XSS 防护措施，我们要**使用更完善更细致的转义策略**，例如 Java 工程里，常用的转义库为`org.owasp.encoder`。

##### 1.3.2.2 预防 DOM 型 XSS 攻击

1. **DOM 型 XSS 攻击**，**实际上就是网站前端 JavaScript 代码本身不够严谨**，**把不可信的数据当做代码执行了**。
2. **在使用 `.innerHTML()`**、`.outerHTML()`、`document.write()`**时要特别小心**，**不要把不可信的数据作为 HTML 插到页面上**，**而要尽量使用 `.textContent()`**、`.setAttribute()`**等**。
3. **DOM 中的内联事件监听器**，如`location`、`onclick`、`onerror`、`onload`、`onmouseover`**等**，`<a>`**标签的 `href` 属性**，**JavaScript 的 `eval()`**、`setTimeout()`、`setInterval()`**等**，**都能把字符串作为代码运行**，**如果不可信的数据拼接到字符串中传递给这些 API**，**很容易产生安全隐患**，**请勿避免**。

#### 1.3.3 其他防范措施

虽然在**渲染页面和执行 JavaScript 时**，通过**谨慎的转义可以防止 XSS 的发生**，但**完全依靠开发的谨慎仍然是不够的**，以下介绍一些通用的方案，可以降低 XSS 带来的风险和后果。

##### 1.3.3.1 Content Security Policy

1. 严格的 CSP 在 XSS 的防范中可以起到以下的作用：
   1. **禁止加载外域代码**，**防止复杂的攻击逻辑**。
   2. **禁止外域提交**，**网站被攻击后**，**用户的数据不会泄露到外域**。
   3. **禁止内联脚本执行**。
   4. **禁止未授权的脚本执行**。

##### 1.3.3.2 控制输入内容长度

1. **对于不受信任的输入**，**都应该限定一个合理的长度**，**虽然无法阻止 XSS 的发生**，**但是可以增加 XSS 攻击的难度**。

## 2 注入攻击

注入攻击包括 SQL 注入攻击和代码注入攻击两种，下面主要以 SQL 注入攻击为例进行介绍。

### 2.1 SQL 注入攻击

#### 2.1.1 含义

1. **SQL 注入是发生于应用程序与数据库层的安全漏洞**，**本质是代码和数据未分离**，**通过在用户可控参数中注入 SQL 语法**，**程序未对输入的指令进行合法性判断**，**注入进去的恶意指令就会被数据库服务器误认为是正常的 SQL 指令而运行**，**破坏原有 SQL 结构**，**达到编写程序时意料之外结果的攻击行为**。

#### 2.1.2 分类

1. 按照**参数类型**可分为两种，分比为**数字型**和**字符型**：
   1. **数字型**：**发生注入点的参数为整数**，比如 ID、num、page 等。
   2. **字符型**：**发生注入点的参数为字符串**，**字符型注入需要引号来闭合**。
2. 按照**数据库返回的结果**可分为**回显注入**、**报错注入**、**盲注**：
   1. **回显注入**：可以**直接在存在注入点的当前页面中获取返回结果**。
   2. **报错注入**：**程序将数据库的返回错误信息直接显示在页面上**，虽然**没有返回数据库的查询结果**，但是**可以构造一些报错语句从错误信息中获取想要的结果**。
   3. **盲注**：**程序后端屏蔽了数据库的错误信息**，**没有直接显示结果也没有报错信息**，**只能通过数据库的逻辑和延时函数来判断注入的结果**。

#### 2.1.3 危害

1. **泄露数据库中的敏感数据给未授权用户**，SQL 注入漏洞**可以绕过一些认证**，**导致用户名**、**密码等用户信息的泄露**。
2. 通过一些**精心构造的注入手法**，可能**会获取到管理员的后台密码**，甚至**获得非法提权和用户系统的权限**。
3. **数据结构被黑客探知**，**得以做进一步攻击**。
4. 黑客可能**在系统中添加恶意链接**、**恶意代码等**，**进行恶意篡改**。

#### 2.1.4 预防

1. **检查变量数据类型和格式**：
   1. 如果我们的 SQL 语句是类似`where id = {$id}` 这种形式，数据库里**所有的 `id` 都是数字**，那么就应该**在 SQL 被执行前**，**检查确保变量 `id` 是 `int` 类型**，如果是**接收邮箱**，那就应该**检查并严格确保变量一定是邮箱的格式**，其他的类型比如日期、时间等也是一个道理。
   2. 总结起来，也就是说**只要有固定格式的变量**，**在 SQL 语句执行前**，**应该严格按照固定格式去检查**，**确保变量是我们想要的格式**，**这样很大程度上可以避免 SQL 注入攻击**。
2. **过滤特殊符号**：
   1. **对于无法确定固定格式的变量**，**一定要进行特殊符号过滤或转义处理**。
   2. **以 PHP 为例**，**通常是采用 `addslashes` 函数**，他会**在指定的预定义字符前添加反斜杠转义**，这些预定义的字符是**单引号**（`'`）、**双引号**（`"`）、**反斜杠**（`\`）、**NULL**。
3. **绑定变量**，**使用预编译语句**：
   1. 一般情况下**一条 SQL 语句的执行要经过语义解析**、**制定执行计划**、**执行并返回结果**。
   2. **预编译是指把要执行的 SQL 语句先进行一个解析**，**解析语法**、**确定查询范围**、**返回结果类型**，**也就是确定了查询的方式**，**把命令和参数进行了分离**，**使用预编译的 SQL 语句来进行查询时直接进行执行计划**，**不会再进行语义解析**，**也就是数据库不会再进行编译**，**而是直接执行编译过的 SQL**，**只需要替换掉参数部分就可以了**，因此**使用预编译语句能够防止 SQL 注入**。
   3. 比如`SELECT id, title, author, content FROM blog WHERE id = '?'`，如果**经过了预编译**，那么这个时候**不管 `?` 输入的是什么**，**都不会调用编译器来解析 SQL 指令了**，**而是只替换掉参数的位置**，**然后执行编译好的查询**，**尽管输入 `1 = ' or '1 = 1'--`**，**也只会把这一部分当做参数替换掉 `?` 的位置**，**查找字符串**，**而不会再解析 `or` 这个语法了**。

## 3 中间人攻击

### 3.1 含义

![](/media/202107/2021-07-20_0953530.15541465257353382.png "中间人攻击（https://blog.pradeo.com/man-in-the-middle-attack）（来源：知乎 @顾伊凡 YGY）")

1. 中间人攻击（Man-in-the-MiddleAttack，简称 MITM 攻击）是**一种间接的入侵攻击**，这种攻击模式是**通过各种技术手段将受入侵者控制的一台计算机虚拟放置在网络连接中的两台通信计算机之间**，这台计算机就成为**中间人**。
2. 中间人攻击的基本步骤为：
   1. **某网站有用于非对称加密的公钥 A**、**私钥 A'**。
   2. **浏览器向网站服务器请求**，**服务器把公钥 A 明文传输给浏览器**。
   3. **中间人劫持到公钥 A**，**保存下来**，**把数据包中的公钥 A 替换成自己伪造的公钥 B**（他当然也拥有公钥 B 对应的私钥 B）。
   4. **浏览器生成一个用于对称加密的密钥 X**，**用公钥 B**（浏览器无法得知公钥被替换了）**加密后传输给服务器**。
   5. **中间人劫持后用私钥 B'解密得到密钥 X**，**再用公钥 A 加密后传输给服务器**。
   6. **服务器拿到后用私钥 A'解密得到密钥 X**。
3. 这样**在双方都不会发现异常的情况下**，**中间人**通过一套狸猫换太子的操作，**掉包了服务器传来的公钥**，**进而得到了密钥 X**，**根本原因是浏览器无法确认收到的公钥是不是网站自己的**。

### 3.2 预防

预防的基本思想就是解决上面提到的问题**如何证明浏览器收到的公钥一定是该网站的公钥**，这里就要用到**数字证书**。

#### 3.2.1 数字证书

##### 3.2.1.1 什么是数字证书

1. **网站使用 HTTPS 前**，**需要向 CA 机构申领一份数字证书**，**数字证书里含有证书持有者信息**、**公钥信息等**。
2. **服务器把证书传输给浏览器**，**浏览器从证书里获取公钥就行了**，**证书就如身份证**，**证明该公钥对应该网站**。

##### 3.2.1.2 如何防止数字证书被篡改

![](/media/202107/2021-07-20_1039340.9717877675556482.png "数字签名的生成与验证（来源：知乎 @顾伊凡 YGY）")

1. 我们**把证书原本的内容生成一份签名**，**比对证书内容和签名是否一致就能判别是否被篡改**，这就是**数字证书的防伪技术**，这里的签名就叫**数字签名**。
2. 数字签名的制作过程为：
   1. **CA 机构拥有非对称加密的四要和公钥**。
   2. **CA 机构对证书明文数据 T 进行 Hash**。
   3. **对 Hash 后的值用私钥加密**，**得到数字签名 S**。
3. **明文和数字签名共同组成了证书**，**这样一份数字证书就可以颁发给网站了**。
4. 浏览器拿到服务器传来的数字证书后，需要验证他是不是真的（有没有被篡改、掉包），具体的验证过程如下：
   1. **拿到证书**，**得到明文 T**，**签名 S**。
   2. **用 CA 机构的公钥对 S 解密**（由于是浏览器信任的机构，所以浏览器保有他的公钥，详情见下文），**得到 S'**。
   3. **用证书里指明的 Hash 算法对明文 T 进行 Hash 得到 T'**。
   4. 通过以上步骤，**T'应该等于 S'**，**除非明文或签名被篡改**，所以此时**通过比较 S'是否等于 T'来判断证书是否可信**。

##### 3.2.1.3 中间人有可能篡改改证书吗

1. 假设**中间人篡改了证书的原文**，由于他**没有 CA 机构的私钥**，所以**无法得到此时加密后的签名**，也就**无法相应地篡改签名**。
2. **浏览器收到该证书后发现原文和签名解密后的值不一致**，则**说明证书已被篡改**，**证书不可信**，从而**终止向服务器传输信息**，**防止信息泄露给中间人**。

##### 3.2.1.4 中间人有可能把证书掉包吗

1. 假设有**另一个网站 B 也拿到了 CA 机构认证的证书**，他**想劫持网站 A 的信息**，于是他**成为中间人拦截到了 A 传输给浏览器的证书**，然后**替换成自己的证书**，**传给浏览器**，之后**浏览器就会错误地拿到 B 的证书里的公钥**了，这**看起来会导致中间人攻击**。
2. 而**实际上**，**这并不会发生**，因为**证书里包含了网站 A 的信息**，**包括域名**，**浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了**。

##### 3.2.1.5 为什么制作签名时要 Hash 一次

1. 这里主要是**性能问题**，因为**非对称加密效率较差**，**证书信息一般较长**，**比较耗时**，而**Hash 得到的是固定长度的信息**（比如用 MD5 算法 Hash 后可以得到固定 128 位的值），这样**加解密就快很多**。
2. 当然也有**安全**上的原因，这部分可参考[Why hash the message before signing it with RSA?](https://crypto.stackexchange.com/questions/12768/why-hash-the-message-before-signing-it-with-rsa/12780)

##### 3.2.1.6 怎么证明 CA 机构的公钥是可信的

![](/media/202107/2021-07-20_1122280.016306424280829956.png)

1. **操作系统**、**浏览器本身会预装一些他们信任的根证书**，**如果其中会有 CA 结构的根证书**，**这样就可以拿到他对应的可信公钥了**。
2. 实际上**证书之间的认证也可以不止一层**，可以**A 信任 B**、**B 信任 C**，以此类推，我们把他叫做**信任链**或**数字证书链**，也就是**一连串的数字证书**，**以根证书为起点**，**透过层层信任**，**使终端实体证书的持有者可以获得转授的信任**，**以证明身份**。
3. 我们以前遇到过网站访问不了，提示需要安装证书的情况，这里**安装的就是根证书**，说明浏览器不认可给这个网站颁发证书的机构，那么我们就得手动下载安装该机构的根证书（风险自己承担），**安装后**，**我们就有了他的公钥**，**就可以用他验证服务器发来的证书是否可信了**。

## 参考文献

1. [10 种常见网站安全攻击手段及防御方法](https://www.secrss.com/articles/29803)。
2. [前端安全系列（一）：如何防止 XSS 攻击？](https://tech.meituan.com/2018/09/27/fe-security.html)
3. [SQL 注入攻击原理是什么？如何防护 SQL 注入？](https://dun.163.com/news/p/12cbbbc06dc1475d883ba9fb2386d6cc)
4. [1、sql 注入的原理与分类](https://www.kanxue.com/book-6-110.htm)。
5. [Web 安全之 SQL 注入攻击技巧与防范（转）](https://www.cnblogs.com/ajianbeyourself/p/13298510.html)。
6. [【面经】预编译为什么可以防止 sql 注入，mybatis 是如何预防的](https://blog.csdn.net/weixin_45525005/article/details/108124612)。
7. [中间人攻击](https://baike.baidu.com/item/%E4%B8%AD%E9%97%B4%E4%BA%BA%E6%94%BB%E5%87%BB/1739730)。
8. [彻底搞懂 HTTPS 的加密原理](https://zhuanlan.zhihu.com/p/43789231)。