24、API 注入攻击：XSS、XAS、SQL 与 NoSQL 注入解析

API 注入攻击：XSS、XAS、SQL 与 NoSQL 注入解析

在当今数字化的时代，API 的安全性至关重要。各种注入攻击，如跨站脚本攻击（XSS）、跨 API 脚本攻击（XAS）、SQL 注入和 NoSQL 注入，对 API 安全构成了严重威胁。本文将详细介绍这些攻击的原理、检测方法和应对策略。

跨站脚本攻击（XSS）

XSS 是一种经典的 Web 应用程序漏洞，已经存在了数十年。对于 API 安全而言，XSS 同样是一个不可忽视的威胁，尤其是当通过 API 提交的数据与浏览器中的 Web 应用程序进行交互时。

在 XSS 攻击中，攻击者通过提交用户输入，将恶意脚本插入到网站中，这些输入会被用户的浏览器解释为 JavaScript 或 HTML。常见的 XSS 攻击会在网页中注入弹出消息，引导用户点击链接，从而将其重定向到攻击者的恶意内容。

在 Web 应用程序中，执行 XSS 攻击通常是将 XSS 有效负载注入到网站的不同输入字段中。对于 API 的 XSS 测试，目标是找到一个允许提交与前端 Web 应用程序交互的请求的端点。如果应用程序没有对请求输入进行清理，那么 XSS 有效负载可能会在用户下次访问应用程序页面时执行。

以下是一些 XSS 有效负载的示例：

<script>alert("xss")</script>
<script>alert(1);</script>
<%00script>alert(1)</%00script>
SCRIPT>alert("XSS");///SCRIPT>

这些脚本都试图在浏览器中触发警报。不同的有效负载是为了绕过用户输入验证。通常，Web 应用程序会通过过滤不同的字符或防止字符发送来防止 XSS 攻击。有时，简单地添加空字节（%00）或大写不同的字母可以绕过 Web 应用程序的保护。

对于特定于 API 的 XSS 有效负载，可以参考以下资源：
- Payload Box XSS payload list：包含超过 2700 个可能触发成功 XSS 攻击的 XSS 脚本（https://github.com/payloadbox/xss-payload-list）。
- Wfuzz wordlist：一个较短的单词列表，可用于快速检查 XSS（https://github.com/xmendez/wfuzz/tree/master/wordlist）。
- NetSec.expert XSS payloads：包含不同 XSS 有效负载的解释及其用例，有助于更好地理解每个有效负载并进行更精确的攻击（https://netsec.expert/posts/xss-in-2020）。

如果 API 实施了某种安全措施，许多 XSS 尝试可能会产生类似的结果，如 405 错误输入或 400 错误请求。但要密切关注异常情况。如果发现某些请求得到了成功响应，尝试刷新浏览器中的相关网页，查看 XSS 尝试是否对其产生了影响。

在审查 Web 应用程序以寻找潜在的 API XSS 注入点时，应寻找包含客户端输入并用于在 Web 应用程序中显示信息的请求。以下类型的请求是主要的候选对象：
- 更新用户个人资料信息
- 更新社交媒体“点赞”信息
- 更新电子商务商店产品
- 发布到论坛或评论区

可以在 Web 应用程序中搜索请求，然后用 XSS 有效负载对其进行模糊测试。审查结果，查找异常或成功的状态代码。

以下是 XSS 攻击的简单流程图：

graph TD;
    A[攻击者构造 XSS 有效负载] --> B[通过 API 提交有效负载];
    B --> C{应用程序是否清理输入};
    C -- 否 --> D[用户访问页面，执行 XSS 脚本];
    C -- 是 --> E[阻止 XSS 攻击];

跨 API 脚本攻击（XAS）

XAS 是跨 API 执行的跨站脚本攻击。例如，假设 hAPI Hacking 博客的侧边栏由 LinkedIn 新闻源提供支持。博客与 LinkedIn 有 API 连接，当 LinkedIn 新闻源添加新帖子时，它也会出现在博客侧边栏中。如果从 LinkedIn 接收的数据没有进行清理，那么添加到 LinkedIn 新闻源中的 XAS 有效负载就有可能被注入到博客中。

要测试这种情况，可以发布包含 XAS 脚本的 LinkedIn 新闻源更新，并检查它是否在博客上成功执行。

