一、业务逻辑漏洞挖掘关键点
验证码突破
业务授权安全
业务流程乱序
业务接口调用
时效绕过测试
身份认证安全
业务一致性安全
业务数据篡改
用户输入合规性
密码找回漏洞
二、四大核心分类
1.业务授权安全
(1)未授权访问:用户在没有通过认证授权的情况下能够直接访问需要通过认证才能访问到的页面或文本信息。
(2)越权访问:
- 水平越权:同权限用户互查数据(订单 / 身份证)
- 垂直越权:普通用户越权管理员用户

越权漏洞的成因主要是因为开发人员在对数据进行增、删、改、查询时对客户端请求的数据过分相信而遗漏了权限的判定。
所以挖掘越权漏洞思路:
- 水平越权:如果在访问网站数据包中有传输用户的编号、用户组编号或类型综号的时候,那么尝试对这个值进行修改,就是测试越权漏洞的基本。(抓包修改
userid/orderid/phone遍历。) - 垂直越权:添加用户
如何检测越权漏洞?
最简单的一种检测方式是,首先是通过定位鉴权参数,然后替换为其他账户鉴权参数的方法来发现越权漏洞。
(3)业务流程乱序
(1 顺序执行缺陷导致的支付漏洞:
- 0 元购 / 低价购买:先改价格/数量/快递运费等 → 再下单; 先下单 → 再改状态为已支付
(2 绕过旧密码和短信验证码修改付款密码:
正常流程:
- 入修改支付密码页
- 输入旧支付密码验证身份
- 获取并输入短信验证码
- 设置新支付密码
- 提交修改成功
注意修改付款密码需要两个条件:
- 需要输入旧付款密码
可以抓修改支付密码的请求,直接删参数/传空/任意参数,只要后端不校验真实旧密码,直接成功。
- 需要验证短信验证码
抓短信验证最终的提交包,修改短信验证码或者用旧验证码,不请求发送验证码(“获取验证码”),直接提交。
还可以在提交时把手机号改成他人号码,但验证码填自己的,如果后端只校验验证码是否匹配当前会话,不校验手机号归属,可改他人支付密码。
2.业务接口调用
(1)重放攻击
- 恶意注册
- 短信轰炸
- 无限刷积分
- 投票活动刷票
目前大部分投票系统都有做限制,比如同一个IP每天只能投三次票,可尝试用X-Forwarded-For:127.0.0.1来绕过IP限制。
(2)内容编辑
在 App/网站里,用户发布文章、评论、个人资料、商品信息后,会有一个编辑接口,抓包拿到编辑请求包。通过分析数据包,把参数由客户端控制的修改为攻击者想要发送的内容。
(3)实效绕过(时间范围)
针对某些带有时间限制的业务,修改其时间限制范围,例如在某项时间限制范围内查询的业务,修改含有时间明文字段的请求并提交,查看能否绕过时间限制完成业务流程。
- 直接篡改时间参数:直接修改请求中的明文时间字段,比如将限制近 6 个月的查询请求里的
month改为更早的月份,或把start_time设为业务允许范围之前的日期、end_time设为未来日期,尝试获取超出限制的数据。 - 时间格式变形绕过:通过改变时间的表示形式绕过校验,比如将标准日期转换为时间戳、把横杠分隔的日期改为斜杠格式、使用简写日期,利用后端仅校验特定格式的漏洞。
- 参数名变形 / 别名测试:更换时间参数的名称,比如将
month改为startMonth、start_time改为beginTime,尝试绕过后端仅针对特定参数名的校验逻辑。 - 并发 / 批量请求绕过:通过同时发送多个不同时间范围的请求,或在批量查询接口中传入多个超出限制的时间点,利用校验逻辑的不足绕过限制
3.业务一致性安全
- 手机号篡改
抓包修改手机号码参数为其他号码尝试, 例如在办理查询页面,输入自己的号码然后抓包, 修改手机号码参数为其他人号码,查看是否能查询其他人的业务。
- 邮箱地址篡改
抓包修改用户邮箱参数为其他用户的邮箱。
- 订单id篡改
查看自己的订单id,然后修改id(加减一)查看是否能查看其它订单信息。
- 商品编号篡改
例如积分兑换处, 100个积分只能换商品编号为001,1000个积分只能换商品编号005, 在100积分换商品的时候抓包把换商品的编号修改为005,用低积分换区高积分商品。
- 用户id篡改
抓包查看自己的用户id,然后修改id(加减1)查看是否能查看其它用户id信息。
通过篡改用户的这些信息,实现越权操作,查看其他用户的信息。
4.业务数据篡改
(1)金额数据篡改
抓包修改金额等字段,例如在支付页面抓取请求中商品的金额字段(订单价格设定为0/负数/浮点数等),修改成任意数额的金额并提交,查看能否以修改后的金额数据完成业务流程。
(2)商品数据篡改
抓包修改商品数量等字段,将请求中的商品数量修改成任意数额,如负数并提交,查看能否以修改后的数量完成业务流程。
(3)最大数限制突破
很多商品限制用户购买数量时,服务器仅在页面通过js脚本限制,没有在服务器端校验用户提交的数量,通过抓包修改商品最大数限制,将请求中的商品数量改为大于最大数限制的值,查看能否以修改后的数量完成业务流程。
186

被折叠的 条评论
为什么被折叠?



