一位客户让我们针对只有他们企业员工和顾客能使用的企业内网进行渗透测试。这是安全评估的一个部分，所以尽管我们之前没有使用过SQL注入来渗透网络，但对其概念也相当熟悉了。最后我们在这项任务中大获成功，现在来回顾一下这个过程的每一步，将它记录为一个案例。

我们记录下了在多次错误的转折后经历的曲折过程，而一个更有经验的人会有这不同的 — 甚至更好的 — 方法。但事实上我们成功以后才明白，我们并没有完全被误导。

其他的SQL文章包含了更多的细节，但是这篇文章不仅展示了漏洞利用的过程，还讲述了发现漏洞的原理。

目标内网

展现在我们眼前的是一个完整定制网站，我们之前没见过这个网站，也无权查看它的源代码：这是一次“黑盒”攻击。‘刺探’结果显示这台服务器运行在微软的IIS6上，并且是ASP.NET架构。这就暗示我们数据库是微软的SQL server：我们相信我们的技巧可以应用在任何web应用上，无论它使用的是哪种SQL 服务器。

登陆页有传统的用户-密码表单，但多了一个 “把我的密码邮给我”的链接；后来，这个地方被证实是整个系统陷落的关键。

当键入邮件地址时，系统假定邮件存在，就会在用户数据库里查询邮件地址，然后邮寄一些内容给这个地址。但我的邮件地址无法找到，所以它什么也不会发给我。

对于任何SQL化的表单而言，第一步测试，是输入一个带有单引号的数据：目的是看看他们是否对构造SQL的字符串进行了过滤。当把单引号作为邮件地址提交以后，我们得到了500错误（服务器错误），这意味着“有害”输入实际上是被直接用于SQL语句了。就是这了！

我猜测SQL代码可能是这样：

$EMAIL 是用户从表单提交的地址，并且这段查询在字符串末端$EMAIL上提供了引号。我们不知道字段或表的确切名字，但是我们了解他们的本质，这有助于我们做正确的猜测。

当我们键入 steve@unixwiz.net‘ -注意这个末端的引号 – 下面是这个SQL字段的构成：

当这段SQL开始执行，SQL解析器就会发现多余的引号然后中断执行，并给出语法错误的提示。这个错误如何清楚的表述给用户，基于应用内部的错误恢复规程，但一般来说都不会提示“邮件地址不存在”。这个错误响应成了死亡之门，它告诉别人用户输入没有被正确的处理，这就为应用破解留下了可乘之机。

这个数据呈现在WHERE的从句中，让我们以符合SQL规范的方式改变输入试试，看看会发生什么。键入anything’ OR ‘x’=‘x, 结果如下：

因为应用不会思考输入 – 仅仅构造字符串 - 我们使用单引号把WHERE从句的单一组成变成了双组成，’x'=‘x’从句是恒成立的，无论第一个从句是什么。（有一种更好的方式来确保“始终为真”，我们随后会接触到）。

但与每次只返回单一数据的“真实”查询不同，上面这个构造必须返回这个成员数据库的所有数据。要想知道在这种情况下应用会做什么，唯一的方法就是尝试，尝试，再尝试。我们得到了这个：

---

你的登录信息已经被邮寄到了 random.person@example.com.

---

我们猜测这个地址是查询到的第一条记录。这个家伙真的会在这个邮箱里收到他忘记的密码，想必他会很吃惊也会引起他的警觉。

我们现在知道可以根据自己的需要来篡改查询语句了，尽管对于那些看不到的部分还不够了解，但是我们注意到了在多次尝试后得到了三条不同的响应：

• “你的登录信息已经被邮寄到了邮箱”
• “我们不能识别你的邮件地址”
• 服务器错误

前两个响应是有效的SQL，最后一个响应是无效的SQL：当猜测查询语句结构的时候，这种区别非常有用。

模式字段映射

第一步是猜测字段名：我们合理的推测了查询包含“email address”和“password”，可能也会有“US Mail address”或者“userid”或“phone number”这样的字段。我们特别想执行 SHOW TABLE语句, 但我们并不知道表名，现在没有比较明显的办法可以拿到表名。

