我是从蜘蛛攻击者的角度谈论客户端API安全设计

示例1金融APP订阅杂志

这本杂志是我最喜欢阅读的内容之一。我购买了三年的订阅。这期上周就过期了，但是我想看一篇我离线的去年杂志上的文章，却发现打不开。我顿时心烦意乱，想杀了她，于是我用著名的网络调试器Surge直接在手机上用中间人攻击没收了她的包。

原来他的杂志清单是这样的：

注意package_path！这些事情绝对不应该被提起。

我拿到了杂志的链接，发现开发者显然考虑到了这种情况，对杂志进行了加密。要加密 zip，必须有一个地方可以传输密码。然而我来回查找，却没有找到类似的API，也没有看到socket的存在。我开始怀疑是否有需要付费的 API，所以我查看了代码。

我的遭遇是我在最后一刻才这么做的，而且我身上没有越狱机。我只能使用我不擅长的Android逆向工程来查找问题。首先，使用jadx将代码提取到APK中。注意力！此 APK 未进行强化！

grep zip 代码中的相关内容，结果我们得到：

public native String getZipKey(Context paramContext);

这个 API 非常可疑，我们发现了一个有趣的事情：native 这意味着这个 API ndk 包含。结果我在lib文件夹下看到了libZipKey.so。这是我见过的最愚蠢的命名。他好像在说钥匙在我这里，过来转动一下。

从这套API的设计可以看出，该开发者的水平并不高。所以我首先使用strings命令来扫描这个动态链接库中合适的字符串符号。我看到了字符串e811xxxxxxxxxxxxxxxxxxxxx，很奇怪。我只是随意放松，宾果游戏……然后什么也没发生。这套事情花了不到五分钟，没有使用动态调试就完成了。 ？有很多具有大局观的长文章值得阅读，这就是我想首先转移到 Telegram 的内容。

然而，其移动版和PC版的主页设计更为复杂，并且在提要中嵌入了横幅。有些横幅还通过提要重复关键亮点，这非常复杂。首先，我想获取他的应用程序的 json API，但我一直碰壁。

HTTPS证书验证

网络数据包分析的第一步应该是使用Surge进行中间人攻击。事实证明，客户端确实进行了证书验证。你相信吗！直接抛出处理错误。为了确认我在使用 Surge 时的姿势是正确的，我再次使用 Charles 并重复了同样的结果。

这种情况下，iPhone不坏的话我们也无能为力。我们甚至不知道他请求的路径，所以只能进行静态分析。

静态域名分析

照常下载APK并对jar进行逆向工程。 APP也没有被增强或遮挡，所以我们可以继续查看内容。通过grep域名，我们找到了断点，是一个名为component/net/NetworkConstants.java的类。里面有很多路径，例如：

所以我们通过host+path串联得到了完整的URL，看起来很合理！所以我们要求：

我们不要抱怨，为什么它明明返回的是JSON，但是Content-Type：text/html，但是它告诉我们一件事，它甚至要求一个GET横幅API。签了，安全意识真好。既然你要签名，那我就去找签名。

静态分析signature

借助grep、signature，发现我们真的中奖了。我们得到这个返回值：

看起来有一个到这个CommonParams的路径。阅读里面的代码：

没错。签名的结果编译得很轻松愉快：

最后一步就是找到目标请求。返回到上面提到的 NetworkConstants，检查它们并获取路径：feed/commonFeeds。模拟请求成功！我看了看表，总共时间是30分钟。

总结

这里举了两个很基础的例子，但却体现了很多客户端开发中需要注意的问题：

• 不要忘记对Android进行强化和替换，不要偷懒
• 一定要使用HTTPS通讯，记得检查证书可以阻止很多新手攻击者
• 与后端API对话生成签名
• 应该更换签名生成算法，尽量使用常量字符串尽可能少。如果您想使用 C++ 进行混淆，请记住某些 NDK 名称和函数签名无法自动混淆，必须手动处理。
• API 应尽可能与 cookie 绑定，并且应妥善管理权限。如果出现蜘蛛，后端可以屏蔽cookie账户。

爬行预防只能基于对抗性策略。没有办法将他们全部杀死。基本上就是不断提高攻击阈值。