全球工单 分享一个新的骗钱手段：利用“闲鱼-支付宝”的某些规则

[ivanor]

具体的原理，知乎上这篇文章应该说的比较清楚
https://zhuanlan.zhihu.com/p/625230704

闲鱼新骗局，大家闲鱼捡漏一定注意，不要被骗了，必看，必看，必看完，说三遍。

1.卖家挂的商品属于真香价格，吸引你购买，并且要求到付

2.你拍下之后和你正常友好沟通，你觉得卖家是个好老哥

3.你的好老哥发来一个二维码，告知需要扫码获得免费的价保，或者是告诉你扫码支付运费新人可能是零元

4.你扫码之后发现是闲鱼链接到支付宝的页面，看起来很正规，于是放松警惕点击立即支付。

5.你支付之后，你会发现你刚拍下的商品已确认收货，吃了个大亏，叫天不应叫地不灵，回群里被大家当成笑柄。


总结：闲鱼卖家发一个让你支付运费或者保价的码，大家都别扫，扫了就直接确认收货被骗，大家眼睛擦亮一点。

https://bbs.nga.cn/read.php?&tid=36187186

[abelyao]

第三步就不对劲了，二维码 = 链接，怎么可能随便就扫

[killva4624]

这个算 APP 的锅吧，封闭但安全措施又没完全做好。
如果显示 URL 的话，看到奇怪的域名就不会往下点了...

[8355]

现在移动互联网了 cookie 都不用偷 他们自己就操作了。。。。

[qsnow6]

这也行🙀

[sillydaddy]

原理没看懂：
「也就是说，如果你在闲鱼下单之后，再使用你的支付宝账号向这笔订单付款，就会将这笔订单的状态自动变成确认收货状态，从而骗子可以收到款项」

我来理理这是什么逻辑。比如一笔订单 10000 元，我是买家，卖家有一个支付宝交易号(可能只在这笔订单中有效)用来收钱。如果我向这个支付宝交易号付款哪怕只有 1 元，订单就算是确认收货了。然后 10000 元就打给卖家了。是这个逻辑吗？可怕啊。

[tomczhen]

我觉得更像 xss ，不过因为移动端扫码，之前浏览器上那些防御措施缺失了。

要说这个支付宝也有锅，毕竟界面和操作意图不一致，也能正常过。

[coolcoffee]

省流：

1. 先用支付宝 schema 打开第三方的网址：alipays://platformapi/startapp?appId=20000067&url=http://kgnb763n.blogqt.gq/index.php

2. 在 http://kgnb763n.blogqt.gq/index.php 的网页里面通过伪装的 0 元确认按钮事件触发: AlipayJSBridge.call("tradePay", { tradeNO: "2023042622001174211404250439" }, function(result) {});

其中 tradeNO 对应的就是闲鱼的订单号，所以就会出现扫个码就把订单给确认了的情况。


节选自： https://zhuanlan.zhihu.com/p/625230704

[coolcoffee]

简要分析一下就是 alipays://绕开了闲鱼的外链警告，其次支付宝打开第三方的网址也不像微信一样有非常严格的限制，最后就是调用 AlipayJSBridge.call("tradePay")这类核心接口之前居然不用鉴权之类的。

我以前还挺烦微信支付的各种域名、路径以及签名之类的校验的，现在看来这个还是有必要的。

[functioncloud]

@sillydaddy #5 没有向交易号支付 1 元这种情况。扫码的打开的支付页，就是需要填写支付密码的确认收货的支付页，骗子获取确认收货的交易号就可以构造这样的链接骗你确认

[SachinBeyond]

楼主建议你们（被骗的人联合起来建群） 大家都 换个 咸鱼账号 再次 让自己被骗个万把块钱，争取吧对方 送进局子好好蹲几年

[sillydaddy]

@coolcoffee #7
关键在于，为什么 AlipayJSBridge.call 可以将订单设置为已收货状态？这才是关键的漏洞。

[cyansto]

