我几个玩原的朋友倒是进去尝了下咸淡，玩明日方舟的，目前没看到入坑

Moss从未叛逃

01-23 08:54

【本文来自《终末地开服这大活，怎么感觉是在蹭“斩杀线”热度，太地狱了》评论区，标题为小编添加】

目前网上流传出来的问题甚至不止这一点（有些真假未明等进一步的消息）

1 账户安全形同虚设，可以利用游戏里的文件替换直接夺舍别人账号

500

2 少前二同款症状，删游戏有概率触发清盘，甚至有倒霉蛋盘都不见了

500

3 这次的离谱支付事故

明日方舟外服是悠星运营的，鹰角无外服运营经验，终末地是首次尝试全球运营。

3测外服没有测试付费内容（付费测没测付费），结合1月5号和19号发布的相关岗位招聘信息推断——代码可能是公测前几天刚写的，内部测试没发现问题。

500

加州法院今年刚更新了一个法律，最低赔偿金是2亿

反正已经把好几个老哥干进斩杀线了，最多的一个倒霉蛋貌似被扣了15000欧，而这批第一时间冲进去氪金的除了氪佬就是忠粉。

500

通过这个讨论也能确认，国外很多人确实没啥存款，月底容错率真的低。

官方此前发布通知，称 PayPal 付款管道正在维护升级，建议用户更换支付方式，并表示会处理道具到账及扣款异常的交易，但未明确说明上述扣款异常的具体原因、修复时间及相关补偿方案。

500

新公告（推特自带机翻）：

500

知乎作者：JHack