XAS 比 XSS 更复杂，因为 Web 应用程序必须满足特定条件才能使 XAS 攻击成功。Web 应用程序必须对通过其自身 API 或第三方 API 提交的数据进行较差的清理。API 输入还必须以能够启动脚本的方式注入到 Web 应用程序中。此外，如果通过第三方 API 攻击目标，可能会受到其平台允许的请求数量的限制。

除了测试第三方 API 的 XAS 漏洞外，还可以在提供者的 API 向其 Web 应用程序添加内容或进行更改的情况下寻找该漏洞。例如，hAPI Hacking 博客允许用户通过浏览器或向 API 端点 /api/profile/update 发送 POST 请求来更新用户个人资料。博客安全团队可能只专注于保护博客免受通过 Web 应用程序提供的输入的攻击，而完全忽略了 API 作为威胁向量。

在这种情况下，可以尝试发送一个典型的个人资料更新请求，在 POST 请求的一个字段中包含有效负载：

POST /api/profile/update HTTP/1.1
Host: hapihackingblog.com
Authorization: hAPI.hacker.token
Content-Type: application/json
{
    "fname": "hAPI",
    "lname": "Hacker",
    "city": "<script>alert("xas")</script>"
}

如果请求成功，在浏览器中加载网页，查看脚本是否执行。如果 API 实施了输入验证，服务器可能会发出 HTTP 400 错误请求响应，阻止发送脚本作为有效负载。在这种情况下，可以尝试使用 Burp Suite 或 Wfuzz 发送大量的 XAS/XSS 脚本，以尝试找到不会导致 400 响应的脚本。

另一个有用的 XAS 技巧是尝试更改 Content-Type 标头，诱使 API 接受 HTML 有效负载以启动脚本：

Content-Type: text/html

以下是 XAS 攻击的简单流程图：

graph TD;
    A[攻击者构造 XAS 有效负载] --> B[通过第三方 API 提交有效负载];
    B --> C{第三方 API 数据是否清理};
    C -- 否 --> D[数据传输到目标 Web 应用程序];
    D --> E{目标 Web 应用程序是否清理输入};
    E -- 否 --> F[执行 XAS 脚本];
    C -- 是 --> G[阻止 XAS 攻击];
    E -- 是 --> G;

SQL 注入

SQL 注入是最著名的 Web 应用程序漏洞之一，它允许远程攻击者与应用程序的后端 SQL 数据库进行交互。通过这种访问，攻击者可以获取或删除敏感数据，如信用卡号码、用户名、密码等。此外，攻击者还可以利用 SQL 数据库功能绕过身份验证，甚至获得系统访问权限。

这种漏洞已经存在了数十年，在 API 出现新的注入攻击方式之前，它似乎有所减少。然而，API 防御者一直热衷于检测和防止通过 API 进行的 SQL 注入。因此，这些攻击不太可能成功。实际上，发送包含 SQL 有效负载的请求可能会引起目标安全团队的注意，甚至导致授权令牌被禁止。

幸运的是，可以通过不太明显的方式检测 SQL 数据库的存在。在发送请求时，尝试请求意外的值。例如，查看 Pixi 端点的 Swagger 文档，Pixi 期望消费者在请求体中提供特定的值，“id”值应为数字，“name”应为字符串，“is_admin”应为布尔值（如 true 或 false）。可以尝试在期望数字的地方提供字符串，在期望字符串的地方提供数字，在期望布尔值的地方提供数字或字符串。如果 API 期望一个小数字，可以发送一个大数字；如果期望一个短字符串，可以发送一个长字符串。通过请求意外的值，可能会发现开发人员没有预料到的情况，数据库可能会在响应中返回错误。这些错误通常很详细，会揭示数据库的敏感信息。

当寻找用于数据库注入的目标请求时，应寻找允许客户端输入并可能与数据库交互的请求。在 Pixi 的示例中，收集的用户信息很可能会存储在数据库中，PUT 请求允许更新这些信息，因此该请求是数据库注入攻击的一个很好的目标。除了进行明显的请求外，还应该对所有地方的所有内容进行模糊测试，因为可能会在不太明显的请求中发现数据库注入弱点的迹象。

以下是两种简单的测试应用程序是否易受 SQL 注入攻击的方法：

手动提交元字符

元字符是 SQL 视为函数而非数据的字符。例如， -- 是一个元字符，它告诉 SQL 解释器忽略后续输入，因为它是注释。如果 API 端点没有从 API 请求中过滤 SQL 语法，那么从 API 传递到数据库的任何 SQL 查询都将执行。