我们进行了下一步。在每次测试中，我们会用我们已知的部分加上一些特殊的构造语句。我们已经知道这个SQL的执行结果是email地址的比对，因此我们来猜测email的字段名:

目的是假定的查询语句的字段名（email），来试试SQL是不是有效。我不关心匹配的邮件地址是啥（我们用了个伪名’x’），’ ——’这个符号表示SQL注释的起始。对于去除应用末尾提供的引号，这是一个很有效的方式，我们不用在乎我们屏蔽掉的是啥。

如果我们得到了服务器错误，意味着SQL有不恰当的地方，并且语法错误会被抛出：更有可能是字段名有错。如果我们得到了任何有效的响应，我们就可以猜测这个字段名是正确的。这就是我们得到“email unknown”或“password was sent”响应的过程。

我们也可以用AND连接词代替OR:这是有意义的。在SQL的模式映射阶段，我们不需要为猜一个特定的邮件地址而烦恼，我们也不想应用随机的泛滥的给用户发“这是你的密码”的邮件 - 这不太好，有可能引起怀疑。而使用AND连接邮件地址，就会变的无效，我们就可以确保查询语句总是返回0行，永远不会生成密码提醒邮件。

提交上面的片段的确给了我们“邮件地址未知”的响应，现在我们知道邮件地址的确是存储在email字段名里。如果没有生效，我们可以尝试email_address或mail这样的字段名。这个过程需要相当多的猜测。

接下来，我们猜测其他显而易见的名字：password，user ID, name等等。每次只猜一个字段，只要响应不是“server failure”，那就意味着我们猜对了。

在这个过程中，我们找到了几个正确的字段名：

• email
• passwd
• login_id
• full_name

无疑还有更多（有一个线索是表单中的字段名），一阵挖掘后没有发现更多了。但是我们依然不知道这些字段名的表名，它们在哪找到的？

寻找数据库表名

应用的内建查询指令已经建立了表名，但是我们不知道是啥：有几个方法可以找到表名。其中一个是依靠subselect（字查询）。

一个独立的查询

返回表里记录的数量，如果表名无效，查询就会失败。我们可以建立自己的字符串来探测表名：

我们不关心到底有多少条记录，只关心表名是不是正确。重复多次猜测以后，我们终于发现members是这个数据库里的有效表名。但它是用在这个查询里的么？所以我们需要另一个测试，使用table.field：实际查询的部分只工作在这个表中，而不是只要表存在就执行。

当返回“Email unknown”时，就意味着我们的SQL注入成功了，并且我们正确的猜测出了表名。这对后面的工作很重要，但是我们暂时先试试其他的方法。

找用户账号

我们对members表的结构有了一个局部的概念，但是我们仅知道一个用户名：任意用户都可能得到“Here is your password”的邮件。回想起来，我们从未得到过信息本身，只有它发送的地址。我们得再弄几个用户名，这样就能得到更多的数据。

首先，我们从公司网站开始找几个人：“About us”或者“Contact”页通常提供了公司成员列表。通常都包含邮件地址，即使它们没有提供这个列表也没关系，我们可以根据某些线索用我们的工具找到它们。

LIKE从句可以进行用户查询，允许我们在数据库里局部匹配用户名或邮件地址，每次提交如果显示“We sent your password”的信息并且邮件也真发了，就证明生效了。

警告：这么做拿到了邮件地址，但也真的发了邮件给对方，这有可能引起怀疑，小心使用。

我们可以查询email name或者full name（或者推测出来的其他信息），每次放入%通配符进行如下查询：

记住尽管可能不只有一个“Bob”，但我们只能看到一条信息：建议精炼LIKE从句。

密码暴力破解

可以肯定的是，我们能在登陆页进行密码的暴力破解，但是许多系统都针对此做了监测甚至防御。可能有的手段有操作日志，帐号锁定，或者其他能阻碍我们行动的方式，但是因为存在未过滤的输入，我们就能绕过更多的保护措施。

