SQL注入

故事时间

我们先讲一个故事。Mike 是一所小型私立学校的系统管理员，主要负责维护学校的网络和计算机。最近，他开始通过构建一个内部使用的 Web 应用程序来自动化学校的各种任务。他没有接受过正规的编程培训，编程经验也很少。仅掌握了 PHP 的基础知识后，他就为学校开发了一个相当稳定的客户关系管理系统，甚至还因优化了运营流程、为学校节省了开支而得到了校长的表扬。

一切原本都很顺利，直到一名新学生入学。

这名学生的姓名是“小鲍比·表格”（Little Bobby Tables）。有一天，行政办公室的 Jon 打电话给 Mike，询问为什么系统瘫痪了。经过检查，Mike 发现存储所有学生信息的数据表完全消失了。原来，这位小鲍比的全名其实是 "Robert'); DROP TABLE students;--"。而数据库没有任何备份——这事儿一直在 Mike 的待办清单上，但他一直没来得及处理。现在，Mike 麻烦大了。

SQL 注入

现实世界中的案例

虽然现实中不太可能真有孩子的名字包含恶意 SQL 代码，但这类 SQL 注入漏洞 在真实世界中却频繁发生：

• 2012 年，[LinkedIn] 泄露了超过 600 万名用户的资料，原因是存在未公开的 SQL 注入漏洞。
• 2012 年，[Yahoo!] 暴露了 45 万名用户的密码。
• 2012 年，[Nvidia] 被泄露了 40 万个用户密码。
• 2012 年，[Adobe] 有 15 万个密码遭到泄露。
• 2013 年，[Harmony] 约 150 万名用户的密码被曝光。

大多数事件的具体细节并未完全披露，我们无法百分之百确定这些都源于 SQL 注入攻击，但可能性极高。

SQL 注入的工作原理

如果你直接使用未经处理的用户输入，恶意用户就可能传入意料之外的数据，从而彻底改变你的 SQL 查询逻辑。

假设你的代码如下所示：

1UPDATE users
2    SET first_name="' + req.body.first_name +  '" WHERE id=1001;

你期望生成的 SQL 是：

1UPDATE users 
2    SET first_name="Liz" WHERE id=1001;

但如果恶意用户将其名字输入为：

1Liz", last_name="Lemon"; --

那么最终生成的 SQL 将变成：

1UPDATE users
2    SET first_name="Liz", last_name="Lemon"; --" WHERE id=1001;

这样一来，所有用户的姓名都被改成了 Liz Lemon —— 这显然非常糟糕。

实际中的 SQL 注入演示

如果不采取预防措施，SQL 注入攻击会造成严重后果。下面我们来尝试注入一些 SQL 代码。点击 RUN 按钮将打开一个 Web 应用程序，其编辑功能存在漏洞，请尝试利用它！

若执行了任何注入攻击，刷新页面即可查看结果变化。

提示

• 尝试使用上述技术，将 first_name 设置为 Liz。
• 注意引号的使用：" 或 '。
• 你甚至可以通过修改 Bobby 的名字 Robert'); DROP TABLE students;-- 来删除整个数据表。
• 点击 RUN 按钮可重置数据库。

将 First Name 设置为 Liz'; --，这会把所有人的名字都改为 Liz。

将 First Name 设置为 Robert'; DROP TABLE students;--，这会删除整个数据表。