SQL注入或SQLi是最简单的Web应用程序安全攻击之一，它可以让攻击者完全控制Web应用程序数据库，在XKCD 327中有个形象的漫画，SQLi于1998年首次发现，但仍然在互联网上困扰着Web应用程序。 即使是 OWASP Top10也将注入列为Web 应用安全 的头号威胁。

好消息？SQL注入无论对于攻击者还是防守者来说，都是最简单的事情。SQLi不是像一些尖端的NSA 影子经纪人 工具包，它是如此简单三岁小孩都可以做到。这是脚本小子的东西 - 修复您的Web应用程序以降低SQLi风险非常容易，不过越是这样就越容易发生重大疏忽。

SQL注入定义和类型

有几种类型的SQL注入，但都涉及到攻击者在Web应用程序数据库查询中插入任意SQL。SQL注入的最简单形式是通过用户输入。Web应用程序通常通过表单接受用户输入，前端将用户输入传递给后端数据库进行处理。 如果Web应用程序无法过滤用户输入，攻击者可以将他们选择的SQL注入后端数据库并删除、复制或修改数据库的内容。

攻击者还可以修改cookie，并向Web应用程序的数据库查询中投毒。 Cookies在本地存储客户端状态信息，Web应用程序通常会加载Cookie并处理该信息。 恶意用户或恶意软件可以修改cookie，进而将恶意SQL语句注入后端数据库。

服务器变量（如HTTP标头）也可以用作SQL注入攻击向量。 如果Web应用程序无法过滤这些输入，那么包含任意SQL的伪造标题都可以将该代码注入数据库。

二阶SQL注入攻击是最棘手的一组攻击，因为它们不是立即运行的，而是很久以后。 当中毒数据在不同的上下文中使用时，开发人员如果能正确清理所有输入以防止即时攻击，可能仍然容易受到二阶SQLi的攻击。

SQL注入是如何完成的？

作为一种技术，SQL注入比现在许多使用SQLi的人类攻击者都要历史悠久。 SQLi攻击是基本的，早已自动化了。 像SQLninja、SQLmap和Havij这样的工具可以让您轻松测试自己的Web应用程序，同时也可以让攻击者轻松实现。

十年前，一个SQLi蠕虫横扫互联网。切入现在：没有太大变化。 尽管人们普遍意识到SQL注入是一个问题，但很大一部分Web应用程序仍然很脆弱。

自动化测试工具可以让您在寻找轻松发薪日的攻击者中领先一步。 使用SQLmap等工具对您的Web应用程序进行测试，可以快速查看您的缓解措施是否足够。 SQLmap几乎支持当今使用的所有主要数据库，并且可以检测和利用大多数已知的 SQL注入漏洞 。

清理您的输入，但需要进行测试，以验证您的缓解措施是成功的。 有用的提醒：蓝队和红队是同一枚硬币的两面。

SQL注入攻击的例子

我们来看一下基本的SQL注入攻击。 假设您已经构建了一个Web应用程序，可以让客户输入他们的客户ID并检索他们的客户配置文件。 Web应用程序前端将用户输入的客户ID传递到后端数据库。 数据库运行SQL查询并将结果返回给Web应用程序，Web应用程序将结果显示给最终用户。

后端数据库查询可能如下所示：

SELECT *

FROM customers

WHERE customer_id = '1234567'

假设用户在网页表单字段中输入了以下customer_id：

1234567; DELETE * customers where'1'='1

后端数据库然后会乖乖地执行下面的SQL：

SELECT *

FROM customers

WHERE customer_id = '1234567';

DELETE *

FROM customers

WHERE 'x' = 'x'

请记住，如果以分号分隔，数据库将愉快地在一行中执行多个SQL语句。 如果不能清理单引号“'”字符的用户输入，则攻击者可能会删除整个表。 希望你有好的备份。

这是一个很简单的例子，虽然有许多不同的SQL注入攻击媒介，但所有工作都基于相同的原理：Web应用程序无法清理输入导致远程SQL代码执行。

可以检测到SQL注入吗？

减轻SQL注入攻击并不困难，但即使是最聪明和最有意向的开发者也会犯错。 因此，检测是减轻SQL注入攻击风险的重要组成部分。 Web应用防火墙（WAF）可以检测并阻止基本的SQL注入攻击，但不应将其作为唯一的预防措施。

可以调整入侵检测系统（IDS）（基于网络和主机）来检测SQL注入攻击。 基于网络的IDS可以监视与数据库服务器的所有连接，并标记可疑活动。 基于主机的IDS可以监视Web服务器日志并在出现异常时发出警报。

但是，最终，SQL注入攻击已被很好地理解并且易于预防，并且风险缓解的优先级应该首先防止SQL注入攻击。

如何防止SQL注入

收听小鲍比表并清理数据库输入。 对您的Web应用程序数据库的任何输入都应被视为不可信，并据此进行处理。 当他们告诉你“有些成功的SQL注入攻击发生时有点可耻，因为在你的代码中避免 SQL注入漏洞 极其简单”。

在OWASP SQL注入防范指南比我们这里讲的更深入，但防SQL注入攻击，OWASP告诉我们，要求开发者白名单输入验证（不是黑名单），使用具有参数化查询预处理语句，并逃避所有用户提供的输入。

还要限制帐户权限。 假设违反。 如果开发人员无法清理单个用户输入字段会怎么样？ 嘿，它发生了。 开发人员只是人。 消毒输入，但假设有东西会滑过你。 限制数据库用户的帐户权限。 例如，您的Web应用程序是只读的吗？ 它是否需要具有DROP TABLES权限？ 可能不会。 最小特权原则适用于此。 为Web应用程序提供运行所需的最低权限。

存储过程也会使SQLi变得更加困难 - 尽管并非不可能。 如果您的Web应用程序只需要运行一些SQL查询，请创建存储过程以执行这些查询。 通常，只有数据库管理员才有权创建或修改存储过程。 不过请注意，许多数据库都提供了默认的存储过程，攻击者知道这一点。 考虑删除那些默认的存储过程，除非你真的需要它们。

防止SQL注入是最低尽职调查

SQL注入是低悬挂Web应用程序安全性水平中最低的。 这种众所周知的攻击媒介很容易被不成熟的攻击者利用，但通过少量的尽职调查可以轻易缓解这种攻击。 2018年，Web应用程序不再有任何理由容易受到SQL注入的攻击。 这就是Web应用程序安全性的最低尽职调查。