这是一个创建于 560 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
jaydenhpj 2023-05-04 21:47:24 +08:00
如果对异步回调的参数验证了签名，就不需要了。
|
 |
2
moult 2023-05-04 21:50:49 +08:00
异步回调里面还有一个 notifyId 参数的，建议验签之后，再验证一下 notifyId 即可。
|
 |
3
LLaMA OP 补充：一个外包的商城系统有 30 多笔款项对不上，检查日志后发现同步通知接口被多次伪造 method=alipay.trade.wap.pay.return 的请求，研究了 3 天也没找到这是怎么做到的，只能加主动查单了，异步接口在研究有没有必要加
|
|
4
LLaMA OP @benrezzagmehamed #3 伪造的同步通知请求验签可通过，查不到任何资料这怎么伪造
|
 |
6
jenlors 2023-05-04 22:05:53 +08:00
@benrezzagmehamed 密钥泄露了？
|
 |
7
bootvue 2023-05-04 22:31:30 +08:00
有内鬼 停止交易
|
 |
8
awolf 2023-05-04 22:31:45 +08:00
签名也能伪造？确认支付单号都是不一样的？（或者说是全新生成的？）
|
 |
9
dem0ns 2023-05-04 22:33:22 +08:00
肯定要验证啊，回调只是通知，没收到通知也得定时主动验证
|
 |
10
optional 2023-05-04 22:35:47 +08:00 via iPhone
异步通知已经是异步请求了，增加一个验证又不会影响你的体验，加。
|
 |
11
silypie 2023-05-04 22:59:06 +08:00
一般两个都要实现
|
 |
12
kcnine 2023-05-04 23:16:50 +08:00
多半是代码和密钥都被泄漏了，做做安全检查吧，不然不可能通过签名的
|
 |
13
lower 2023-05-04 23:17:30 +08:00
我之前接手过一个系统，支付回调里连支付状态是不是 success 都没判断，直接就拿 id 更新订单状态了，😂幸亏财务一直在一笔笔的核对
|
 |
14
sujin190 2023-05-04 23:25:53 +08:00 via Android
@benrezzagmehamed 密钥泄露了这不随便就能弄了
|
|
15
LLaMA OP |
 |
16
bestie 2023-05-05 01:04:02 +08:00
既然私钥不可能泄漏，那只能是同步通知的处理有问题。如果暂时查不出来就同时接入下异步通知吧，保证业务稳定再慢慢排查代码哪里有漏洞。
|
 |
17
Crawping 2023-05-05 01:24:23 +08:00
你确认了订单号么? 签名怎么伪造
|
 |
19
haha512 2023-05-05 01:31:37 +08:00
伪造有难度，不代表不能伪造
比如 订单 return_url=http://xxx.com/notify&out_trade_no=12345&seller=alice&total_fee=100&sign=XXX, 攻击者可以通过修改 return_url 到掌控的地址，如 http://bbb.com/,提交请求: return_url=http://bbb.com/notify&out_trade_no=12345&seller=alice&total_fee=100&sign=XXX 来获得 return_url 的结构。再伪造以下消息签名后发送给商户，伪造通知 target_url: http://xxx.com/notify post_data: put_trade_no=12345&seller=alice&total_fee=100&trade_status=SUCCESS&sign=XXX. 商户收到消息后验证签名正确，所有参数均正确，将完成攻击者的订单。而事实上并未进行过任何支付。 |
|
20
haha512 2023-05-05 01:36:41 +08:00
在异步通知里更新订单状态，不要在同步通知里更改
|
|
21
LLaMA OP @haha512 改 return_url 需要商户私钥签名，假设商户私钥泄露了，如果攻击者不支.付，支.付宝也不会给攻击者签名 return 的数据，如果攻击者换成自己的收款账号那 appid sellerid 之类验证都过不了了
|
|
22
jenlors 2023-05-05 08:12:40 +08:00 via iPhone
感觉是不是代码里面验签逻辑的问题，建议好好看看代码。另外不要完全依赖同步接口，因为用户可能支付完成直接关掉界面不进行跳转。
|
 |
23
wqhui 2023-05-05 09:21:33 +08:00
是不是代码逻辑有 bug ，支付宝印象中是 rsa 的签名，私钥只在支付宝平台那边，其他人改参数后没有重新生成签名，签名就对不上了
|
 |
24
Felldeadbird 2023-05-05 09:45:03 +08:00
日订单数量不多，财务又勤快校验的话可以信任异步回调。
反之将回调的信息发给支付宝确认订单状态是为了避免回调被人恶意发起，实现伪造支付请求。 |
|
25
haha512 2023-05-05 09:46:27 +08:00
return_url 并不参与签名。
异步通知的 url 需要在支付宝控制台填写，会验证。所以异步里更新订单是比较安全的。 |
 |
26
skyrem 2023-05-05 10:17:26 +08:00
支付宝有很多支付产品，当面付 和 手机网站支付 接入上都差不多，回调体也差不多，我记得 手机网站支付 如果用户取消也会有回调，只是状态码不一样
|
 |
27
changepll 2023-05-05 10:41:52 +08:00
在异步中，查一下订单状态是必要的。 这样伪造都没办法伪造。
不用查的前提是代码，密钥之类的没有出现泄密 |
 |