我们在构造的字符串里包含进邮箱名和密码来进行密码测试。在我们的例子中，我们用了受害者bob@example.com 并尝试了多组密码。

这是一条很好使的SQL语句，我们不会得到服务器错误的提示，只要我们得到“your password has been mailed to you”的提示信息，就证明我们已经得到密码了。这时候受害人可能会警觉起来，但谁关心他呢，我们已经得到密码了。

这个过程可以使用perl脚本自动完成，然而，我们在写脚本的过程中，发现了另一种方法来破解系统。

数据库不是只读的

迄今为止，我们没做查询数据库之外的事，尽管SELECT是只读的，但不代表SQL只能这样。SQL使用分号表示结束，如果输入没有正确过滤，就没有什么能阻止我们在字符串后构造与查询无关的指令。

The most drastic example is:

这剂猛药是这样的：

第一部分我们准备了一个伪造的email地址——‘X’——我们不关心查询结果返回什么：我们想要得到的只是我们自己构造的SQL指令。这次攻击删除了整个members表，这就不太好玩了。

这表明我们不仅仅可以切分SQL指令，而且也可以修改数据库。这是被允许的。

添加新用户

我们已经了解了members表的局部结构，添加一条新纪录到表里视乎是一个可行的方法：如果这成功了，我们就能简单的用我们新插入的身份登陆到系统了。

不要太惊讶，这条SQL有点长，我们把它分行显示以便于理解，但它依然是一条语句：

即使我们得到了正确的字段名和表名，但在成功攻击之前我们还有几件事需要了解：

1. 在web表单里，我们可能没有足够的空间键入这么多文本（尽管可以用脚本解决，但并不容易）。
2. web应用可能没有members表的INSERT权限。
3. 母庸置疑，members表里肯定还有其他字段，有一些可能需要初始值，否则会引起INSERT失败。
4. 即使我们插入了一条新纪录，应用也可能不正常运行，因为我们无法提供值的字段名会自动插入NULL。
5. 一个正确的“member”可能额不仅仅只需要members表里的一条纪录，而还要结合其他表的信息（如，访问权限），因此只添加一个表可能不够。

在这个案例里，我们遇到了问题#4或#5，我们无法确定到底是哪个—— 因为用构造好的用户名登陆进去的时候，返回了服务器错误的提示。尽管这就暗示了我们那些没有构造的字段是必须的，但我们没有办法正确处理。

一个可行的办法是猜测其他字段，但这是一个劳力费神的过程：尽管我们可以猜测其他“显而易见”的字段，但要想得到整个应用的组织结构图太难了。

我们最后尝试了其他方式。

把密码邮给我

我们意识到虽然我们无法添加新纪录到members数据库里，但我们可以修改已经存在的，这被证明是可行的。

从上一步得知 bob@example.com 账户在这个系统里，我们用SQL注入把数据库中的这条记录改成我们自己的email地址：

运行之后，我们自然得到了“we didn’t know your email address”的提示，但这在预料之中，毕竟我们用了假的email地址。UPDATE操作不会通知应用，因此它悄然执行了。

之后，我们使用了“I lost my password”的功能，用我们刚刚更新的email地址，一分钟后，我们收到了这封邮件：

现在，我们要做的就是跟随标准的登录流程进入系统，这是一个高等级职员，有高级权限，比我们INSERT的用户要好。

我们发现这个企业内部站点内容特别多，甚至包含了一个全用户列表，我们可以合理的推出许多内网都有同样的企业Windows网络帐号，它们可能在所有地方都使用同样的密码。我们很容易就能得到任意的内网密码，并且我们找到了企业防火墙上的一个开放的PPTP协议的VPN端口，这让登录测试变得更简单。

我们又挑了几个帐号测试都没有成功，我们无法知道是否是“密码错误”或者“企业内部帐号是否与Windows帐号名不同”。但是我们觉得自动化工具会让这项工作更容易。

其他方法

在这次特定的渗透中，我们得到了足够的权限，我们不需要更多了，但是还有其他方法。我们来试试我们现在想到的但不够普遍的方法。

我们意识到不是所有的方法都与数据库无关，我们可以来试试。