捋一下；
1 、打开支付宝 app ，调用支付宝的浏览器打开支付页面
2 、中间的支付页面是有问题的，做出一个闲鱼跳到支付宝的页面 http://kgnb763n.blogqt.gq/index.php
3 、当你点击支付的时候，支付的订单号是咸鱼的支付交易号，不是随机生成的订单号，
你以为是支付，其实是确认收货的验证支付

[sillydaddy]

@functioncloud #9
可以看介绍骗局的里面提到的：「这个二维码通过闲鱼扫描之后会跳转到支付宝，支付宝支付一元之后，闲鱼突然自动收货了，此时骗子收到钱了之后把我拉黑了。」
确实只支付了一元啊。

[sillydaddy]

@functioncloud
如果是对闲鱼订单的支付，那么支付宝的支付页，显示的就是实际金额吧。

[cyansto]

@sillydaddy
以为支付了一元，查看账单应该是没有交易记录的

[paradoxs]

给大家省流：

1 、 遇到陌生的二维码， 不应该去扫。

2 、 虽然他扫这个码 这个操作值得批评。 但即便如此， 扫码之后 不应该变成“确认收货” 这个结果。



总结 ： 这是闲鱼和支付宝的漏洞， 个人认为，算是 BUG 吧。

[mxT52CRuqR6o5]

这属于是 P0 级的漏洞了

[coolcoffee]

@sillydaddy 是的。出现第三方网址都能匿名调用订单核心操作，这个锅得让支付宝来背。

像微信是在支付订单的时候是会校验 H5 的域名和路径的，任意一项不符合都没法继续。

[joesonw]

@SachinBeyond 干这个的你觉得他会用自己的身份信息？

[SachinBeyond]

@joesonw 有流水还能跑得了？

[x86]

只能说黑产太用心啦。。。

[joesonw]

@SachinBeyond 一般都是收的全套，身份证+银行卡。

[retanoj]

支付宝 APP 漏洞啊

[vsitebon]

这个 BUG 很恶性啊

[ouqihang]

这个漏洞听说有段时间了，现在还没修好。

[systemcall]

杰克马的东西有这些毛病不奇怪，毕竟技术力宇宙第一
你可以见到自家的许多程序里面的页面，因为触发了自家的一些安全规则，导致无法正常使用，你也可以见到各种提权和权限滥用，你还可以见到见缝插针地弹广告的同时关键消息都能漏

[Lentin]

@ouqihang 恐怕是有人故意不去修🐶

[coolair]

所以，在设计时是不是应该把买家订单号和卖家订单号分开来生成，生成两个不一样的订单号，或者一个订单号使用不同的加密规则给买家和卖家分别加密，然后显示不一样。

[likunyan]

hook 0 级别的漏洞了。

[sillydaddy]

@coolcoffee #18 >“。。匿名调用订单核心操作，这个锅得让支付宝来背。。”
@cyansto

你们能相信支付宝有「确认订单完成」的接口或功能吗？支付页面肯定要显示支付金额的，我没有见过只输入支付密码的而没有交易金额显示的，想想也不符合实际场景啊。所以，我觉得应该不是支付宝的问题。而是闲鱼的 bug 。

“确认收货”这个肯定不是支付宝能够做出的动作。这一点成立的话，那么无论支付宝作出什么动作，闲鱼都不应该确认交易完成，并给卖家放款，因为确认交易完成只能买家在闲鱼 App 里面才能触发。

[Wishprophet]

支付宝追回难度有多大

[yokisama]

@Wishprophet 难度很大，进了支付宝然后就转出国了，骗子支付宝大都是买的

[est]

大厂的 qa 和攻防团队应该外包给黑产。

[k0140146498]

两个月前就在🐔安看到了，居然还没修复

[Rache1]

一两个月以前就看到这个问题了，然后这两天还看到有人因为这个中招，某些大厂还是有些水平。

阿里家还有去年三无公社还爆出来一个天猫的利用自定义优惠券虚假详情页可以直接下单欺骗消费者的问题，而天猫那边却也还没解决。

