灰产-如何破解请求验签（上）
前情提要
先来个前情提要：灰产-如何对APK修改后重签
在写那篇文章的我，是否会想到我竟然还有有关“灰产”的下文来写？而且就标题来说，还有分上下两篇！所以这4个月不到的时间我又经历了什么呢？
写在前面
以下都是情节模拟，并非具体情况，请细加甄别
让我们把时间拨回到年后。
年后回来一阵子，接到业务风控同学的反馈，我们有用户发现自己的账户被盗了，自己购买了不是自己的商品（不产生金额）并对这个商品统一匿名评价……
我第一反应卧槽哥们我们应用不是做了端校验，不同设备必须验证码登录，怎么连手机一起丢了才有后面能说漏洞导致账密泄漏的事？
后面通过网关日志、应用日志、接口日志等排查，发现这个用户的登录凭证（token）有从境外服务器请求服务的情况，可以基本确认是 token 的泄漏；
再和用户沟通以及进一步的深入排查，我们发现 token 的泄漏源于用户被钓鱼，这里细节不表；被社工得到的 token 会先从 ip 1 被收集并转发给 ip 2 进行购买请求与评论……
这里涉及到一个问题，我们的请求在各端做了验签，Sign 参数会根据不同端走不同的计算方式，想要更改 token 并发起购买请求，不重新计算 Sign是不可能通过校验的，只有两种可能：
- 我们的 Sign 计算方式被破解
- 我们的 Sign 计算方式可被任意调用
总而言之
总而言之，这个任务又落到我这里了= =
会议讨论对齐的时候，研发一致认为是在 H5 端的 Sign 计算方式太简单了，如何计算已经被破解，应该换上现在端上更安全的 Sign 计算就可以了！
直接破解一个计算方法理论上是不太容易的，我更在意的是是否是哪个地方泄漏了 Sign 的计算方法，或者在什么地方的计算代码可以被调用，直接入参入值然后得到结果。
但这里就要提到另一个事情了，研发不告诉你！
他们只表述这个好像比较简单就能破，但问他们怎么破的，不知道；问他们在哪里可能泄漏了，不知道：
“大概是从前端 JS 泄漏的？你看我们这里都做了混淆了，你看是不是就是这个位置，sign 关键词都命中了……”“可是为啥我调试/下断点没反应啊？”
后来嘛，在把钓鱼的口子堵了一下后，换上“更安全”的 Sign 计算方式后，喜闻乐见的钓鱼的口子也被绕过了，“更安全”的 Sign 计算也被破解了……
然后呢？
遭殃的还是我好吧，本来他们都认为可行的解决办法没用的时候，我就不得不花时间和精力来看看不在我 OKR 上的问题了
泄漏发现
算研发很配合安全工作，虽然告诉了我一个错误的泄漏位置，但起码提醒了我可能是 JS 就已经泄露了，没必要一来就去逆向找源码。
开始的思路还是去利用前端给到的 JS 复用：Burp Suite作为代理，复用目标站点的js代码处理指定的内容
后来发现 JSFlash 必须要能够指定调用代码函数才行，前端 JS 混淆了，指向不出来，直接分析不了
然后我就在前端登录页 Source - js 找到了 Sign 计算点，并且下断点步进调试看到了所有 Sign 的计算入参：
它端验证
在前端 JS 调试的过程中能看到有一个 secret 参数是不会暴露在 request 里的，其他端的如何获得？
Jadx 逆向反编译一下应用端，以 SIGN 为关键词，在源代码中发现了硬编码在其他端使用的 secret，以及使用的 Sign 最后加签算法：
写在后面
上篇就到这里，写的好像很简单，解过程也没遇到什么麻烦，但是还得说和大伙配合的还是不好，我还是认为不管是锻炼或者检验个人能力也好，工作任务忙不想接手深入这个事情也好，如果是以把事情完成的结论来说，相互配合是很重要的。
以旧 Sign 为例，大家说的好像每个人都知道这个是怎么生成的，但就是没人和你说，告诉的还是错误的位置，即使真的可能知道是怎么生成的不知道是在哪里泄露的，那信息汇通还是更重要的。研发完全可以告诉你“我猜是在前端 JS 泄漏的，位置是在这里，他的调用是这样的……”给你演示出来，如果真的在前端直接 Debug 下断点走一遍，就会知道一开始的位置告诉错了，并且一下就把泄漏点找出来了。
不会浪费双方的时间的。