调用xp_cmdshell

微软的SQLServer支持存储过程xp_cmdshell有权限执行任意操作系统指令。如果这项功能允许web用户使用，那webserver被渗透是无法避免的。

迄今为止，我们做的都被限制在了web应用和数据库这个环境下，但是如果我们能执行任何操作系统指令，再厉害的服务器也禁不住渗透。xp_cmdshell通常只有极少数的管理员账户才能使用，但它也可能授权给了更低级的用户。

绘制数据库结构

在这个登录后提供了丰富功能应用上，已经没必要做更深的挖掘了，但在其他限制更多的环境下可能还不够。

能够系统的绘制出数据库可见结构，包含表和它们的字段结构，可能没有直接帮助。但是这为网站渗透提供了一条林萌大道。

从网站的其他方面收集更多有关数据结构的信息（例如，“留言板”页？“帮助论坛”等？）。不过这对应用环境依赖强，而且还得靠你准确的猜测。

减轻危害

我们认为web应用开发者通常没考虑到“有害输入”，但安全人员应该考虑到（包括坏家伙），因此这有3条方法可以使用。

输入过滤

过滤输入是非常重要的事，以确保输入不包含危险代码，无论是SQL服务器或HTM本身。首先想到的是剥掉“恶意字符”，像引号、分号或转义符号，但这是一种不太好的方式。尽管找到一些危险字符很容易，但要把他们全找出来就难了。

web语言本身就充满了特殊字符和奇怪的标记（包括那些表达同样字符的替代字符），所以想要努力识别出所有的“恶意字符”不太可能成功。

换言之，与其“移除已知的恶意数据”，不如移除“良好数据之外的所有数据”：这种区别是很重要的。在我们的例子中，邮件地址仅能包含如下字符：

允许不正确的字符输入是没有任何好处的，应该早点拒绝它们 - 可能会有一些错误信息 – 不仅可以阻止SQL注入，也可以捕获一些输入错误而不是把它们存入数据库。

某个特殊的email地址会让验证程序陷入麻烦，因为每个人对于“有效”的定义不同。由于email地址中出现了一个你没有考虑到的字符而被拒绝，那真是糗大了。

真正的权威是 RFC 2822（比RFC822内容还多），它对于”允许使用的内容“做了一个规范的定义。这种更学术的规范希望可以接受&和*（还有更多）作为有效的email地址，但其它人 - 包括作者 – 都乐于用一个合理的子集来包含更多的email地址。

那些采用更限制方法的人应当充分意识到没有包含这些地址会带来的后果，特别是限制有了更好的技术（预编译/执行，存储过程）来避免这些“奇怪”的字符带来的安全问题。

意识到“过滤输入”并不意味着仅仅是“移除引号”，因为即使一个“正规”的字符也会带来麻烦。在下面这个例子中，一个整型ID值被拿来和用户的输入作比较（数字型PIN）:

在实践中，无论如何这个方法都有诸多限制，因为能够彻底排除所有危险字符的字段实在太少了。对于“日期”或者“email地址”或者“整型”，上面的办法是有价值的，但对于真实的环境，我们不可避免地要使用其他方式来减轻危害。

输入项编码/转义

现在可以过滤电话号码和邮件地址了，但你不能通过同样的方法处理“name”字段，要不然可能会排除掉Bill O’Reilly这样的名字：对于这个字段，这里的引号是合法的输入。

有人就想到过滤到单引号的时候，再加上一个引号，这样就没问题了 – 但是这么干要出事啊！

预处理每个字符串来替换单引号：

这个方法很容易出问题，因为大部分数据库都支持转码机制。像MySQL，允许输入’来替代单引号，因此如果输入 ‘; DROP TABLE users; — 时，通过两次引号来“保护”数据库，那我们将得到：

‘’’ 是一个完整的SQL语句（只包含一个引号），通常，恶意SQL代码就会紧跟其后。不光是反斜线符号的情况：像Unicode编码，其他的编码或者解析规则都会无意中给程序员挖坑。完美的过滤的很困难的，这就是为什么许多的数据库借口语言都提供函数给你使用。当同样的内容给“string quoting”和“string parsing”处理过后，会好一些，也更安全一些。

