趣解SQL注入原理

    上次说到三兄弟用XSS和CSRF这两个工具获利颇丰，后来人们在编程中很注意防范，这两个漏洞越来越少了，逼得三兄弟不得不开辟新财路。



    一、另辟蹊径

🙌🏦🍞‼🦬‎

   
    老二给大家提了一个建议：“要不我们试一试SQL注入？”老大说：“老掉牙的东西了，1998年都有了，估计漏洞也没几个了吧？”

    “那不一定啊，反正我们要节源开流，我最近找了一个网站，可以让老三来练练手。”老三一听又可以学到新东西了，非常兴奋：“二哥，你先给我说说什么是SQL注入。”

👃🗼🍖♏🕊‏

    “原理非常简单，比如网站有个users表格，数据如下：”


    “这个网站有个功能，根据id来查看用户信息，http://xxxx.com/user?id=xxxx， 对应的SQL可能是这样的：”
👦‌🩳📞😒✋
    string sql ="SELECT id , name， age from users WHERE id="+<id>;

    如果用户在浏览器的URL 是 http://xxxx.com/user?id=1，那真正执行的SQL就是这样：SELECT id , name， age from users WHERE id=1


👃🌦🍞📶🐮‏    就会把张大胖对应的那条记录给取出来了。

    老三说：“这没什么啊，程序不都是这么写的吗？”

    老二说：“作为黑客，如果遇到了这种情况，那可是个好机会啊，你想想，如果我输入了 http://xxxx.com/user?id=1 or 1=1 会发生什么状况？”

👨‍🚒‏🧢🗝😇🦷

    老三把id的值代入到sql中，有趣的事情发生了，sql变成了这样：

    SELECT id , name， age from users WHERE id=1 or 1=1

👌🎢🥄↔🐠‍    “哇塞，这是哪个天才想出来的注意啊，or 1=1 会让where字句的值一直是true， 那岂不把所有的user数据都给提取出来了！” 老三惊叹。#366:

   二、牛刀小试
   
    老二笑道：“三弟，原理很简单吧，但是想用好可不容易，你再试试这个网站：www.badblog.com/viewblog?id=U123，这个URL能显示ID为U123的博客摘要。
🧠🛩🍏🉑🐙‍   
    老三迫不及待地把url 改为 www.badblog.com/viewblog?id=U123 or 1=1 ， 心想最终的sql 就是： SELECT xxx FROM xxx WHERE id =U123 or 1=1 ，他兴奋地等待所有的博客摘要显示出来。

    可是，浏览器只是提示：“无效的博客ID”

👁🚤🍞➡🦠‍

    这是怎么回事？ 轮到我怎么不行了呢？老三挠了挠头。

    老二解释道：其实吧，你没有注意到，那个id不是一个数字，是一个字符串("U123")，背后的SQL可能是这样的：
   
    string sql = "SELECT xxx FROM xxx WHERE id='" + <id> +"'";

🥷‎👜⌨😇🤞

   
    字符串的话需要用单引号括起来，所以URL应该这么写：www.badblog.com/viewblog?id=U123' or '1'='1

    这样才能生成有效的SQL：SELECT xxx FROM xxx WHERE id ='U123' or '1'='1'

👨‍🎨‎👗🖨🤖🖕

    “奥，原来是这样，看来拼接字符串也真的不容易啊！” 老三赶紧继续试验。可是浏览器还是没有把所有博客都显示出来，还是只显示了一条， 但不是U123对应的那条博客。

    老三想了想说：“二哥，是不是SQL执行成功了，但是内部的程序永远只返回SQL结果集的第一行啊。”

    “应该是这样。”
🔥🦞📳🦕‌
    “那这所谓的SQL注入也没啥用处啊。 ”

    在一旁忙活XSS的老大笑了： 咱们做黑客的，得有无比的耐心，还得充分发挥想象力才行啊。#379:

