如何向非技术人(程序猿)解释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这个单词表达,我还不得而知。

你可能感兴趣的:(sql注入)