以下是一些可能导致问题的 SQL 元字符：

'
''
;%00
--
-- -
""
;
' OR '1
' OR 1 -- -
" OR "" = "
" OR 1 = 1 -- -
' OR '' = '
OR 1=1

这些符号和查询都旨在给 SQL 查询带来问题。像 ;%00 这样的空字节可能会导致详细的 SQL 相关错误作为响应发送。 OR 1=1 是一个条件语句，意味着“或者以下语句为真”，它会使给定的 SQL 查询条件为真。单引号和双引号在 SQL 中用于表示字符串的开始和结束，因此引号可能会导致错误或特殊状态。

例如，后端可能使用以下 SQL 查询来处理 API 身份验证过程：

SELECT * FROM userdb WHERE username = 'hAPI_hacker' AND password = 'Password1!'

如果在密码字段中提供 ' OR 1=1-- - ，SQL 查询可能会变为：

SELECT * FROM userdb WHERE username = 'hAPI_hacker' OR 1=1-- -

这将被解释为选择一个条件为真的用户，并且跳过密码验证，因为密码验证部分已被注释掉。查询不再检查密码，用户将被授予访问权限。这种攻击可以同时应用于用户名和密码字段。

使用 SQLmap

自动测试 API 是否存在 SQL 注入的一种常用方法是在 Burp Suite 中保存潜在的易受攻击的请求，然后使用 SQLmap 对其进行测试。可以通过对请求中的所有潜在输入进行模糊测试，并审查响应中的异常情况来发现潜在的 SQL 弱点。在 SQL 漏洞的情况下，这种异常通常是详细的 SQL 响应，如“SQL 数据库无法处理您的请求…”。

保存请求后，启动 SQLmap（Kali 系统的标准包之一，可以通过命令行运行）。SQLmap 命令示例如下：

$ sqlmap -r /home/hapihacker/burprequest1 -p password

-r 选项用于指定保存请求的路径， -p 选项用于指定要测试 SQL 注入的具体参数。如果不指定要攻击的参数，SQLmap 将依次攻击每个参数。这对于对简单请求进行全面攻击很有用，但对于有许多参数的请求可能会非常耗时。SQLmap 会一次测试一个参数，并告知某个参数是否不太可能存在漏洞。要跳过一个参数，可以使用 CTRL-C 快捷键调出 SQLmap 的扫描选项，然后使用 n 命令移动到下一个参数。

当 SQLmap 表明某个参数可能可注入时，可以尝试利用它。有两个主要的下一步操作，可以选择先进行哪一个：转储所有数据库条目或尝试获得系统访问权限。

要转储所有数据库条目，可以使用以下命令：

$ sqlmap -r /home/hapihacker/burprequest1 -p vuln-param –dump-all

如果不想转储整个数据库，可以使用 --dump 命令指定要转储的具体表和列：

$ sqlmap -r /home/hapihacker/burprequest1 -p vuln-param –dump -T users -C password -D helpdesk

这个示例尝试转储 helpdesk 数据库中 users 表的 password 列。当命令成功执行时，SQLmap 将在命令行上显示数据库信息，并将信息导出到 CSV 文件。

有时，SQL 注入漏洞允许上传一个 Web shell 到服务器，然后执行该 shell 以获得系统访问权限。可以使用 SQLmap 的命令自动尝试上传 Web shell 并执行它：

$ sqlmap -r /home/hapihacker/burprequest1 -p vuln-param –os-shell

这个命令将尝试利用易受攻击参数中的 SQL 命令访问权限来上传和启动 shell。如果成功，将获得一个与操作系统的交互式 shell。

也可以使用 os-pwn 选项尝试使用 Meterpreter 或 VNC 获得 shell：

$ sqlmap -r /home/hapihacker/burprequest1 -p vuln-param –os-pwn

以下是 SQL 注入测试的流程图：

graph TD;
    A[发送意外请求值] --> B{数据库是否返回错误};
    B -- 是 --> C[使用 SQLmap 测试];
    C --> D{是否发现可注入参数};
    D -- 是 --> E[选择转储数据或获取系统访问];
    B -- 否 --> F[未发现 SQL 注入风险];
    D -- 否 --> F;

NoSQL 注入

由于 NoSQL 数据库与 API 常见的架构设计具有良好的扩展性，API 通常会使用 NoSQL 数据库。因此，发现 NoSQL 数据库的可能性可能比 SQL 数据库更高。而且，NoSQL 注入技术不如 SQL 注入技术那么广为人知，这可能使得更容易发现 NoSQL 注入漏洞。