比如MySQL的函数mysql_real_escape_string()和perl DBD 的 $dbh->quote($value)方法，这些方法都是必用的。

参数绑定 (预编译语句)

尽管转义是一个有用的机制，但我们任然处于“用户输入被当做SQL语句”这么一个循环里。更好的方法是：预编译，本质上所有的数据库编程接口都支持预编译。技术上来说，SQL声明语句是用问号给每个参数占位创建的 – 然后在内部表中进行编译。

预编译查询执行时是按照参数列表来的：

Perl中的例子

感谢Stefan Wagner帮我写了个java实现：

不安全版

安全版

$email 是从用户表单获得的，它作为#1（第一个问号标记的地方）位置的参数传递过来，在任何情况下这条SQL声明都可以解析。引号，分号，反斜杠，SQL指令记号 – 任何字符都不会产生特殊效果，因为它们“只是数据”而已。这不会对其他东西造成破坏，因此这个应用很大程度上防范了SQL注入攻击。

如果预编译查询语句多次（只编译一次）执行，也会带来性能上的提升，但是与大量安全方面的巨大提升相比，这显得微不足道。这可能是我们保证web应用安全最重要的一步。

限制数据库权限和隔离用户

在这个案例中，我们观察到只有两个交互动作不在登录用户的上下文环境中：“登录”和“发密码给我”。web应用应该对数据库连接做权限的限制：对于members表只能读，并且无法操作其他表。

作用是即使一次“成功的”SQL注入攻击也只能得到非常有限的成功。噢，我们将不能做有授权的UPDATE请求，我们要求助于其他方法。

一旦web应用确定登录表单传递来的认证是有效的，它就会切换会话到一个有更多权限的用户上。

对任何web应用而言，不使用sa权限几乎是根本不用说的事。

对数据库的访问采用存储过程

如果数据库支持存储过程，请使用存储过程来执行数据库的访问行为，这样就不需要SQL了（假设存储过程编程正确）。

把查询，更新，删除等动作规则封装成一个单独的过程，就可以针对基础规则和所执行的商业规则来完成测试和归档（例如，如果客户超过了信用卡限额，“添加新记录”过程可能拒绝订单）。

对于简单的查询这样做可能仅仅能获得很少的好处，不过一旦操作变复杂（或者被用在更多地方），给操作一个单独的定义，功能将会变得更稳健也更容易维护。

注意：动态构建一个查询的存储过程是可以做到的：这么做无法防止SQL注入 – 它只不过把预编译/执行绑定到了一起，或者是把SQL语句和提供保护的变量绑定到了一起。

隔离Web服务器

实施了以上所有的防御措施，仍然可能有某些地方有遗漏，导致了服务器被渗透。设计者应该在假定坏蛋已经获得了系统最高权限下来设计网络设施，然后把它的攻击对其他事情产生的影响限制在最小。

例如，把这台机器放置在极度限制出入的DMZ网络“内部”，这么做意味着即便取得了web服务器的完全控制也不能自动的获得对其他一切的完全访问权限。当然，这么做不能阻止所有的入侵，不过它可以使入侵变的非常困难。

配置错误报告

一些框架的错误报告包含了开发的bug信息，这不应该公开给用户。想象一下：如果完整的查询被现实出来了，并且指出了语法错误点，那要攻击该有多容易。

对于开发者来说这些信息是有用的，但是它应该禁止公开 – 如果可能 - 应该限制在内部用户访问。

注意：不是所有的数据库都采用同样的方式配置，并且不是所有的数据库都支持同样的SQL语法（“S”代表“结构化”，不是“标准的”）。例如，大多数版本的MySQL都不支持子查询，而且通常也不允许单行多条语句（multiple statements）：当你渗透网络时，实际上这些就是使问题复杂化的因素。

---

再强调一下，尽管我们选择了“忘记密码”链接来试试攻击，但不是因为这个功能不安全。而是几个易攻击的点之一，不要把焦点聚集在“忘记密码”上。