👩‍🩳🪗😂🦷

    三、疯狂注入SQL
   
    老二说：“大哥说得非常对， 我们换一个URL www.badblog.com/news?id=3，我实验过，这个URL也有SQL注入漏洞，并且如果我输入id=3 or 1=1 , 就会把数据库中所有的新闻给显示出来。”


👄🛩🍭☣🐞‎    “现在我们利用这个漏洞： 努力把这个网站的用户名和密码给挖出来。”

    老三瞪大了眼睛，似乎有点不相信：“不登录它的服务器，仅仅通过浏览器就可以吗？”

    “是可以滴，但也要看看我们运气如何，我们假设这个网站是个Mysql数据库，接下来你得懂一点Mysql 数据库知识了。我们分三步走，首先获取这个数据库的库名，然后获取所有的表名，最后找到用户表，从中select 数据。”

🙏🔥🍚‼🪶‍

    “我似乎有点明白了，就是不断地往那个URL注入SQL语句，对吧？”

    “对的，第一步，我们已经能猜出那个URL对应的SQL是：SELECT xxx FROM xxx WHERE xx=<id>，并且我们知道，这个SELECT出的数据中至少有两列（标题和内容），现在我们注入数据，形成一个这样的sql 出来：
   

👨‍🚒‍🎒💿🤬👍

    SELECT xxx FROM xxx WHERE xx=3 union select 1,2,3,4,5,6,7,8 ， 你猜猜为什么要这么做？”

    “这难不倒我，union 要求两个结果集的列必须个数相同，现在你在union的第二部分输入了8个column ,就是猜测union的第一个字句也有8 个column， 对不对？”

    老二说：“没错，孺子可教，如果这个SQL执行不正常（界面会有错误）， 我们就再尝试，增加或减少列，直到成功为止。”老三试了几次，等到列数为3的时候，SELECT xxx FROM xxx WHERE xx=3 union select 1,2,3
👍🍇❌🦬‌
    浏览器页面突然显示了出了两条新闻， 一条有正常的标题和内容， 另外一条的标题是2, 内容是3, 正是老三构造出来的。


    老三说：“理解了， 关键点是第二列和第三列的值会被显示到浏览器的界面中，接下来我们可以这么做：SELECT xxx FROM xxx WHERE xx=3 union select 1,2,database() ”
🦷⛵🧊🚷🦦‎
    于是就获得了数据库的名称: epdb


    老二心想，三弟悟性确实不错啊，数据库也扎实。他说：“那我问你，你怎么才能获得这个数据库的所有表的名称？”
🙌🏦🍞🈚🐤‎
    “这难不倒我，mysql 中 information_schema.tables 这个表保存着所有的表名，现在知道了数据库的名称，只需要把数据库名称传递过去就行了”

    SELECT xxx FROM xxx WHERE xx=3 union select 1,2,table_name from information_schema.tables where table_schema='epdb'

🦷🌧🍏🆗🐤‎

    果然，epdb这个数据库所有的表都取出来了：


    老三指着ep_users 大叫，“二哥，用户表肯定就是这个了！”

🙌🛩🍞🉑🐮‍    老大扭过头来：“小点声，老子正处于XSS的紧要关头。”#393:

。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
   
    老二说：“接下来你知道怎么办了吧？”
🖕🍓ℹ🐡‌
    老三点点头，又构造出一个sql ，把ep_users的列名全取出来：
   
    SELECT xxx FROM xxx WHERE xx=3 union select 1,2,column_name from information_schema.columns where table_name='ep_users'

🤙🗼©🐅‍

    看来这个ep_users有这么几个column : id ,name, pwd。
   
    再接再厉，把ep_users表的数据给选出来：