我其他的视频你可以不看，但这视频你得把他看完_哔哩哔哩_bilibili
https://www.bilibili.com/video/BV1514y1w74b/

120 万人看过的电商平台漏洞，貌似堵不上了...._哔哩哔哩_bilibili
https://www.bilibili.com/video/BV1oV4y1D7ng/

[dcsite]

这就是我一直不用阿里系的原因……

/t/333527

2017 年我发现支付宝只需知道银行卡和手机号，即可改密码并登录，就彻底对这家公司失去信任了

[fydpfg]

@abelyao @killva4624 @8355 @paradoxs 稍微了解一些 web 安全的人都知道，在现代浏览器的安全模型下，用户就是可以随便打开不信任的链接的，这并不是用户的问题。如果打开不信任的链接就可以对其他网站产生不好的副作用，那么要么是浏览器的 0day ，要么是其他网站的 0day 。

「不要点击陌生链接、不要打开陌生短信 /邮件」是一种一刀切的说法，基于的假设是很多用户完全没有鉴别 URL 中域名的能力，或者这些用户会被钓鱼从而自己主动输入其他网站的密码 /密钥、直接运行下载的可执行文件等等。

对于了解一些计算机安全知识的人来说，点开不信任的链接 /扫描不信任的二维码本身并不是一件应该批评的事情。

即使二维码指向的域名是可信的，打开之后也完全可能直接自动跳转到不可信的域名。web 的安全性从设计上就不是由用户自己确保别打开不信任的网站来保证的。

另外，各种安全措施如加密、签名校验也不是越多就越好、越少就越不安全。这完全取决于应用的安全模型，有经验的开发者会正确使用密码学来保证协议的安全性。

[xmumiffy]

@Rache1 这个厉害了

[mercury233]

@fydpfg 但支付宝不是浏览器，无论是用户还是阿里都没有把支付宝当成浏览器的意思

[feejson]

蹲一个后续，望有缘人踢我🙂

[8yte]

@fydpfg

页面再精细一点，估计换成搞安全的人也分不清。

付款金额只有 1 块，如果不是付完款会确认收货，换谁都以为是官方活动吧。

这比 csrf xss 还危险，他甚至用的是自己的域名。

从第三方伪造网站能调用 AlipayJSBridge.call 就知道完全是支付宝的锅。骗子根本不用获得你的凭证，支付宝直接帮骗子一把梭了。

[gujuji]

@8yte 他这个 api 应该就是方便 h5 调用收货，但是脑残没有鉴定域名白名单导致的

[gujuji]

@SachinBeyond 跑的了，随便买个假信息，然后换成 usdt 就结束了

[gujuji]

@SachinBeyond 不好弄的，这些人都是在强北买的假信息，钱一到账就换成 u 了，你就追不了了

[8yte]

@gujuji 所以我说骗子域名还能调用 API 就很离谱

[gujuji]

支付宝没想到会有这么明显的安全漏洞，简直无脑，感觉还可以细挖

[linauror]

看起来确实是支付宝的问题了

[ZField]

这应该属于支付宝的安全漏洞，支付宝全责……

[bjzhush]

@dcsite 微信支付更扯淡，支付宝好歹有客服，微信连个鬼都没有，方方面面支付宝比微信强多了，再说了，新设备不可能这么简单就改支付宝密码的

[sillydaddy]

@coolcoffee
@cyansto
我搜了下“支付宝确认收货”，还真有这个接口。。没有交易金额，只输入确认密码。

那现在问题比较清楚了，支付宝在收到确认收货的调用时，没有做域名校验，这应该是主责。但是，闲鱼的设计是不是有漏洞呢？按常理，「确认收货」这个动作，只有在买家的闲鱼 App 里面才可以操作，对吧，但由于卖家获取到了订单的 ID ，直接调用了支付宝的接口，实现了确认收货。

