我正在开发一个使用证书固定的Android应用程序(以类似this的方式)。
但是,我遇到了诸如Frida或更糟的Objection之类的动态工具库,它们可以绕过这种保护措施。
我知道必须在服务器端实现安全性,但是,我想在我的API之外继续窥视。而且,我还理解Java可执行文件易于反汇编和分析。
我如何使攻击者更难执行此过程,即执行诸如objection
之类的基本命令
android sslpinning disable
无法通过我的应用加固?我已经看到,根据资产的名称,此过程也会崩溃。
有什么想法吗?
答案 0 :(得分:1)
几个强化框架可能会使Frida和类似工具难以附加和操纵应用程序流程。但是,只要有足够的时间,动力和/或金钱,您甚至可以打破这些框架。
但是,通常不是“是否使用强化框架”这个问题,而是“您愿意为获得这种额外的保护支付多少钱?
据我所知,没有免费甚至廉价的强化框架(如果我错了,请纠正我,并提供具有良好保护的免费/廉价解决方案的链接),因此,这只是一个问题,您需要多少保护以及如何保护您愿意付出的代价。
注意:Proguard和R8并不是强化框架!他们只是稍微混淆了代码,但是特别是当涉及到证书固定和通过Frida禁用它时,它们不提供任何保护!
答案 1 :(得分:0)
我如何使攻击者更加困难
针对您的问题的一种可能的解决方案是使用移动应用程序证明解决方案,以确保在运行时您的移动应用程序不受MitM攻击,未被篡改,不在有根设备中运行,未连接到调试器,没有任何检测框架。这是通过在后台运行SDK来实现的,该SDK将与在云中运行的服务进行通信以证明移动应用和设备正在运行的完整性。移动应用程序中的SDK不会根据移动应用程序提供的度量标准对应用程序或移动设备的完整性做出任何决定(在云服务中完成)。
因此,在成功证明移动应用程序完整性时,云服务会发布一个短暂的JWT令牌并用一个秘密签名,该秘密只有云中的API服务器和移动应用程序证明服务可以识别。如果移动应用程序证明失败,则会使用API服务器不知道的秘密对JWT令牌进行签名。
现在,应用程序必须随每个API一起发送,并在请求的标头中调用JWT令牌。这将允许API服务器仅在可以验证JWT令牌中的签名和到期时间时才处理请求,而在验证失败时拒绝它们。
一旦移动应用程序不知道移动应用程序证明服务使用的机密,即使在应用程序被篡改,在有根设备上运行或通过连接进行通信时,也无法在运行时对其进行反向工程成为中间攻击中一名男子的目标。
因此,该解决方案可在没有误报的积极检测模型中工作,从而不会阻止合法用户,同时又将坏人拒之门外。
有什么想法吗?
您可以尝试推出自己的解决方案,也可以寻找现有的移动应用证明SAAS解决方案,例如Approov(我在这里工作),该解决方案为多个平台(包括iOS,Android,React Native)提供SDK和别的。集成还需要在API服务器代码中进行少量检查,以验证由云服务发出的JWT令牌。对于API服务器来说,必须进行此检查才能决定要处理的请求和拒绝的请求。
最后,必须根据要保护的内容的价值以及该类型数据的法律要求(例如GDPR法规)来选择用于保护API服务器和移动应用程序的解决方案在欧洲。
您似乎对移动应用程序的安全性很感兴趣,我是否建议您:
OWASP Mobile Security Project - Top 10 risks
OWASP移动安全项目是一个集中式资源,旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目,我们的目标是对移动安全风险进行分类并提供开发控制措施,以减少其影响或被利用的可能性。