28
azui999 2023-05-05 10:43:23 +08:00
支付宝
|
 |
30
justfindu 2023-05-05 11:08:58 +08:00
确认就是你们系统出现了 bug. 不要怀疑自己. 我之前也看到群里有个人说这个问题. 就是被绕过去了
|
 |
31
lopssh 2023-05-05 11:11:19 +08:00 via Android
肯定要验证啊，回调只是通知，没收到通知也得定时主动验证。
异步通知已经是异步请求了，增加一个验证又不会影响你的体验，加。 一般两个都要实现。 我之前接手过一个系统，支付回调里连支付状态是不是 success 都没判断，直接就拿 id 更新订单状态了，😂幸亏财务一直在一笔笔的核对。 |
|
33
lopssh 2023-05-05 11:12:02 +08:00 via Android
return_url 并不参与签名。
异步通知的 url 需要在支付宝控制台填写，会验证。所以异步里更新订单是比较安全的。 支付宝有很多支付产品，当面付 和 手机网站支付 接入上都差不多，回调体也差不多，我记得 手机网站支付 如果用户取消也会有回调，只是状态码不一样。 在异步中，查一下订单状态是必要的。 这样伪造都没办法伪造。 不用查的前提是代码，密钥之类的没有出现泄密。 |
 |
35
Anivial 2023-05-05 11:20:28 +08:00
“伪造的同步通知请求验签可通过”，问题不是很明显了吗？
1. 支付宝私钥泄露 2. 你的验签代码有问题 那你觉得哪个可能大呢？如果你都换成同步，那订单数量多了之后怎么办，而且你代码上的漏洞还是没解决 |
 |
36
vZexc0m 2023-05-05 11:27:28 +08:00
异步通知验签过了基本没有问题。排查下自己代码问题。支付宝异步通知时未收到正常 response 会重复发起异步通知。
楼上说更改 URL 的不成立，因为所有参数都要参与签名。 |
 |
37
brader 2023-05-05 11:32:36 +08:00
楼主，不管是你代码问题，还是支付宝或你们导致的资料泄露，反正都是有人盯上你们了，其他措施你该怎么补救怎么补救，我给你一个额外的建议：
你尽快更换回调地址的 url 吧，不然一直有人知道你回调 url ，骚扰你，也挺烦的。你可以换成如： https://xxx.com/callback/bdxZYgAHF1V2yCMD 这样的地址，后面加了一串随机字符串，注意：这个策略不保证你的接口安全，仅是让攻击者不那么容易找到你的回调 url ，避免大部分麻烦。 |
|
38
LLaMA OP |
|
39
Anivial 2023-05-05 14:12:53 +08:00
@LLaMA #38 官方验证只是能证明参数加密没有错误，你有完整对比订单号，appid 这些信息吗？
官方的文档： 商家需要验证该通知数据中的 out_trade_no 是否为商家系统中创建的订单号。 判断 total_amount 是否确实为该订单的实际金额（即商户订单创建时的金额）。 校验通知中的 seller_id （或者 seller_email) 是否为 out_trade_no 这笔单据的对应的操作方（有的时候，一个商家可能有多个 seller_id/seller_email ）。 验证 app_id 是否为该商家本身。 如果这些信息都能被伪造，我只能说你的网站真的很有价值，能被呢么大手笔来攻击 |
 |
40
ytmsdy 2023-05-05 14:36:29 +08:00
|
 |
41
buffzty 2023-05-05 14:39:52 +08:00  2
不用怀疑支付宝私钥泄露.
应该是对方真的支付了,但是你们漏了 导致对账错误 别再错误的路上瞎走 |
 |
42
bjzhush 2023-05-05 16:00:18 +08:00 1
泄露个毛线啊，先理清流程吧
正常流程来说，发起支付用户只能看到 return url ，就是用户支付完了跳到的提示页面 至于支付成功之后，支付宝回调商家，那个回调通知的 URL ，只要你自己不泄露，从某些角度来说除了支付宝别人不可能知道的 都看到了所谓的被伪造的请求了，就没去查查发这些请求的 IP 到底是不是支付宝的？没去看看是不是处理回调失败导致支付宝重试的？没去检查下自己代码是不是有问题？ |
 |
43
simonlu9 2023-05-05 17:34:06 +08:00
肯定要再次去支付宝获取一下订单是否真的充值成功，回调签名是支付宝私钥加密的，别人可以用支付宝公钥解密，但绝不能伪造。再次检查下代码吧
|
|
44
simonlu9 2023-05-05 17:36:46 +08:00
最好在数据库在加一个支付凭证的唯一索引，不然会导致重复充值问题，客户端支付成功->服务端确认；支付宝回调-》服务端确认订单；我之前遇到这两个同时并发，结果多充了两笔
|
 |
45
Kinnice 2023-05-05 17:45:41 +08:00
一般的实现基本是只依赖异步回调的接口结果，同步接口只是做个跳转，你这正好反过来。
|
 |
46
WindProtect 2023-05-06 10:11:25 +08:00
你收的的是重复的回调么？有没可能是因为支付宝的通知回调然后你们这边没有应答然后他们重试了？
|
Select Language