黑客三兄弟是如何获取登录用户cookie的（续）

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

1.另辟蹊径

老二给大家提了一个建议：“要不我们试一试SQL注入？”

老大说：“老掉牙的东西了，1998年都有了，估计漏洞也没几个了吧？”

“那不一定啊，反正我们要节源开流，我最近找了一个网站，可以让老三来练练手。”

老三一听又可以学到新东西了，非常兴奋：“二哥，你先给我说说什么是SQL注入。”

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

“这个网站有个功能，根据id来查看用户信息，?id=xxxx， 对应的SQL可能是这样的：”

string sql ="SELECT id , name， age from users WHERE id="+<id>; 

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

就会把张大胖对应的那条记录给取出来了。

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

老二说：“作为黑客，如果遇到了这种情况，那可是个好机会啊，你想想，如果我输入了 ?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数据都给提取出来了！” 老三惊叹。

2.牛刀小试

老二笑道：“三弟，原理很简单吧，但是想用好可不容易，你再试试这个网站：?id=U123，这个URL能显示ID为U123的博客摘要。

老三迫不及待地把url 改为 ?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应该这么写：?id=U123' or '1'='1

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

“奥，原来是这样，看来拼接字符串也真的不容易啊！” 老三赶紧继续试验。

可是浏览器还是没有把所有博客都显示出来，还是只显示了一条， 但不是U123对应的那条博客。

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

“应该是这样。”

“那这所谓的SQL注入也没啥用处啊。 ”

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

3.疯狂注入SQL

老二说：“大哥说得非常对， 我们换一个URL ?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 ， 你猜猜为什么要这么做？”