这个教学示例不准备全面覆盖SQL注入的内容，甚至都不是一个教程：它仅仅是一篇我们花了几小时做的渗透测试的记录。我们看了其他的关于SQL注入文章的讨论，但它们只给出了结果而没有给出过程。

但是那些结果报告需要技术背景才能看懂，并且渗透细节也是有价值的。在没有源代码的情况下，渗透人员的黑盒测试能力也是有价值的。

其他资源

• (more) Advanced SQL Injection, Chris Anley, Next Generation Security Software.
• SQL Injection walkthrough, SecuriTeam
• GreenSQL, an open-source database firewall that tries to protect against SQL injection errors— note; I don’t have any direct experience with this tool
• “Exploits of a Mom”— Very good xkcd cartoon about SQL injection
• SQL Injection Cheat Sheet— by Ferruh Mavituna
• This page translated into Belorussianby Bohdan Zograf (thanks!)

SQL注入详解
一：什么是sql注入

SQL注入是比较常见的网络攻击方式之一，它不是利用操作系统的BUG来实现攻击，而是针对程序员编写时的疏忽，通过SQL语句，实现无账号登录，甚至篡改数据库。

二：SQL注入攻击的总体思路

1：寻找到SQL注入的位置

2：判断服务器类型和后台数据库类型

3：针对不同的服务器和数据库特点进行SQL注入攻击

三：SQL注入攻击实例

String sql = "select * from user_table where username=
' "+userName+" ' and password=' "+password+" '";
--当输入了上面的用户名和密码，上面的SQL语句变成：
SELECT * FROM user_table WHERE username=
'’or 1 = 1 -- and password='’
--分析SQL语句：
--条件后面username=”or 1=1 用户名等于 ” 或1=1 那么这个条件一定会成功；

--然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用，这样语句永远都--能正确执行，用户轻易骗过系统，获取合法身份。
--这还是比较温柔的，如果是执行
SELECT * FROM user_table WHERE
username='' ;DROP DATABASE (DB Name) -- and password=''
--其后果可想而知…

四：如何防御SQL注入

注意：但凡有SQL注入漏洞的程序，都是因为程序要接受来自客户端用户输入的变量或URL传递的参数，并且这个变量或参数是组成SQL语句的一部分，对于用户输入的内容或传递的参数，我们应该要时刻保持警惕，这是安全领域里的「外部数据不可信任」的原则，纵观Web安全领域的各种攻击方式，大多数都是因为开发者违反了这个原则而导致的，所以自然能想到的，就是从变量的检测、过滤、验证下手，确保变量是开发者所预想的。

1、检查变量数据类型和格式

如果你的SQL语句是类似where id={$id}这种形式，数据库里所有的id都是数字，那么就应该在SQL被执行前，检查确保变量id是int类型；如果是接受邮箱，那就应该检查并严格确保变量一定是邮箱的格式，其他的类型比如日期、时间等也是一个道理。总结起来：只要是有固定格式的变量，在SQL语句执行前，应该严格按照固定格式去检查，确保变量是我们预想的格式，这样很大程度上可以避免SQL注入攻击。
　　比如，我们前面接受username参数例子中，我们的产品设计应该是在用户注册的一开始，就有一个用户名的规则，比如5-20个字符，只能由大小写字母、数字以及一些安全的符号组成，不包含特殊字符。此时我们应该有一个check_username的函数来进行统一的检查。不过，仍然有很多例外情况并不能应用到这一准则，比如文章发布系统，评论系统等必须要允许用户提交任意字符串的场景，这就需要采用过滤等其他方案了。

2、过滤特殊符号

对于无法确定固定格式的变量，一定要进行特殊符号过滤或转义处理。

3、绑定变量，使用预编译语句

MySQL的mysqli驱动提供了预编译语句的支持，不同的程序语言，都分别有使用预编译语句的方法

实际上，绑定变量使用预编译语句是预防SQL注入的最佳方式，使用预编译的SQL语句语义不会发生改变，在SQL语句中，变量用问号?表示，黑客即使本事再大，也无法改变SQL语句的结构

