WEB漏洞-逻辑越权之登录脆弱及支付修改

支付篡改

商品购买流程

选择商品和数量-选择支付及配送方式-生成订单编号-订单支付选择-完成支付

常见修改参数

商品编号 ID，购买价格，购买数量，支付方式，订单号，支付状态等

常见修改方法

支付漏洞之总结
替换支付，重复支付，最小额支付，负数支付，溢出支付，优惠券支付等

6000 大米测试产品
/index.php?m=Member&a=gobuy&iscart=0&id=127&name=%E5%A4%A7%E7%B1%B3%E6%B5%8B%E8%
AF%95%E4%BA%A7%E5%93%81&qty=1&price=6000&gtype=%E7%81%B0%E8%89%B2&pic=/Public/Uplo
ads/thumb/thumb_1393218295.jpg
5400 大米手机 cms
/index.php?m=Member&a=gobuy&iscart=0&id=70&name=%E5%A4%A7%E7%B1%B3%E6%89%8B%E6%9
C%BACMS&qty=2&price=5400&gtype=%E7%81%B0%E8%89%B2&pic=/Public/Uploads/thumb/thumb_13
93218295.jpg
index.php?s=/wap/pay/wchatQrcodePay 微信支付
index.php?s=/wap/pay/alipay 支付宝支付
index.php?s=http://www.xiaodi8.com/alipay 调用其他的支付接口
$pay_name=$_GET['s'];

某商场系统商品支付逻辑测试-数量,订单

购买数量

1、点击购买抓包，发现参数里有num，与购买的数量一样2、修改num为-1，放行，发现应付金额变成0

3、提交后显示库存不足

4、分析：在error_message.php中找到了库存不足的变量名

5、利用搜索查找low_stocks

6、发现提交的goods_sku[1]也就是num小于0的话会

7、把$goods_sku[1]<0去掉
8、成功了2次，但是后面又不行了

8、提交订单后发现弹出操作失败，但是过一会刷新页面就可以了，大概是系统发现异常，进行暂时的操作限制，后面又发现只有-1可以，-100或者其他行不通，暂时不知道原因，

订单编号

用其中一单伪造另一单
1、买一单到支付页面发现流水号

2、立即支付抓包，发现流水号与url后面参数的no相同

3、买一单较低的进入到支付页面，把no改成上面的no
4、放行数据包，发现由原来的200变成2000，没有成功

某建站系统商品支付逻辑测试-价格,商品

购买价格

1、购买抓包

2、发现url后面的参数有价格，把价格改成6

3、放行数据包，成功修改

4、提交订单

5、6000 是存储到数据库里，安全的做法：以数据库的数据值为准

商品编号

1、将立即购买抓包后的数据包url中的参数id和name换成需要更改的即可
2、测试产品

对应的id和name

id=66&name=%E6%B5%8B%E8%AF%95%E4%BA%A7%E5%93%81

3、大米测试产品

对应的id和name

id=127&name=%E5%A4%A7%E7%B1%B3%E6%B5%8B%E8%AF%95%E4%BA%A7%E5%93%81

4、抓取测试产品的数据包，将id和name更改为大米测试产品的，放行数据包，可以看出编号和名称都改变了

登录脆弱

1.登录点暴力破解
2.HTTP/HTTPS 传输
3.Cookie 脆弱点验证
4.Session 劫持
5.Session 固定
6.验证密文比对安全测试
会话劫持加固定

session劫持

含义：
　会话劫持（Session hijacking），这是一种通过获取用户Session ID后，使用该Session ID登录目标账号的攻击方法，此时攻击者实际上是使用了目标账户的有效Session。会话劫持的第一步是取得一个合法的会话标识来伪装成合法用户，因此需要保证会话标识不被泄漏。

攻击步骤：
　1、 目标用户需要先登录站点；
　　2、 登录成功后，该用户会得到站点提供的一个会话标识SessionID；
　　3、 攻击者通过某种攻击手段捕获Session ID；
4、 攻击者通过捕获到的Session ID访问站点即可获得目标用户合法会话。

攻击者获取SessionID的方式有多种：
1、 暴力破解：尝试各种Session ID，直到破解为止；
2、 预测：如果Session ID使用非随机的方式产生，那么就有可能计算出来；
3、 窃取：使用网络嗅探，XSS攻击等方法获得。

对于PHP来说，其内部Session的实现机制虽然不是很安全，但是关于生成Session ID的环节还是比较安全的，这个随机的Session ID往往是极其复杂的并且难于被预测出来，所以，对于第一、第二种攻击方式基本上是不太可能成功的。

对于第三种方式大多使用网络数据通讯层进行攻击获取，可以使用SSL进行防御。

在应用层上也可以做出相应的防御措施：

目前有三种广泛使用的在Web环境中维护会话（传递Session ID）的方法：URL参数，隐藏域和Cookie。其中每一种都各有利弊，Cookie已经被证明是三种方法中最方便最安全的。从安全的观点，如果不是全部也是绝大多数针对基于Cookie的会话管理机制的攻击对于URL或是隐藏域机制同样适用，但是反过来却不一定，这就让Cookie成为从安全考虑的最佳选择。

