gol*_*gil 8 security url-scheme phishing ios
场景:
一个Web应用程序,一旦新用户完成注册,将发送一封电子邮件,其中包含一个曾在iOS设备中点击的URL,iOS应用程序将启动.此方案是使用户使用移动应用程序的经典方案.
在实现它时(使用URL方案),我们开始想知道这种方法有多安全?从理论上讲 - 恶意应用程序可以注册相同的URL方案,并且根据Apple的说法:
注意:如果多个第三方应用程序注册以处理相同的URL方案,则目前没有确定将为该方案提供哪个应用程序的过程.
在这种情况下,如果用户正在点击电子邮件中的网址,则不知道将启动两个(或更多应用)中的哪一个(我们的或恶意的).让我们说一个不同的应用程序正在推出 - 如果它真的是恶意的,理论上它可以模仿我们的应用程序的登录页面并获取用户的凭据.
是否有处理此类情况的最佳做法?我已经阅读了很多关于这个问题的文章,他们都声称唯一的解决方案是等待Apple使这些网址方案独一无二. example1, example2
如果存在,我很想听听有关问题的任何解决方案,提前谢谢!
我们必须假设恶意应用程序可以拦截此网址中包含的任何数据,并且其作者可以自由地对您的应用程序中包含的任何行为进行逆向工程,以便它可以模仿您的 UI 以及您的应用程序尝试执行的任何验证。但是,我们也可以假设恶意应用程序包含在自己的沙箱中,因此您的应用程序可以与后端私下通信。恶意应用程序可以模仿任何此类通信,但这确实允许我们构建恶意应用程序未知的秘密。这至少给了我们一个设计一些对策的机会。
一种选择可能是:
现在,我们已将数据发送到您的应用程序,这些数据可能会重定向到恶意应用程序,但恶意应用程序无法读取这些数据。这是部分解决方案。我们仍然需要小心设计一个 UI,不要鼓励用户陷入网络钓鱼攻击,因为 URL 仍然可能会启动冒名顶替者。
编码数据可能是我们可以用来对用户进行身份验证的令牌,因此永远不需要他们在应用程序内重新进行身份验证。然后就没有可以模仿的登录屏幕(尽管巧妙的伪造可能仍然足以诱骗用户泄露他们的凭据)。
另一种方法可能是使用存储在客户端上的类似的每用户秘密作为盐来与用户的密码相结合。仅凭他们的密码可能不足以进行身份验证,因此捕获他们凭据的恶意应用程序无法立即访问他们的帐户。
另一种设计可能是允许用户以可识别的方式定制他们的体验。您可以在登录屏幕上显示他们选择的个人资料图片。如果该选择只有您的应用程序知道,那么模仿者应该无法可靠地复制它(同样,不能保证这意味着用户会发现欺骗)。
所有这些都会带来权衡;用户仍然可能被诱骗向恶意应用程序泄露信息,无论它们与您的合法客户端有多么不同,客户端机密可以通过其他攻击提取,并且您需要一个计划来支持切换、丢失或升级设备的用户。您必须决定这是否真的可以提高用户的安全性,以及是否值得付出成本来实施。
| 归档时间: |
|
| 查看次数: |
1178 次 |
| 最近记录: |