这里面闲鱼的处理逻辑是有漏洞的，因为订单的 ID 对于买家和卖家，应该都不可见才对，尤其是对于卖家。只有在买家点击「确认收货」时，才由闲鱼 App 从后台获取到这个订单 ID ，然后发起支付宝确认操作。这样，就类似于 @coolair 所说的「买家订单号和卖家订单号分开来生成」了，卖家是无法见到这个订单 ID 的，卖家应该也用不到这个订单 ID （即使是卖家取消订单？）。

我不知道支付宝的担保交易的逻辑，生成订单 ID 的逻辑是什么样的，生成的订单 ID 是不是只是对于闲鱼可见，还是对买家和卖家都可见。如 @coolair 那样的方案，在密码学上更严谨。像 @fydpfg 所说的，「正确使用密码学来保证协议的安全性」

[xmumiffy]

@sillydaddy 订单号不是密码,不应该期待使用订单号来保密.本质还是越权调用确认收货接口的问题

[sillydaddy]

@xmumiffy 订单号足够长的话，就是能起到密码的作用，也可以起到与密钥同等的效力。这点不用怀疑吧。如果可以做到的话，那么逻辑上是更完整的。再加上你说的鉴权行为，相当于是两道加密的效果。这两道加密没有什么主次之分。

[sillydaddy]

@xmumiffy 或者这么理解，订单号对于谁可见，本质上是业务上的必要性的问题。如果一个订单号可以只对闲鱼可见，那么就无需暴露给买家和卖家。对于任何一方，都只暴露给其所需的最小信息量。这样攻击面也会最小化。支付宝的买家和卖家直接交易中，双方都可以见到支付宝交易的订单 ID ，便于双方核对。

那么闲鱼作为中间方的担保交易也是这样吗？买家的钱首先是打给闲鱼的，而不是打给卖家，所以订单 ID 应该也分成买家和闲鱼、闲鱼和卖家这 2 份，至于它们后台共享同一个业务 ID ，那这个 ID 应该是只对闲鱼可见的。我不懂支付业务，但直觉上感觉是应该这样设计的。

[xmumiffy]

@sillydaddy 我的意思是,订单号不需要保密.你不会告诉卖家你的支付密码,但是你会告诉卖家你的订单号.

[xmumiffy]

@sillydaddy 至于用卖家的订单号来确认收货,还是买家的订单号来确认,还是业务内部订单号,这都不重要.重要的是本来就不应该能被第三方越权直接调起确认收货

[Rache1]

@sillydaddy 据说阿里的平台下的担保交易是支付宝承担的，大致流程应该就是 确认收货的时候实际上是调用的支付宝的接口，支付宝验证完密码后，再异步回调给闲鱼告诉闲鱼这个交易号下的订单已经确认收货。

这里的交易号不是闲鱼的订单号，而是支付宝平台的交易号，网站在调用支付宝创建订单时，需要把网站的订单编号传递过去，也就是你的每笔订单至少都有两个跟这个交易有关的编号，你打开你的支付宝账单，点开就都能看到的。

这里骗子网站就是使用的支付宝的交易号。交易号还可以用在退款，对账等等。


你说的理想情况就是，用户在闲鱼 App 里面点击确认收货按钮后，把订单设置一个状态，比如确认收货中，然后再调用支付宝的确认收货接口，当收到支付宝的确认收货异步回调后，如果判断到订单的状态不是在确认收货中（就是这个漏洞的情况），那就忽略这个异步回调，但是也可能会存在一些问题。

[codehz]

@sillydaddy 阿里系的确认收货都是支付宝做的，实际上担保服务就是支付宝提供的，第一方就是支付宝。而闲鱼，淘宝，1688 这些都是不提供担保交易服务，这么说反而闲鱼 app 内做确认才是“第三方确认收货”。。。

[xuelu520]

JSB 鉴权背锅，第三方页面居然可以直接调用

[sillydaddy]