1、 更改Session名称。PHP中Session的默认名称是PHPSESSID，此变量会保存在Cookie中，如果攻击者不分析站点，就不能猜到Session名称，阻挡部分攻击。
2、 关闭透明化Session ID。透明化Session ID指当浏览器中的Http请求没有使用Cookie来存放Session ID时，Session ID则使用URL来传递。
3、 设置HttpOnly。通过设置Cookie的HttpOnly为true，可以防止客户端脚本访问这个Cookie，从而有效的防止XSS攻击。
4、 关闭所有phpinfo类dump request信息的页面。
5、验证HTTP头部信息
　　　 在http访问头文件：[Accept-Charset、Accept-Encoding、Accept-Language、User-Agent]，浏览器一般发出的头部不会改

使用User-Agent检测请求的一致性。

 1 GET/HTTP/1.1
 2 host:example.org
 3 User-Agent:Firefox/1.0
 4 Accept:text/html,image/png,image/jpeg,image/gif,*/*
 5 Cookie:PHPSESSID=1234
 6 
13                        exit;
14         }
15 }
16 else
17 {      
18 　　$_SESSION['HTTP_USER_AGENT']=md5($_SERVER['HTTP_USER_AGENT']);
19 }
20 ?>

确保User-Agent头部信息一致的确是有效的，如果会话标识通过cookie传递，攻击者能取得会话标识，他同时也能取得其它HTTP头部。由于cookie暴露与浏览器漏洞或跨站脚本漏洞相关，受害者需要访问攻击者的网站并暴露所有头部信息。则攻击者只需重建头部即可进行攻击了。

因此前提需要做好XSS防御！

注意：

在某些版本的IE浏览器中，用户正常访问一个网页和刷新一个网页时发出的Accept头部信息不同，因此Accept头部不能用来判断一致性。

有专家警告不要依赖于检查User-Agent的一致性。这是因为服务器群集中的HTTP代理服务器会对User-Agent进行编辑，而本群集中的多个代理服务器在编辑该值时可能会不一致。

6、 加入Token校验。同样是用于检测请求的一致性，给攻击者制造一些麻烦，使攻击者即使获取了Session ID，也无法进行破坏，能够减少对系统造成的损失。但Token需要存放在客户端，如果攻击者有办法获取到Session ID，那么也同样可以获取到Token。

Session 固定

含义：
　会话固定（Session fixation）是一种诱骗受害者使用攻击者指定的会话标识（SessionID）的攻击手段。这是攻击者获取合法会话标识的最简单的方法。（让合法用户使用黑客预先设置的sessionID进行登录，从而Web不再进行生成新的sessionID，导致黑客设置的sessionId变成了合法桥梁。）

会话固定也可以看成是会话劫持的一种类型，原因是会话固定的攻击的主要目的同样是获得目标用户的合法会话，不过会话固定还可以是强迫受害者使用攻击者设定的一个有效会话，以此来获得用户的敏感信息。
　　
攻击步骤：
1、 攻击者通过某种手段重置目标用户的SessionID，然后监听用户会话状态；
2、 目标用户携带攻击者设定的Session ID登录站点；
3、 攻击者通过Session ID获得合法会话

Web接收sessionID机制：

早期浏览器存贮的sessionID容易暴露、使用URL来传送sessionID
　　首先检查携带cookie是否含有sessionID；若没有则再检查get、post数据中是否含有，若有则使用此数据；没有才会使系统生成一个sessionID发给客户端。（经测试，get与post都不能设置sessionID，也许是被浏览器限制或者被代码本身禁止了吧，不过没关系，咱还有其他方法进行固定sessionID）

重置sessionID方式：

（一）使用客户端脚本来设置Cookie到浏览器。大多数浏览器都支持用客户端脚本来设置Cookie的，例如document.cookie=“sessionid=123”，这种方式可以采用跨站脚本攻击来达到目的。防御方式可以是设置HttpOnly属性，但有少数低版本浏览器存在漏洞，即使设置了HttpOnly，也可以重写Cookie。所以还需要加其他方式的校验，如User-Agent验证，Token校验等同样有效。

测试例子：

html页面（表单），用于跨站脚本攻击

<!DOCTYPE html>
<html>
<head>
    <title>重置sessionID（一）</title>
    <meta charset="utf-8">
</head>
<body>
<form action="./test2.php" method="post">
name：<input type="text" name="name"><br/>
age：<input type="text" name="age"><br/>
<input type="submit" name="" value="提交">
</form>
</body>
</html>

接收表单 ，test2.php

<?php
header("content-type:text/html;charset=utf8");
session_start();
if(!isset($_SESSION['count']))  #自增测试
{
    $_SESSION['count']=0;
}
else
{
    $_SESSION['count']++;
}
echo '$_POST数据:';
echo "
";
print_r($_POST);        #不处理数据直接接收
echo "
";
echo '$_SESSION数据:';
echo "
";
print_r($_SESSION);
echo "
";die;
?>

测试：

1、表单中插入数据，并提交。然后不断刷新test2.php

<script type='text/javascript'> document.cookie='PHPSESSID=12345' </script>

2、接着分别查看sessionID以及count数值
　
　3、在其他浏览器中，执行相同的步骤1（保证sessionID与之前相同）和2，可以看到count初始值不是0，而是在之前的基础上增加的。
　 结论：盗取sessionID成功！

（二）使用HTML的标签加Set-Cookie属性。服务器可以靠在返回的HTML文档中增加标签来设置Cookie。例如，与客户端脚本相比，对标签的处理目前还不能被浏览器禁止。【只要让此行代码在服务器中执行即可入侵】
测试：
　　只要让此行代码执行即可，（）即可。我们将它放入表单中然后提交给PHP；接着不断刷新，再换浏览器执行相同步骤。和上面的测试一样！接着查看结果

（三）使用Set-Cookie的HTTP响应头部设置Cookie。攻击者可以使用一些方法在Web服务器的响应中加入Set-Cookie的HTTP响应头部。如会话收养，闯入目标服务器所在域的任一主机，或者是攻击用户的DNS服务器。
测试：(伪造浏览器执行http请求)

1、攻击者控制的服务器（127.0.0.1）
　　2、www.127.0.0.1/test1.php
　　客户访问这个页面，无形之中就简介访问第三方网站，并绑定一个sessionID；攻击者就可以掌握这个sessionID进行相应的攻击了

<?php
header("content-type:text/html;charset=utf8");
$host='www.linuxtest.com';
$port=80;
$a=fsockopen($host,$port);

//请求行
$request_data="Get /test2.php HTTP/1.1\r\n";
//请求头
$request_data.="Host: 127.0.0.1\r\n";
$request_data.="User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:10.0) Gecko/20100101 Firefox/10.0\r\n";
$request_data.="Connection: keep-alive\r\n";
$request_data.="Cookie: PHPSESSID=12345\r\n";   #设置sessionID
$request_data.="\r\n"; //空行表示头结束
//发送数据
fwrite($a,$request_data);

#用于测试
//接收数据
$inheader=1;
while(!feof($a))
{
    //echo fgets($a,1024);
    //除去请求头，只显示返回数据
    $data=fgets($a,1024);
    if($inheader && ($data=="\n" || $data=="\r\n"))
    {
        $inheader=0;
    }
    if($inheader==0)
    {
        echo $data;
    }
}
//关闭请求
fclose($a);

?>

防御方法：
1、每当用户登陆的时候就进行重置sessionID

2、sessionID闲置过久时，进行重置sessionID

3、 大部分防止会话劫持的方法对会话固定攻击同样有效。如设置HttpOnly，关闭透明化Session ID，User-Agent验证，Token校验等。

对文对比认证

一.密文比对认证介绍
在系统登录时密码加密正确流程是先将用户名和密码发送到服务器，服务器会把用户提交的密码经过Hash算法加密及加盐后和数据库中存储的加密值比对，如果加密值相同，则判定用户提交密码正确。

有些网站系统的密码加密流程是在前台浏览器客户端先对密码进行Hash加密后传输给服务器并与数据库加密值进行对比，如果加密值相同，则判定用户提交密码正确。以此流程会泄露密码加密方式，导致出现安全隐患。

加盐加密是一种对系统登录口令的加密方式，它实现的方式是将每一个口令同一个叫做“盐”的n位随机数相关联。无论何时只要口令改变，随机数就改变。随机数以未加密的方式存放在口令文件中，这样每个人都可以读。不再只保存加密过的口令，而是先将口令和随机数连接起来然后一同加密，加密后的结果放在口令文件中。

二.密文对比认证流程

三.防御方案
1.将密码加密过程及密文对比过程放置在服务器后台执行。
2.对系统用户登录模块增加有效的验证码机制。
3.对密码加密数据进行加盐处理存储。

HTTP/HTTPS 传输

登录认证模块之本地加密传输
HTTP传输过程中的密码有可能是加密的，而HTTPS的密码是加密后的密文。

后台登录帐号密码爆破测试

靶场：
1.登录点暴力破解

2、点击登录抓包，查看参数密码加密了

3、32位字符，有可能是md5加密，验证确实是md5加密

4、采用burpsuite爆破，选取字典后，采取md5加密

5、开始爆破

6、拿到password md5解密

7、成功登录

Cookie 脆弱点验证修改测试(代码审计)

1、查看admin/index.php，进行代码审计，发现如果r的值为空的话，会跳转到files/index.php文件中

2、查看files/index.php文件，发现包含了一个checklogin.php文件

3、查看checklogin.php文件

<?php
$user=$_COOKIE['user'];
if ($user==""){
header("Location: ?r=login");
exit;	
}
?>

发现只要cookie中user的值不为空即可登录管理员界面

4、抓包http://127.0.0.1/xscj/cookieCMS_V1.0/admin/index.php添加cookie中的user值

5、登陆成功