我自己就在国内某金融机构IT部门做技术架构……
当我看到这个新闻的时候，脑瓜子嗡嗡的……
我们这一行，领导一直强调“生产安全关乎着民生”，我虽然认同但是还没太能深刻理解这句话是什么意思，现在结合yj整的大活和牢a的斩杀线，算是彻底理解了……
我已经很久没在写回答的时候用这么多省略号了，因为我可能比99%的人都清楚yj这次犯错有多逆天、造成的后果有多严重，不由自主地代入进去，想象“如果是我犯了这样的错会怎样”……
先简单给大伙介绍下三方代理快捷支付的场景是怎么回事。
一般情况下，你在网上支付一个订单，参与方是：用户（你）、商家、银行。
这时兴起了三方支付代理，比如支付宝，它对于用户的好处是，你身上那一堆银行卡、信用卡，都可以通过绑定支付宝，通过支付宝来完成支付，而不需要在支付的时候去输入对应银行的支付密码什么的，支付宝帮你全部管理起来了，很方便。
回想下支付宝流行起来之前，各位是怎么购买东西的，我就不吐槽那难用的一笔的各大银行的网银了，支付宝直接把这些痛点解决了个七七八八，纸钞已经逐渐看不到了。
于是代理方加入支付流程后，参与方就变成了：用户、商家、代理（支付宝）、银行。
那么一个订单支付流程就大致是这样的：
商家创建订单用户通过客户端向商家发起支付请求用户选择支付方式（比如选择支付宝）商家客户端向用户所选择的支付方（支付宝）同步订单信息并发起支付请求支付宝通过回调/重定向确认用户信息（例如让用户在支付宝的页面输入支付密码等）支付宝确认身份后向该用户绑定的银行发起支付请求银行通知支付宝扣款成功支付宝通知商家支付成功商家向用户交付商品
里面有大量细节略过了。这个过程中商家并没有参与在「支付」时的用户身份认证，商家只提供基础信息给支付宝，由支付宝和银行来负责确认用户身份和支付信息是否一致。总之，支付宝需要通过某种方式确认将要进行支付的这个支付宝账号就是发起支付的本人，往往是通过支付密码、人脸识别、动态验证码等，一般是支付宝给商家提供的url，在iOS一般是universal link，商家通过这个url可以打开支付宝App或者支付宝的网页，要求用户进行身份验证。
这里支付宝和商家又开启了一个功能，叫做免密支付，也就是由商家承担一部分用户身份确认的责任，在向支付宝发起支付请求的时候，可以不需要再由支付宝向用户发起身份校验。
用户在商家那里开通免密支付后，商家就会通过某种方式将用户信息和其支付宝信息绑定，比如支付宝会给商家一个该用户对应的令牌，只要支付宝看到这个令牌，就如同见到了用户本人一样。然后商家需要将这个支付宝提供的令牌与用户信息绑定起来，比如A用户开通了免密支付，那么支付宝就会给商家一个A用户的令牌，商家自己需要将A用户的uid和这个令牌通过某种方式绑定。这样每当A用户发起支付时，商家只需要通过A用户的uid找到这个令牌，然后拿着令牌去找支付宝支付，支付宝就不需要再通过给商家一个url让用户进行身份验证了，因为支付宝看到了这个令牌，知道这是A用户本人发起的支付。
同时，为了防篡改、盗用，商家需要通过非对称加密对令牌进行签名，大致流程是：商家生成一对密钥，分别是私钥和公钥，这对密钥可以互相加解密，对任意内容，如果用私钥加密，那么只能用公钥解密；如果用公钥加密，那么只能用私钥解密。商家将公钥提供给支付宝，然后用私钥加密这个令牌，这样每次支付时将加密后的令牌提供给支付宝的后，支付宝用公钥尝试解密，如果解密成功，则说明这个令牌一定是商家给过来的，中途没有被篡改过。因为支付宝的这个公钥只能解密由商家私钥加密的内容，而这个私钥只可能是商家才拥有的（当然，如果商家连自己的私钥都保管不好，那是无解的）。所以就算这个签名后的令牌泄露出去了，比如被黑客拦截了，黑客也无法篡改其中的信息，因为黑客没有私钥，篡改后如果不重新用私钥加密，支付宝那边是无法用公钥解密的，而无法用公钥解密就说明信息被篡改了，这就是签名（防篡改）的基本原理。
当然这其中还有大量技术细节需要解决，比如支付宝和银行之间的账务处理（对账、拒付调单、退款等等），还有一些网络安全问题，比如支付领域必须要处理的重放攻击等等这里就略过了。
所以了解了以上流程，大概率就能简单推理yj到底怎么整出来的这个活。
A用户和B用户均在zmd（商家）开通了paypal免密支付，现在A发起支付，结果B扣了钱，说明zmd在A用户支付时，实际向paypal提供的是B的令牌。
所以极有可能是zmd的令牌管理有问题，比如大家共用一个令牌池，支付时随机从池子中挑选一个「幸运儿」…… 我觉得这概率应该比较小，我不敢相信设计支付系统的人会这么玩……
所以重新考虑一下问题的本质，是「信息隔离」失效，也就是原本A用户的令牌应该与A用户绑定，B用户无论如何也不可能获取到A用户的令牌，而现在却获取到了，这本质是一种对信息的「越权」访问，用户A访问到了用户B的内容，典型的横向越权问题。
所以可能性有很多种。
比如yj没有校验令牌和用户之间的关系，通过用户uid获取令牌时，默认获取到的就是正确的令牌。
倘若yj是将这个关系通过键值对存放到redis里面的，那就有可能是共享变量线程安全导致的问题，比如A发起支付时，工作线程获取到A的uid，存放到了一个共享变量M中，此时M的值是A的uid。而在前往redis查询令牌前，B又发起了支付，此时工作线程获取到了B的uid，覆盖了共享变量M的值，此时M的值变成了B的uid，注意，此时A的支付流程还没走完，也就是才走到了「通过uid获取A的令牌」这一步。在A的支付流程中，接下来的程序就会拿着M的值去获取令牌，但是此时M的值已经变成了B的uid，自然获取到的就是B的令牌，所以就出现了A的支付却用了B的令牌的情况。
当然这也只是一种容易想到的猜测，实际情况还是不太清楚。
我最无法理解的是，这问题已经爆出来俩小时了，yj才开始反应……
这是我第几次用省略号了？我真的脑瓜子嗡嗡的。这种问题要是第一次爆出来没在10分钟内开始干预、应急，后果就已经不可收拾了。zmd免密支付的的TPS肯定不低吧？
最离谱的是，没有熔断机制，系统应急熔断没有，业务（金融）熔断也没有，真不把生产安全当一回事啊我的老鹰，那就自行承受吧。