@Rache1 #56
「 AlipayJSBridge.call("tradePay", { tradeNO: "2023042622001174211404250439" }, function(result) {});」
这个里面的 2023042622001174211404250439 ，应该就是你说的支付宝交易号吧。如果这个号是闲鱼在创建订单的时候生成的，那么这个号是否有必要暴露给买家和卖家呢？「买家在闲鱼 App 里面点击确认收货按钮」，这个时候闲鱼才应该从后台拿到 2023042622001174211404250439 这个交易号，发起确认收货，由用户在支付宝上输入密码确认。支付宝是确认的一方，但是发起的却是闲鱼。如果这个交易号暴露给了卖家，那么卖家也可以作为发起人了。这也就是不必要的信息暴露导致的风险。
所以一个关键的问题就是，这个交易号是不是必须暴露给卖家（比如卖家伪装取消订单拿到了这个交易号）。如果存在这种暴露的可能性，是不是可以进一步改进这种交易号的设计（应该由支付宝来做）。

[sillydaddy]

@codehz 但是确认收货的发起人肯定是闲鱼。从业务上来说，也只有闲鱼 app 上才有确认收货的入口才合理。闲鱼暴露给用户的，只有一个“确认收货”的按钮，用户经由这个按钮“代理”才可以触发收货，进而启动支付宝的支付密码确认。
主题提到的骗钱手段，能成功的原因，一是卖家伪装成闲鱼，向支付宝发起了确认收货的操作，二是确认收货所必须的信息(支付宝交易号)被暴露给了卖家。

[royzxq]

顶级大厂顶级设计

[C47CH]

问题是，支付宝会赔偿损失吗？🤔

[Rache1]

@sillydaddy

> 如果这个交易号暴露给了卖家，那么卖家也可以作为发起人了

这是不可能的，已经有人做过验证了，如果是其他人的交易号，在你点击的时候（ AlipayJSBridge.call 后）就会弹窗提示（当前支付宝登录的账号和这个交易号对应的账号）不是同一用户，无法继续进行，说明支付宝是有验证的。

> 如果这个号是闲鱼在创建订单的时候生成的，那么这个号是否有必要暴露给买家和卖家呢？

闲鱼创建的编号是他自己商户平台订单号，支付宝会在创建订单时再生成一个交易号，这个交易号和商户订单号时相对应的（这两个编号在支付宝账单详情是可以看到的），闲鱼在他的平台上的用户订单中可以只展示 [商户订单号（买家 /卖家同时看到）] ，实际上闲鱼也是这样做的。

而这里的交易号是卖家在通过自己的支付宝账单来查找到的，这个交易号我前面就说过了，他的应用场景还有如：对账，退款等。


支付宝的场景是一个支付平台，而不是特定于某个平台去服务，他同时提供商户订单号和交易号这都是合理的。


在这里支付宝的问题是只关注了 [调起确认收货] ，而却没有验证是谁（来源）调起的。

---

我后面说的给订单加个状态来判断，这种实际上也是不合理的，因为还要考虑自动收货。

[sobev]

淘宝确认收货的时候不也要输入密码嘛

[sillydaddy]

@Rache1
「如果这个交易号暴露给了卖家，那么卖家也可以作为发起人了」，我这里说的卖家作为发起人就是指主题里的那种诈骗手段：卖家诱骗买家确认收货。这也可以看作是卖家作为发起方吧。前提就是卖家有这个交易号。

我理解了你的意思是不是说，支付宝担保交易这种，从头到尾，也只有一个交易号，并且这个号同时被买家、闲鱼、卖家共享？担保交易相对于直接交易，多了一个中间状态，对于买家来说，是已付款待确认，而对于卖家来说则是已付款未收款。是这样吗？

如果是这样，交易号是统一且共享的，那么是不适合作为 API 的参数来用的，比如对于买家来说确认收货的 API 。支付宝完全可以针对每一个交易号，再产生一个对应的确认收货号，并且仅下发给闲鱼。然后闲鱼才可以使用这个收货号，在 App 中让买家发起确认收货的操作。由于这个确认收货号只会在交易过程中才使用，交易完毕可以废弃，所以不影响最终的交易结果和数据归档。就相当于是一个对应于某种操作权限的 token 。

