支付漏洞及cookie脆弱性
支付漏洞
简介
- 支付漏洞在漏洞中一直是处于高风险漏洞，对于企业来说相应的危害是很大的，同样对于用户的风险也很大的，比如当攻击者通过修改，使用他人账号的余额进行购买，那么就属于支付中的越权漏洞了。
- 购买流程：选择商品和数量——产生订单——选择邮寄地址及支付方式——订单支付——完成支付。
- 支付漏洞就是针对以上流程进行越权操作
支付漏洞分类
修改支付价格
- 对于修改支付价格，通常来说购买一件物品需要选中自己所需购买的物品，其次确认相关的信息，最后支付价钱，而在这个过程中，可以在选中时就修改价格，若有相关的验证，则可以向后边退，一步一步测试。
修改支付状态
- 其实这里的支付状态挺好理解的，把支付未成功修改为支付成功即可，这个也是由于支付的状态未和实际订单的支付状态进行校验而产生的。
修改购买数量
- 在支付的过程中，数量也同时决定着价格，比如：1个数量商品对应的是100，2个数据就是200，那么当你修改这个值数量值为负数时，那么其金额也会变为负数，最后就会导致支付问题的产生。
替换支付
- 替换支付简单来说，首先去产生两个订单，但是这两个订单的商品是不一样的，其价格也是不一样的，如果服务端未做好相应的验证，那么在支付过程中去替换数据，最后支付，这时候就可以使用订单支付的价格购买到其他贵的物品。
越权支付
- 在支付当中会出现当前用户的ID，比如：username=XXXXX，如果没有加以验证，其支付也是一次性支付没有要求输入密码什么的机制，那么就可以修改这个用户ID为其它用户ID，达到用其他用户的账号进行支付你的商品。
修改优化价
- 比如一些商品有优惠价，优惠多少多少，那么在支付时抓包，修改这个优惠价就可造成支付问题的产生。
常用篡改参数
- 商品的ID编号、购买价格、购买数量、支付方式、订单号、支付状态等。
实例
- 这里用大米cms进行实验
- 注册一个用户test
- 随便选一个商品购买然后抓包
- 修改价格
- 可以看见价格已经被修改了
- 还可以修改其他信息，包括商品id等等
防御
- 对商品的价格进行判断，不能为负数。
- 商品的价格以数据库的为准，不能以页面为准。
- 设置类似的token值来对数据包进行唯一性处理
cookie脆弱性
简介
- 用户在客户端 (一般为浏览器) 中访问某个页面 ，也就是向服务器发送请求。
- 服务器收到请求后，会在响应头中设置Set-Cookie字段值，该字段存储相关信息和状态。
- 客户端解析服务器HTTP响应头中的Set-Cookie字段，并以key=value的形式保存在本地，之后客户端每次发送HTTP请求时，都会在请求头中增加Cookie字段。
- 服务器接收到客户端的HTTP请求之后，会从请求头中取出Cookie数据，来校验客户端状态或身份信息。
实例
- 这里使用熊海靶场进行实验
- 这个越权登录，其实是基于代码审计获取得，也就相当于是白盒测试，若黑盒测试，基本上应该是测试不出来的。
- 代码审计：
1
2
3
4
5
6
7
$user=$_COOKIE['user'];
if ($user==""){
header("Location: ?r=login");
exit;
} - 通过代码知道，cookie当中会有user信息，如果为空则进入登录页面，否则进行登录
- 直接在url后加admin会进入登录界面
- 因为我们没登陆过
- 这里我们清理一下cookie信息，并进行抓包
- 抓包信息当中，没有cookie
- 我们手动加入cookie信息
- 设定user为1，即不为空
- 放包，可以看见成功进入admin，最高权限用户
越过条件
- 其实在这里可以看到我们直接输入了cookie: user=1，那么我们该如何知道这个cookie值需要使用到user呢？所以相对来说挺鸡肋的，在实战中若没有源码基本上不可能绕过，所以这多数适合在白盒测试中，如果一定要使用黑盒测试，那么就需要在网上找相应的源码进行分析，但若别人修改了，那么基本上就是凉凉的节奏，不可能被绕过的。
防御
- 根据交互所需的传输范围，设置适当的Cookie有效时间
- 对cookie加密以及数字签名，并在安全信道中传输
- 用URL参数代替cookie中可能包含的敏感信息
- 不要在cookie中设置中文
- 合理设置Cookies中的安全属性
- 服务器不应该在同一个主机上同时运行相互不信任的服务
客户端回显、response状态值、验证码爆破、找回流程绕过等。
评论