如何向非技术人（程序猿）解释SQL注入？

前两天看博客园新闻，有一篇文章名为《我该如何向非技术人解释SQL注入？》（http://kb.cnblogs.com/page/515151/）。是一个外国人写的，伯乐在线翻译的。我当时看了一下，觉得蛮通俗易懂的，对于不懂编写程序及数据库SQL语言的人来说，理解应该没有问题。

今天早上上班坐地铁，看到糗百里的一个段子（原谅一个程序猿看跟编程技术不相关网站行为），笑过之后脑海中突然就跳出了这几个字“SQL注入”！先把那个段子Copy一份，大家先轻松一下：

一哥们是送快递的，一天送快递到人家楼下，买家名字叫“猴子请来的逗比”，打电话开口就问：请问你是猴子请来的逗比吗？只听电话那头传来一声大吼：你才是逗比，你全家都是逗比！哥们只好发了个短信说是送快递的在你家楼下，没两分钟，买家下来了，说道：那个，我就是猴子请来的逗比。

我不知道其他程序猿如何看待这个笑话，但是我觉得用这个生活例子来理解SQL注入，简直太贴切了！

程序中传递SQL语句到数据库中，是以字符串的形式传递，数据库拿到完整的SQL语句字符串进行解析执行。比如说假设笑话中的买家叫张三，快递员就会打电话问：请问你是张三吗？快递员就是程序端，他把SQL字符串发送给买家，买家对“请问你是张三吗？”进行解析执行，发现这是在问他是不是名字叫张三这个人，然后判断一下给出执行结果——我是/我不是。而笑话中的买家居然叫“猴子请来的逗比”，这是买家没有将SQL语句做参数化查询，仍然将买家的名字拼接到了“请问你是”之后，并将整个SQL字符串发送给卖家，买家对“请问你是猴子请来的逗比吗？”进行解析执行，错误地理解为“请问你是逗比吗？而且还是猴子请来的”这个意思。这就导致了快递员要表达的意思，与买家理解的意思不一致的情况出现。为什么呢？因为名字中的一部分（而且大多数情况是前一部分）与“请问你是”这个执行动作能组合产生出新的执行动作语义，导致本来的执行动作语义被改变成新的执行动作语义，最终使得买家的执行结果“你才是逗比，你全家都是逗比”，并不是快递员想要的执行结果“我是/我不是”（不知道我这么说是不是符合语文上对词句的定义）。

后来又想到了参数化查询，这个SQL注入的基本防范方式。其实上面这个笑话如果把第三句“买家名字叫“猴子请来的逗比””去掉，我想大家看到“。。。你全家都是逗比！”这里，并不会觉得有什么问题。因为我们理解的语义跟买家理解的语义一样了，都跟快递员表达的语义不同。而这个笑话引发笑点的前提就是第三句，它正是起到了参数化查询的作用。当我们看到快递员打电话的问句时，我们的理解是“请问你是名字叫“猴子请来的逗比”的买家吗？”，理解为“请问你是买家吗？而且你的名字是“猴子请来的逗比””，这个语义就与快递员想要表达的语义一致了。而SQL语句的参数化查询也是起到这个作用，举个简单的例子：select * from users where user_name='xxx'。当程序端生成这个SQL字符串，它想要表达的语义就是从用户表中查找用户名是xxx的用户记录。如果不用参数化查询，并被SQL注入为"a' or 1=1--"，替换xxx之后SQL字符串为select * from users where user_name='a' or 1=1--'，这时数据库解析的语义就变为从用户表中查询用户名为a或者1=1的所有用户记录并忽略其后的字符串，数据库解析的语义明显跟程序端要表达的语义不一致，导致数据库返回给程序端的执行结果并不是程序端想要的执行结果（或者说编写程序的程序猿预期返回的执行结果）。而采用参数化查询后就变成这样：select * from users where user_name=@username(@username="a' or 1=1--")，数据库解析的语义为从用户表中查找用户名为@username变量中存储值的用户记录，@username变量的值为a' or 1=1--，显然一般正常情况下，没有人的用户名叫这个，因此也不会返回错误的执行结果。这样SQL语句参数化查询就起到了防SQL注入的目的，其实生活中也有类似的情况，比如上面那个笑话，如果大家跟我有一致的看法，以后也可以用上面那个生活例子向非技术人解释SQL注入这个专业名词。

最后说一句，其实SQL注入并不是中国人起的名字，这个专业名词是从SQL injection翻译得来，至于外国友人对于SQL注入这个状况为什么用injection这个单词表达，我还不得而知。