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

华中科技大学计算机学院 《信息系统应用安全》实验报告 实验名称 ：简单网站的SQL注入攻击 姓名： 项中村 班级： 信安0803 学号： U200814066 教师评语： 背景： 所谓的SQL Injection，即SQL注入用户可以提交一段数据库查询代码，根据程序返回的结果，最终达到欺骗服务器执行恶意的SQL命令获得某些他想得知的数据随着B/S模式(Browser/Server，浏览器/服务器)应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。SQL注入是从正常的WWW端口访问，而且表面看起来跟一般的Web页面访问没什么区别，所以目前市面的防火墙都不会对SQL注入发出警报，如果管理员查看IIS日志，可能被入侵很长时间都不会发觉。 国内的网站用ASP+Access或SQLServer的占70%以上，PHP+MySQ占L20%，其他的不足10%。ASP动态网页中，有时一个动态网页中可能只有一个参数，有时可能有N个参数，有时是整型参数，有时是字符串型参数，不能一概而论。总之只要是带有参数的动态网页且此网页访问了数据库，那么就有可能存在SQL注入。如果ASP程序员没有安全意识，不进行必要的字符过滤，存在SQL注入的可能性就非常大。SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串调整IE的配置否则，不论服务器返回什么错误，IE都只显示为HTTP 500服务器错误。为了全面了解网页回答的信息把IE菜单-工具-Internet选项－高级－显示友好HTTP错误信息前面的勾去掉。一般来说，SQL注入一般存在于形如：HTTP://xxx.xxx.xxx/abc.asp?id=XX等带showdetail.asp?id=”一个出现频率比较高。因此我随意添加了id=44以“showdetail.asp?id=44”进行关键字搜索，这次出现的链接都是符合HTTP://xxx.xxx.xxx/abc.asp?id=XX的，我开始一个一个的点击并给这些动态网站发送一个请求，改变其中的id=语句，一个额外的单引号，来试图取消其中的SQL语句(例如，如 HTTP://xxx.xxx.xxx/ showdetail.asp?id= )寻找是否存在SQL注入漏洞。分析返回的回复，检查错误消息是否表示发送到SQL服务器的参数没有被正确加码(encoded)，如果如此，那么表示可对该网站进行SQL注入攻击/map/showdetail.asp?id=44，其正常界面为下图 在加上单引号后返回了错误信息如图： 其实，通过一定了解以后，我知道这并不是最好的方法。原因有两个，首先，不一定每台服务器的IIS都返回具体错误提示给客户端，如果程序中加了cint(参数)之类语句的话，SQL注入是不会成功的，但服务器同样会报错，具体提示信息为处理 URL 时服务器上出错。其次，部分对SQL注入有一点了解的程序员，认为只要把单引号过滤掉就安全了，这种情况不为少数，如果用单引号测试，是测不到注入点的。更准确的方法是经典的1=1、1=2测试法，但是由于工作相对繁琐，所以我选择用单引号筛选出网站后再用1=1、1=2测试法深入验证。 对/map/showdetail.asp?id=44 进行验证如下： /map/showdetail.asp?id=44;and 1=1 /map/showdetail.asp?id=44;and 1=2 通过以上步骤判断出： /map/showdetail.asp?id=44存在注入点。 接下来要进行SQL注入了。根据id=44判断注入参数类型为数字型，那么其SQL语句原貌大致为：Select * from 表名 where 字段=44。注入的参数为ID=44 and [查询条件]，即是生成语句：Select * from 表名 where 字段=49 And [查询条件]。 接着将查询条件替换成SQL语句，猜解表明。 例如：and 0(select count(*) from Admin)或者and 0(select count(*) from admin)或者其他可能表名。如果页面显示正常，说明附加的查询条件成立，既确定表名。此处我舍弃了大部分已经寻找到的存在注入点的网站，因为在使用了很多通用的规则表名后还是找不到他们的表名，我觉得在此次有很大的运气成分，当然后面猜测段名等也是。 猜解出该站点表名就是admin 表名猜出来后，将Count(*)替换成Count(字段名)，用同样的原理猜解字段名。猜解出字段名有id和pwd 在得到表名和字段名之后，首先要猜解管理员的id号。很幸运，该网站只有有一个即id=1 在表名和列名猜解成功后，