SQL 注入与命令注入
学习攻击者如何构造注入载荷来操纵数据库查询或 OS 命令，以及参数化查询和输入验证如何阻止这些攻击。
SQL 注入与命令注入 是 CoddyKit 上的免费 Security+ Academy 课时。 这是第 1 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Security+ Academy 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Security+ Academy 课程共包含 4 节课。
什么是 SQL 注入
SQL 注入（SQLi）发生在攻击者将恶意 SQL 代码插入或“注入”到某个输入字段中，而该字段随后被传递给数据库查询时。由于应用程序会将 User 输入直接拼接到 SQL 语句中，数据库无法区分合法数据和攻击者提供的 Commands。SQLi 一直位列 OWASP Top 10 中最危险的 Web Vulnerabilities 之一。
经典 SQLi Payload 示例
存在 Vulnerability 的登录查询可能如下所示：SELECT * FROM users WHERE username='INPUT' AND password='INPUT'。攻击者将 ' OR '1'='1 作为用户名提交后，会使查询发生变化，从而让 WHERE 子句始终为真，完全绕过身份验证。这就是经典的基于恒真式的注入。
-- Vulnerable query (DO NOT use in production)
SELECT * FROM users
WHERE username = '' OR '1'='1'
AND password = 'anything';
-- Returns ALL rows — auth bypassedSQL 注入的类型
SQL 注入攻击有多种形式：In-band SQLi 会直接在 HTTP 响应中返回结果（基于错误或基于联合查询）。Blind SQLi 通过布尔值的 true/false 响应或故意制造的时间延迟（SLEEP(5)）推断数据。Out-of-band SQLi 会使用 DNS 查询等辅助通道，在无法看到响应时窃取数据。
-- Time-based blind SQLi example
SELECT * FROM users
WHERE id = '1' AND SLEEP(5)--';
-- If response is delayed 5s, injection succeeded防御 SQLi：参数化查询
防御 SQL 注入的主要措施是使用参数化查询（也称为预编译语句）。在参数化查询中，SQL 结构会先被编译，User 输入则作为独立参数传入——它绝不可能改变查询结构。这种方法与具体语言无关，而且比单独进行输入清理可靠得多。
# Python example — parameterized query (safe)
import sqlite3
conn = sqlite3.connect('app.db')
cursor = conn.cursor()
username = 'admin'
password = 'secret'
cursor.execute(
'SELECT * FROM users WHERE username=? AND password=?',
(username, password) # parameters, never concatenated
)将输入验证作为纵深防御
参数化查询是主要防御手段，而输入验证则提供了重要的第二层防护。允许列表验证只接受预期字符（例如，用户名字段仅允许字母和数字），并拒绝其他所有内容。拒绝列表验证会阻止已知的恶意字符，但攻击者经常通过编码或混淆 Payload 来绕过拒绝列表，因此允许列表的防护能力更强。
什么是 Commands 注入
Commands 注入（OS Commands 注入）发生在应用程序将未经清理的 User 输入传递给系统 Shell 时。与针对数据库的 SQL 注入不同，Commands 注入直接针对操作系统本身——攻击者可以借助 Web 服务器进程的 Privileges 运行任意 Commands。其严重程度被评为 CRITICAL，并且经常会导致整个 System 被攻陷。
Commands 注入示例
一个 Ping User 提供的 IP 地址的 Web 应用可能使用：ping -c 1 INPUT。如果攻击者提供 8.8.8.8; cat /etc/passwd，Shell 会将 ; 解释为 Commands 分隔符，并运行这两个 Commands。常见的注入运算符包括 ;、&&、||、| 以及反引号 Commands 替换。
# Vulnerable Python (subprocess with shell=True)
import subprocess
user_ip = '8.8.8.8; cat /etc/passwd' # attacker input
subprocess.run('ping -c 1 ' + user_ip, shell=True)
# Safe alternative — avoid shell=True, pass args as list
subprocess.run(['ping', '-c', '1', '8.8.8.8'])防止 Commands 注入
防御 Commands 注入最安全的方法是完全避免根据 User 输入调用操作系统 Commands——改用能够实现相同目标的库函数。如果无法避免调用 Shell，请将参数作为列表传递（绝不要拼接成字符串），禁用 Shell 解释，依据严格的允许列表验证输入，并使用 Privileges 尽可能低的 User 账户运行进程。
OWASP 背景：Top 10 中的注入
OWASP Top 10 将注入（包括 SQL、NoSQL、OS 和 LDAP 注入）列为最严重的应用安全风险之一。OWASP 建议采用纵深防御方法：使用可避免调用解释器的 Safe API，在 Server 端执行正向（允许列表）输入验证，根据相应解释器的语法转义特殊字符，并使用 LIMIT 等 SQL 控制措施来防止大规模数据泄露。
检测：WAF 和日志记录
Web 应用防火墙（WAF）可以通过根据特征模式检查 HTTP 请求，检测并拦截常见的注入载荷。不过，WAF 可能被编码技巧绕过，不能替代安全编码。适当的应用日志记录——记录查询参数、响应代码和错误消息——可以帮助安全团队在事件复盘期间识别注入尝试。
注入攻击的现实影响
注入攻击曾造成历史上一些规模最大的数据泄露事件。2017 年的 Equifax 数据泄露事件通过一个 Web 应用漏洞暴露了 1.47 亿条记录。2011 年，针对 Sony PlayStation Network 的 SQL 注入攻陷了 7700 万个账户。这些事件表明，注入漏洞会带来极其严重的业务影响：数据窃取、监管罚款、声誉损害和法律责任都会随着成功的注入攻击而来。
快速检查
请测试您对本课 CompTIA Security+（SY0-701）概念的理解。
课程回顾
在本课中，您学到了：SQL 注入会利用未经清理、被拼接进数据库查询的输入，命令注入会通过 ; 和 | 等运算符，将 Malicious 输入传递给 OS shell，而参数化查询和避免使用 shell=True 是主要的 Defense。接下来，我们将学习跨站脚本（XSS）和 CSRF 攻击。
常见问题解答
「SQL 注入与命令注入」课时是免费的吗？
是的 — 「SQL 注入与命令注入」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Security+ Academy 课程的其余内容，请升级到 CoddyKit PRO。 Security+ Academy 课程共包含 4 节课。
「SQL 注入与命令注入」这节课中我会学到什么？
学习攻击者如何构造注入载荷来操纵数据库查询或 OS 命令，以及参数化查询和输入验证如何阻止这些攻击。 你通过在浏览器中直接运行的动手代码来练习 Security+ Academy，全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 Security+ Academy 需要有经验吗？
无需任何先前经验。CoddyKit 上的 Security+ Academy 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 1 节课，共 4 节。
「SQL 注入与命令注入」课时需要多长时间？
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。
我能在这节 Security+ Academy 课中编写并运行代码吗？
能。每节 Security+ Academy 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。