五：什么是sql预编译

1.1：预编译语句是什么

通常我们的一条sql在db接收到最终执行完毕返回可以分为下面三个过程：

词法和语义解析
　　优化sql语句，制定执行计划
　　执行并返回结果
　　我们把这种普通语句称作Immediate Statements。

但是很多情况，我们的一条sql语句可能会反复执行，或者每次执行的时候只有个别的值不同（比如query的where子句值不同，update的set子句值不同,insert的values值不同）。
　　如果每次都需要经过上面的词法语义解析、语句优化、制定执行计划等，则效率就明显不行了。

所谓预编译语句就是将这类语句中的值用占位符替代，可以视为将sql语句模板化或者说参数化，一般称这类语句叫Prepared Statements或者Parameterized Statements
　　预编译语句的优势在于归纳为：一次编译、多次运行，省去了解析优化等过程；此外预编译语句能防止sql注入。
　　当然就优化来说，很多时候最优的执行计划不是光靠知道sql语句的模板就能决定了，往往就是需要通过具体值来预估出成本代价。

1.2：MySQL的预编译功能

注意MySQL的老版本（4.1之前）是不支持服务端预编译的，但基于目前业界生产环境普遍情况，基本可以认为MySQL支持服务端预编译。

下面我们来看一下MySQL中预编译语句的使用。

（1）建表 首先我们有一张测试表t，结构如下所示：
mysql> show create table t\G
*************************** 1. row ***************************
       Table: t