[iold]

@sobev #64 我看视频了，有开人脸识别的，直接识别就收货了。

[coldmonkeybit]

像这样的国内平台明目张胆骗钱，讲道理不是应该可以马上抓起来吗？

[manhere]

顶级大厂，顶级设计！

[shakoon]

这个漏洞并不是技术层面的 bug ，完全就是产品设计的缺陷。漏得如筛子一样，如此的无脑，以至于这么多年都没有被黑产发现，也是给足了支付宝面子了

[Mosugar]

为什么所有的 app 都必须要封装一个浏览器

[zhumengyang]

md ，绝了

[pkoukk]

@sillydaddy
支付宝是一个第三方交易平台，它的交易流水号必须透明，做到两侧不一致是错误的。
假设 用户银行卡-支付宝-商户 这样一个流程，支付宝生成的流水号会提交给银行，用户在银行流水里能查到
同时流水也要提交给商户，这样用户在商户平台也能查到，两边流水一致才能证明这是同一笔交易行为
这个没有什么问题，目前通行的系统都是这么设计的。

基于以上设计，闲鱼其实是没毛病的，闲鱼通过支付宝的订单确认回调，得知用户已确认收货，执行放款。
换句话说，这个平台即使是其他商户（ pdd 或其他购物平台），一样也会中招。
所以支付宝大锅，对这种确认收货的行为没有做任何校验
闲鱼小锅，对扫码结果是 alipay:// 开头的协议直接放行，没有风险提示

[liuzhedash]

@coolcoffee

这个才是核心的点：跨域调用没鉴权
我之前也被微信支付折腾的欲仙欲死，但是后来逐步理解其各种限制的目的了，支付宝这套可能做得比较早，当时没有这么多攻击的花样

[Rache1]

@sillydaddy

> 支付宝完全可以针对每一个交易号，再产生一个对应的确认收货号

你说的这个方法也是算是一种解决办法，实际实施起来相较于现有的有些过于复杂了。其他人提到的，给 JSBridge 添加鉴权这种方案比较简单且可行的。

[cnit]

我刚刚测试了下已经修复了，会弹窗 [交易已付款，请勿重复支付]

感兴趣的把这个诈骗网站本地部署下把里面的交易号改成自己的就行了
http://kgnb763n.blogqt.gq/index.php

[ZeroDu]

按理说，淘宝商家有可以钓鱼买家来确认收货（虽然没必要怎么干），接口应该都是统一的

[qiangxiaoliu]

@dcsite 这个现在修复了吗？

[rapperx2]

刚才复现了下，已经修复了

[lmhsmart]

支付宝全责
1. deeplink 未做白名单
2. jsb 鉴权问题

[zhlxsh]

@C47CH #62 好问题，等等看吧。
我猜一个不会，这样就承认自己有漏洞了，喊口号仅仅是为了让别人用自己的服务，真赔了会有负面影响

[wanguorui123]

CSRF

[dif]

目测不会赔吧，而且这也掀不起什么波浪。

[RobinHu]

希望上热搜，段一个后续。

[sillydaddy]

@pkoukk #72 对，闲鱼应该没啥问题。我之前一直以为确认收款的操作是闲鱼发给支付宝的。流水号一致的要求也挺合理。

[sugarat]

对象之前也中过招，小红书上买转转的 也是类似的假网站，在支付宝里直接付款了

[dcsite]

@bjzhush 连安全都谈不上的产品，对我来说就是垃圾。
假如有一天你们公司任何人都可以登录你的银行帐号，查看流水，修改登录密码，你还会信任这家银行吗？

PS：只要知道银行卡和手机号就行，任何设备都可以改密码并登录。

[InkAndBanner]

反转了家人们，据说是支付宝给淘系业务提供支持 淘系业务自己开发的 锅在咸鱼

[onlyu]

@InkAndBanner 没啥反转的，两个都有安全问题