在寻找 NoSQL 注入漏洞时，要记住不同的 NoSQL 数据库之间的共性不如不同的 SQL 数据库之间多。NoSQL 是一个统称，表示数据库不使用 SQL。因此，这些数据库具有独特的结构、查询模式、漏洞和利用方法。实际上，会进行许多类似的攻击并针对类似的请求，但实际的有效负载会有所不同。

以下是一些可以在 API 调用中发送以操纵数据库的常见 NoSQL 元字符：

$gt
{"$gt":""}
{"$gt":-1}
$ne
{"$ne":""}
{"$ne":-1}
$nin
{"$nin":1}
{"$nin":[1]}
|| '1'=='1
//
||'a'\\'a
'||'1'=='1';//
'/{}:
'"\;{}
'"\/$[].>
{"$where":  "sleep(1000)"}

其中， $gt 是 MongoDB NoSQL 查询操作符，用于选择大于提供值的文档； $ne 查询操作符用于选择值不等于提供值的文档； $nin 操作符是“不在”操作符，用于选择字段值不在指定数组中的文档。列表中的许多其他符号旨在导致详细的错误或其他有趣的行为，如绕过身份验证或等待 10 秒。

任何异常情况都应该促使对数据库进行彻底测试。例如，在发送 API 身份验证请求时，密码错误的一种可能响应是：

HTTP/1.1 202 Accepted
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
{"message":"sorry pal, invalid login"}

注意，失败的响应状态码为 202 Accepted，并包含失败的登录消息。对 /api/login 端点进行某些符号的模糊测试可能会导致详细的错误消息。例如，将有效负载 '"\;{} 作为密码参数发送可能会导致以下 400 Bad Request 消息：

HTTP/1.1 400 Bad Request
X-Powered-By: Express
--snip--
SyntaxError: Unexpected token ; in JSON at position 54<br> &nbsp; &nbsp;at JSON.parse 
(<anonymous>)<br> [...]

虽然错误消息没有表明使用的数据库，但这种独特的响应表明该请求在处理某些类型的用户输入时存在问题，这可能是它潜在易受注入攻击的迹象。

可以使用 Postman 进行注入攻击尝试。发送包含 NoSQL 模糊测试有效负载的各种请求，可能会得到 202 Accepted 响应。例如，嵌套的 NoSQL 命令 {"$gt":""} 和 {"$ne":""} 有效负载会导致成功注入并绕过身份验证。

以下是 NoSQL 注入测试的简单流程图：

graph TD;
    A[发送包含 NoSQL 元字符的请求] --> B{是否出现异常响应};
    B -- 是 --> C[进行更多测试和利用];
    B -- 否 --> D[未发现 NoSQL 注入风险];

综上所述，API 的注入攻击是一个复杂而严峻的安全问题。无论是 XSS、XAS、SQL 注入还是 NoSQL 注入，都需要我们保持警惕，采用合适的检测方法和防御策略，以确保 API 的安全性。在实际应用中，要不断学习和更新知识，及时发现和修复潜在的安全漏洞。

API 注入攻击：XSS、XAS、SQL 与 NoSQL 注入解析

各类注入攻击对比总结

为了更清晰地了解 XSS、XAS、SQL 注入和 NoSQL 注入的特点，我们可以通过以下表格进行对比：
| 攻击类型 | 攻击原理 | 攻击难度 | 常见利用场景 | 检测方法 |
| — | — | — | — | — |
| XSS | 攻击者通过提交用户输入，将恶意脚本插入网站，被浏览器解释为 JavaScript 或 HTML 执行 | 相对容易，有较多公开的有效负载 | 涉及用户输入并显示在网页上的场景，如用户资料更新、评论区等 | 观察请求响应状态码，使用 XSS 有效负载进行模糊测试 |
| XAS | 跨 API 执行的跨站脚本攻击，依赖第三方 API 数据未清理 | 较复杂，需满足多个条件 | 与第三方 API 有数据交互的 Web 应用，如新闻源集成 | 发布含 XAS 脚本的数据，检查是否在目标网站执行 |
| SQL 注入 | 远程攻击者通过构造恶意 SQL 查询与后端 SQL 数据库交互 | 有一定难度，防御者警惕性高 | 涉及数据库查询的 API 请求，如用户认证、数据更新等 | 发送意外请求值触发数据库错误，使用 SQLmap 测试 |
| NoSQL 注入 | 利用 NoSQL 数据库独特结构和查询模式，构造恶意请求操纵数据库 | 相对容易，技术普及度低 | 使用 NoSQL 数据库的 API，如 MongoDB 存储的用户信息 | 发送 NoSQL 元字符，观察异常响应 |

