这一篇我们讨论一下伪命题SQL注入
首先简单介绍SQL注入的原理，当我们从用户界面采集文本框输入内容传到服务端，并用此内容于查询数据库的时候，在不考虑安全的情况下可能会有人使用sql语句拼接，而如果输入的是特殊的字符串，sql语句的原意就会被篡改。
打比方，获取采集数据文本 account 和password，然后拼接 sql = "select * from user where account = '" + account + "' and password='" + password + "';";
这样的查询语句应该不难理解，然后我们在password中填写1' or 1=1 '
这样sql语句就被拼接为“select * from user where account = 'xxx' and password = '1' or 1=1 '';”
于是乎。。。。在完全不知道密码的情况下，登陆成功。
但是这种例子是个超级伪命题，因为通常账号密码的验证都是sql查账号然后比对密码，而且密码通常经过加密。所以这个例子只是为了让大家理解sql注入的原理。
现在我们来看个稍微正常的例子：
这是一个查询电影的例子，我们在输入行中打入“123' UNION SELECT 1,2,3,DATABASE(),VERSION(),4,5'”，于是乎，数据库的信息就被获取到了
然后我们可以通过特殊的查询语句，依次获取当前数据库所含的表，每张表的数据等各种信息。
到这一步为止，能做到窃取多少数据就看攻击者的数据库基础啦。
然而问题在于，sql注入真的就是个伪命题，因为，现阶段基本上正常网站都是完全没法用sql注入攻击的，这一点与前几章的攻击手段形成鲜明对比。。
我们都知道，如java的preparedstatement、php的pdo等等都支持占位符功能，占位符不仅可以用于绑定blob类型的数据，而且可以防御sql注入，而且是绝对防御。
那么问题来了，为什么这玩意可以防范呢？查询网上资料，大多数人都说是把单引号变成"\'"，的确在正常情况下这种方式的确可以有效防范sql注入，但是人类还是非常机智的，很快就有人发现0xbf27 字符可以有效**这种转义。然而依旧没法**占位符绑定。换句话说，这已经非常明显地表明，占位符绑定并不是网上大多数博客所说的特殊字符转义那么简单了。
那么问题来了，究竟是怎么做到的呢，首先我们要考虑一件事情，占位符的功能究竟是数据库本身完成的还是开发语言来完成的。假设是数据库本身完成的，也就是说数据库底层完成了占位符绑定，那么这其中原理就不是开发语言的范畴，也就是说本身就是数据库对应的一种机制，也就不需要考虑其原理。反之如果是开发语言完成的，我们就有必要去了解底层究竟如何和数据库进行交互的。
答案是前者，这表明我们可能并没有办法知道数据库是怎么实现这一功能的：
SET @sql = "update t_admin set c_name = ? WHERE c_name = ?";
SET @param1 = 'admin';
SET @param2 = 'admin1';
PREPARE stmt FROM @sql;
EXECUTE stmt USING @param1, @param2;
DEALLOCATE PREPARE stmt;
很简单的例子，来说明数据库sql语句如何绑定数据。并不是网上所说的字符转义。
完毕！！！