业务逻辑,是只用代码实现的真实业务的规则映射
业务逻辑漏洞,开发者只考虑了常规的操作流程,即“当在A情况下,就会出现B,此时执行C即可”,但是却没有考虑当用户执行了意料之外的X时会发生什么,使用工具无法完全替代人工测试和发现逻辑漏洞
业务逻辑的发现,简单而复杂
简单的是只用burp稍微修改几个数据就行,复杂的是需要熟悉业务流程,绕过真实用户身份或正常业务流程达到预期的目的
1、选择购物平台
2、注册账户(开通会员、修改密码)
3、搜索商品
4、购买商品
5、确认收货
6、给卖家评分
修改密码
要知道原密码才能修改新密码,或者说忘记密码,也得有对应的验证手机号,收取验证码
非授权访问是指用户在没有通过认证授权的情况下能够直接访问需要通过认证才能访问到的页面或文本信息
可以通过换浏览器测试未授权(清除cookie)
越权漏洞的成因主要是因为开发人员在对数据进行增、删、改、查询时对客户端请求的数据过分相信而遗漏了权限的判定
挖掘思路
可以通过修改用户id、用户编号、遍历编号操作测试越权访问
水平越权:如果在访问网站数据包中有传输用户的编号、用户组编号或类型综号的时候,那么尝试对这个值进行修改,就是测试越权漏洞的基本。
垂直越权:添加高权限用户
访问注册页面,注册账户之后充值提交并抓取数据包,填写任意金额然后并抓包,获取订单
号,利用订单号构造充值链接并访问,看是否能充值成功
一个充值的功能,在拦截包的过程中发现充值成功后会有一个充值成功的连接,例
如是 xxx.com/index.php?controller=site&action=payok&out_trade_no=aaaa,其中
aaa 是充值订单号。接下来注册一个新账号进行充值,在支付产生订单时复制其订单号然后取消支付,把订单号贴到充值成功后的连接中充值成功,则存在乱序问题。
重放攻击(恶意注册\短信炸弹\无限刷积分/投票)
在短信、邮件调用业务或生成业务数据环节中(例:短信验证码,邮件验证码,订单生成,评论提交,签到,投票等),对其业务环节进行调用(重放)测试。如果业务经过调用(重放)后被多次生成有效的业务或数据结果。
在测试的过程中,我们发现众多的系统仅在前端通过JS校验时间来控制短信发送按钮,但后台并未对发送做任何限制,导致可通过重放包的方式大量发送恶意短信。
比如每天签到送5个积分,如果签到接口未做限制,无限重放签到接口,就能实现无限刷积分。
投票接口未做限制,或仅仅在前端JS做限制,可无限重放投票接口,给指定用户刷票。
不过目前大部分投票系统都有做限制,比如同一个IP每天只能投三次票,可尝试用X-
Forwarded-For:127.0.0.1来绕过IP限制。
针对某些带有时间限制的业务,修改其时间限制范围,例如在某项时间限制范围内
查询的业务,修改含有时间明文字段的请求并提交,查看能否绕过时间限制完成业
务流程。例如通过更改查询手机网厅的受理记录的month范围,可以突破默认只能
查询六个月的记录。
抓包修改手机号码参数为其他号码尝试,例如在办理查询页面,输入自己的号码然后抓包,修改手机号码参数为其他人号码,查看是否能查询其他人的业务。
抓包修改用户邮箱参数为其他用户的邮箱。
查看自己的订单id,然后修改id(加减一)查看是否能查看其它订单信息。
如积分兑换处,
100个积分只能换商品编号为001,1000个积分只能换商品编号005,
在100积分换商品的时候抓包把换商品的编号修改为005,用低积分换区高积分商品。
抓包修改金额等字段,例如在支付页面抓取请求中商品的金额字段,
修改成任意数额的金额并提交,查看能否以修改后的金额数据完成业务流程。
经常见到的参数大多为rmb、value、amount、cash、fee、money等
关于支付的逻辑漏洞这一块还有很多种思路:
比如:
相同价格增加订单数量,相同订单数量减少产品价格,订单价格设定为负数等等。
抓包修改商品数量等字段,将请求中的商品数量修改成任意数额,如负数并提交,
查看能否以修改后的数量完成业务流程。
很多商品限制用户购买数量时,服务器仅在页面通过js脚本限制,未在服务器端校验用户提交的数量,通过抓包修改商品最大数限制,将请求中的商品数量改为大于最大数限制的值,
查看能否以修改后的数量完成业务流程。
二、