防御策略建议

针对上述注入攻击，以下是一些有效的防御策略：
1. 输入验证和清理
- 对所有来自客户端的输入进行严格验证，确保输入符合预期的数据类型和格式。
- 使用白名单过滤，只允许特定的字符和格式通过。
- 对输入进行清理，去除可能的恶意脚本和 SQL 元字符。
2. 安全配置 API 端点
- 限制 API 端点的访问权限，仅允许授权的用户和应用程序访问。
- 定期审查 API 端点的配置，确保没有不必要的功能和权限开放。
3. 更新和维护安全补丁
- 及时更新 API 框架、数据库管理系统和相关软件的安全补丁，修复已知的安全漏洞。
- 建立安全漏洞监测机制，及时发现和处理新出现的安全威胁。
4. 安全意识培训
- 对开发人员和运维人员进行安全意识培训，提高他们对注入攻击的认识和防范能力。
- 制定安全开发规范，确保在开发过程中遵循安全最佳实践。

案例分析

为了更好地理解这些注入攻击的实际影响，我们来看一个简单的案例。假设一个电商网站的 API 存在 SQL 注入漏洞。攻击者发现该网站的用户登录接口没有对输入进行严格的过滤，于是构造了如下恶意请求：

POST /api/login HTTP/1.1
Host: example-ecommerce.com
Content-Type: application/x-www-form-urlencoded

username=admin' OR '1'='1 -- &password=any

在这个请求中，攻击者利用 ' OR '1'='1 -- 这个 SQL 元字符组合，绕过了用户名和密码的验证。由于该 API 没有过滤 SQL 语法，这个恶意请求被传递到数据库并执行，攻击者成功登录了管理员账户。

攻击者登录后，可以进行一系列恶意操作，如查看用户的敏感信息、修改商品价格、删除订单等，给电商网站带来了严重的损失。

通过这个案例，我们可以看到注入攻击的危害。因此，在开发和维护 API 时，必须高度重视安全问题，采取有效的防御措施。

未来趋势和应对思路

随着技术的不断发展，API 注入攻击也在不断演变。未来可能会出现更复杂、更隐蔽的攻击方式。为了应对这些挑战，我们需要不断探索新的防御技术和策略。
1. 人工智能和机器学习的应用
- 利用人工智能和机器学习算法对 API 请求进行实时监测和分析，识别异常行为和潜在的攻击模式。
- 训练模型来预测和防范未知的注入攻击，提高防御的智能化水平。
2. 零信任架构的实施
- 采用零信任架构，默认不信任任何内部或外部的用户和设备，对所有访问进行严格的身份验证和授权。
- 在 API 层面实现细粒度的访问控制，确保只有经过授权的用户和应用程序可以访问敏感数据。
3. 自动化安全测试工具的发展
- 开发更强大、更智能的自动化安全测试工具，能够快速、准确地检测和发现各种注入攻击漏洞。
- 结合持续集成和持续部署（CI/CD）流程，将安全测试纳入开发的每个阶段，及时发现和修复安全问题。

总之，API 注入攻击是一个持续存在的安全威胁，我们需要不断学习和创新，采用多种防御手段相结合的方式，才能有效地保护 API 的安全，确保数字业务的稳定运行。

以下是一个综合的 API 安全防护流程的 mermaid 流程图：

graph LR;
    A[用户发起 API 请求] --> B{输入验证};
    B -- 通过 --> C{访问权限检查};
    C -- 通过 --> D{数据清理};
    D --> E[执行 API 操作];
    E --> F{返回响应};
    B -- 不通过 --> G[拒绝请求];
    C -- 不通过 --> G;
    H[定期安全审计] --> I[漏洞扫描];
    I --> J{发现漏洞};
    J -- 是 --> K[修复漏洞];
    J -- 否 --> L[继续监测];
    K --> L;

通过这个流程图，我们可以看到一个完整的 API 安全防护体系，包括请求处理过程中的验证、授权和清理，以及定期的安全审计和漏洞修复。在实际应用中，我们应该按照这个流程来构建和维护 API 的安全性，确保其能够抵御各种注入攻击。