简单网站的SQL注入攻击实验归纳总结报告.doc

华中科技大学计算机学院 《信息系统应用安全》实验报告 实验名称 ：简单网站的SQL注入攻击 姓名： 项中村 班级： 信安0803 学号： U200814066 教师评语： 背景： 所谓的SQL Injection，即SQL注入，就是用户可以提交一段数据库查询代码，根据程序返回的结果，最终达到欺骗服务器执行恶意的SQL命令，获得某些他想得知的数据。随着B/S模式(即Browser/Server，浏览器/服务器)应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。但是由于使用这个模式编写程序入门简单，程序员的水平及经验参差不齐，很多程序员在编写代码时，忽略了对数据库的保护，没有加入对入户输入数据的合法性的判断，导致程序存在着安全隐患，用户可以构造一些SQL语句发送到数据库，从而非法的获得想要的数据。 因为SQL注入是从正常的WWW端口访问，而且表面看起来跟一般的Web页面访问没什么区别，所以目前市面的防火墙都不会对SQL注入发出警报，如果管理员不查看IIS日志，甚至有可能被入侵很长时间都不会发觉。  因为目前国内的网站用ASP+Access或SQLServer的占70%以上，PHP+MySQ占L20%，其他的不足10%。所以，SQL注入攻击对于大部分的网站都有很大威胁性，ASP动态网页中，有时一个动态网页中可能只有一个参数，有时可能有N个参数，有时是整型参数，有时是字符串型参数，不能一概而论。总之只要是带有参数的动态网页且此网页访问了数据库，那么就有可能存在SQL注入。如果ASP程序员没有安全意识，不进行必要的字符过滤，存在SQL注入的可能性就非常大。然而，程序员在编写代码的过程中很难做到毫无疏漏面面俱到，只能通过长时间的积累熟知各类攻击方式，不断更新完善代码。 正文： 在了解了有关SQL注入的基本知识以后，我开始着手进行SQL注入攻击的实验。 因为SQL注入攻击是不断构造SQL语句把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串并通过返回的信息来确定语句是否正确，所以，首先需要调整IE的配置，否则，不论服务器返回什么错误，IE都只显示为HTTP 500服务器错误。为了全面了解网页回答的信息作为提示，根据网上的提示，把IE菜单-工具-Internet选项－高级－显示友好HTTP错误信息前面的勾去掉。如下图所示 对于我这样的初学者来说，进行SQL注入攻击实验最难的事情就是找到一个存在简单注入漏洞的网站。因为大部分网站经过多年时间的维护，简单的漏洞早就已经被网站维护人员屏蔽了，而更复杂的漏洞则需要大量的时间积累有关的经验，对此类网站有更深的理解，甚至本身就是一个维护员或编写者。因此，我的大量时间就花费在需找适合攻击的网站。 一般来说，SQL注入一般存在于形如：HTTP://xxx.xxx.xxx/abc.asp?id=XX等带有参数的ASP动态网页中。所以我开始在google搜索中以“.asp?id=”作为关键字进行搜索，但我发现这样的搜索效率太低了。于是我随即选取几个网站的需要进行数据库调用的网页，将他们的url进行对比后发现，“showdetail.asp?id=”一个出现频率比较高。因此我随意添加了id=44以“showdetail.asp?id=44”进行关键字搜索，这次出现的链接都是符合HTTP://xxx.xxx.xxx/abc.asp?id=XX的，我开始一个一个的点击并给这些动态网站发送一个请求，改变其中的id=语句，在url的最后加一个额外的单引号，来试图取消其中的SQL语句(例如，如 HTTP://xxx.xxx.xxx/ showdetail.asp?id=44' )寻找是否存在SQL注入漏洞。分析返回的回复，检查错误消息是否表示发送到SQL服务器的参数没有被正确加码(encoded)，如果如此，那么表示可对该网站进行SQL注入攻击。 在整个寻找的过程中，大部分网站只会返回参数错误，还有一两个网站弹出如下图的提示将我吓了一跳，考虑再三后才决定继续实验，真要出状况了我就把老师供出去。 经过长时间的枯燥繁琐的寻找后，我终于找到了几个可以进行SQL注入攻击的网站。这里省略了其他攻击无果的网站，只附上最终成功的： /map/showdetail.asp?id=44，其正常界面为下图 在加上单引号后返回了错误信息如图： 其实，通过一定了解以后，我知道这并不是最好的方法。原因有两个，首先，不一定每台服务器的IIS都返回具体错误提示给客户端，如果程序中加了cint(参数)之类语句的话，SQL注入是不会成功的，但服务器同样会报错，具体提示信息为处理 URL 时服务器上出错。其次，部分对SQL注入有一点了解的程序员，认为只要把单引号过滤掉就安全了，这种情况不为少数