Create Table: CREATE TABLE `t` (
  `a` int(11) DEFAULT NULL,
  `b` varchar(20) DEFAULT NULL,
  UNIQUE KEY `ab` (`a`,`b`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
（2）编译

　　我们接下来通过 PREPARE stmt_name FROM preparable_stm的语法来预编译一条sql语句

mysql> prepare ins from 'insert into t select ?,?';
Query OK, 0 rows affected (0.00 sec)
Statement prepared
　（3）执行

　　我们通过EXECUTE stmt_name [USING @var_name [, @var_name] ...]的语法来执行预编译语句
　　
mysql> set @a=999,@b='hello';
Query OK, 0 rows affected (0.00 sec)
 
mysql> execute ins using @a,@b;
Query OK, 1 row affected (0.01 sec)
Records: 1  Duplicates: 0  Warnings: 0
 
mysql> select * from t;
+------+-------+
| a    | b     |
+------+-------+
|  999 | hello |
+------+-------+
1 row in set (0.00 sec)

可以看到，数据已经被成功插入表中。

MySQL中的预编译语句作用域是session级，但我们可以通过max_prepared_stmt_count变量来控制全局最大的存储的预编译语句。

mysql> set @@global.max_prepared_stmt_count=1;
Query OK, 0 rows affected (0.00 sec)
 
mysql> prepare sel from 'select * from t';
ERROR 1461 (42000): Can't create more than max_prepared_stmt_count statements (current value: 1)

当预编译条数已经达到阈值时可以看到MySQL会报如上所示的错误。

（4）释放
　　如果我们想要释放一条预编译语句，则可以使用{DEALLOCATE | DROP} PREPARE stmt_name的语法进行操作:在这里插入代码片

mysql> deallocate prepare ins;
Query OK, 0 rows affected (0.00 sec)

六：为什么PrepareStatement可以防止sql注入

原理是采用了预编译的方法，先将SQL语句中可被客户端控制的参数集进行编译，生成对应的临时变量集，再使用对应的设置方法，为临时变量集里面的元素进行赋值，赋值函数setString()，会对传入的参数进行强制类型检查和安全检查，所以就避免了SQL注入的产生。下面具体分析

（1）：为什么Statement会被sql注入

因为Statement之所以会被sql注入是因为SQL语句结构发生了变化。比如：

“select*from tablename where username=’”+uesrname+
“‘and password=’”+password+"’"
　　在用户输入’or true or’之后sql语句结构改变。

select*from tablename where username=’‘or true or’’ and password=’’
　　这样本来是判断用户名和密码都匹配时才会计数，但是经过改变后变成了或的逻辑关系，不管用户名和密码是否匹配该式的返回值永远为true;

（2）为什么Preparement可以防止SQL注入。

因为Preparement样式为

select*from tablename where username=? and password=?

该SQL语句会在得到用户的输入之前先用数据库进行预编译，这样的话不管用户输入什么用户名和密码的判断始终都是并的逻辑关系，防止了SQL注入

简单总结，参数化能防注入的原因在于，语句是语句，参数是参数，参数的值并不是语句的一部分，数据库只按语句的语义跑，至于跑的时候是带一个普通背包还是一个怪物，不会影响行进路线，无非跑的快点与慢点的区别。

七：mybatis是如何防止SQL注入的

1、首先看一下下面两个sql语句的区别：

<select id="selectByNameAndPassword" parameterType="java.util.Map" resultMap="BaseResultMap">
select id, username, password, role
from user
where username = #{username,jdbcType=VARCHAR}
and password = #{password,jdbcType=VARCHAR}
</select>

<select id="selectByNameAndPassword" parameterType="java.util.Map" resultMap="BaseResultMap">
select id, username, password, role
from user
where username = ${username,jdbcType=VARCHAR}
and password = ${password,jdbcType=VARCHAR}
</select>

mybatis中的#和$的区别：

1、#将传入的数据都当成一个字符串，会对自动传入的数据加一个双引号。
　　
如：where username=#{username}，如果传入的值是111,那么解析成sql时的值为where username=“111”, 如果传入的值是id，则解析成的sql为where username=“id”.

*2、$将传入的数据直接显示生成在sql中。\ast 如：whereusername=${username}，如果传入的值是111,那么解析成sql时的值为where username=111；
如果传入的值是;drop table user;，则解析成的sql为：select id, username, password, role from user where username=;drop table user;
　　3、#方式能够很大程度防止sql注入，$方式无法防止Sql注入。4、$方式一般用于传入数据库对象，例如传入表名.
　　5、一般能用#的就别用$，若不得不使用“${xxx}”这样的参数，要手工地做好过滤工作，来防止sql注入攻击。
　　6、在MyBatis中，“$xxx”这样格式的参数会直接参与SQL编译，从而不能避免注入攻击。但涉及到动态表名和列名时，只能使用“${xxx}”这样的参数格式。所以，这样的参数需要我们在代码中手工进行处理来防止注入。
【结论】在编写MyBatis的映射语句时，尽量采用“#{xxx}”这样的格式。若不得不使用“${xxx}”这样的参数，要手工地做好过滤工作，来防止SQL注入攻击。

mybatis是如何做到防止sql注入的
　　MyBatis框架作为一款半自动化的持久层框架，其SQL语句都要我们自己手动编写，这个时候当然需要防止SQL注入。其实，MyBatis的SQL是一个具有“输入+输出”的功能，类似于函数的结构，参考上面的两个例子。其中，parameterType表示了输入的参数类型，resultType表示了输出的参数类型。回应上文，如果我们想防止SQL注入，理所当然地要在输入参数上下功夫。上面代码中使用#的即输入参数在SQL中拼接的部分，传入参数后，打印出执行的SQL语句，会看到SQL是这样的：

select id, username, password, role from user where username=? and password=?
　　不管输入什么参数，打印出的SQL都是这样的。这是因为MyBatis启用了预编译功能，在SQL执行前，会先将上面的SQL发送给数据库进行编译；执行时，直接使用编译好的SQL，替换占位符“?”就可以了。因为SQL注入只能对编译过程起作用，所以这样的方式就很好地避免了SQL注入的问题。

【底层实现原理】MyBatis是如何做到SQL预编译的呢？其实在框架底层，是JDBC中的PreparedStatement类在起作用，PreparedStatement是我们很熟悉的Statement的子类，它的对象包含了编译好的SQL语句。这种“准备好”的方式不仅能提高安全性，而且在多次执行同一个SQL时，能够提高效率。原因是SQL已编译好，再次执行时无需再编译
　　
　　参考：https://www.cnblogs.com/myseries/p/10821372.html大大知识搬运工-自由门连接