🙌🚠🥩🆎🐯‏    SELECT xxx FROM xxx WHERE xx=3 union select 1,name,pwd from ep_users


    四、破解密码
    👮‍♂️‌👚🔌😇👍
    “二哥，二哥，看到用户名和密码了，著名的张大胖（zhangdapang）的密码也暴露了！” 老三忍不住再次欢呼， 老大回过头来就是一巴掌。

    “可是，这密码不是明文的啊！看看这乱七八糟的字符。” 老三挨了一巴掌后清醒了一点。

    “当然了，现在的数据库基本上都不会存明文的密码了，2012年那时CSDN的数据库被黑客曝光，大家震惊地发现，密码都是明文存储的，由于很多人在多个网站都用同样的密码，明文密码的暴露一下子让很多网站都面临攻击的威胁。”
🤌🦼🍚🆗🦠‍
    “那这些密码是加密的吗？ ”

    “是通过Hash的算法计算出来的。”

🧑‍🌾‎🎒💿😴👆

    “这个Hash值会保存到数据库当中，等到你下次登录，输入用户名和密码的时候，就会再次对密码进行同样的hash计算，然后和数据库的值比较，看看是不是相同。” 老二补充道。

    “这个hash 我知道，是不可逆的运算，所以即使被偷取了，也无法得到明文密码。二哥，我们折腾了半天，难道白忙活了吗？”
👨‍⚕️‌🩴🪟😘✊
    “不不，有几种办法可以去破解密码，一种就是猜测，比如我准备了很多人们最常用的密码，然后把这些密码也做hash操作，和数据库密码对比，如果匹配，我就知道明文密码了。

    还有一种就是查表，我事先把明文密码和计算好的hash值形成一个对照表，然后用数据库中密码的hash值去对照表中查找，如果找到了，明文密码也就有了。当然为了提高效率，人们还制作了所谓彩虹表。”（一个明文密码和Hash值的对照表）


✌🗼🍞♂🦕‏    “二哥你赶快查一下啊， 我真是想知道著名的张大胖(zhangdapang)的密码是多少！”

    老二在电脑前面敲了半天，沮丧地说：“看来不好查，这个密码应该是加盐(salt)了。”

    “加盐？”
👍🛑🍖🦠‍
    “对，他们给每个密码都加了一了随机数，然后再做Hash操作。 这样一来，通过查找的方式就难于破解了！”


    没想到老三神秘地一笑：“二哥，没那么麻烦，我现在已经用管理员账号(admin)登录后台了！”
⛵🥄♂🐤‍
    “啊？！你怎么做到的？”#j347:

    “很简单，刚才我试了下登录的功能，发现也有SQL注入漏洞，那个SQL可能是这样子的：

✊🌧🥭📳🦚‏

    select xx from ep_users where user='<username>' and pwd='<password>'

    然后代码会判断这个sql 返回的结果集数目是否为0， 如果不为0就认为登录成功。

    那我通过注入把它改写成：👵‍🎩✏🤔👄

    select xxx from ep_users where user='admin' and password='password' OR '1'='1'

    然后我就立刻就登录了，由于用户名是admin，现在我已经有了管理员权限了！可以为所欲为了。”#j336:
👨‍🎨‏🩲📥😴🧠
    老二有点尴尬：我忙活了半天，还不如这小子找的一个漏洞。

    五、后记
   
    本文描述了SQL注入的原理，实际上SQL注入漏洞的危害非常巨大，因为黑客可以利用漏洞去执行数据库中很多函数（mysql的LOAD_FILE, SELECT INTOFILE），存储过程（例如臭名卓著的xp_cmdshell）, 可以向服务器植入代码。 如果有数据库账号适当权限，还可以创建表，删除表，非常可怕。
👏⛪🍓✡🦜‌
    防御SQL注入的最佳方式，就是不要拼接字符串， 而要使用预编译语句，绑定变量，不管你输入了什么内容，预编译语句只会把它当成数据的一部分。

    String sql = "select id from users where name=?";
    PreparedStatement pstmt = conn.prepareSatement(sql);
✋🎠🫑🚭🐖‏    pstmt.setStrig(1,request.getParameter("name");
    pstmt.executeQuery();