我不想单独验证每个用户.我希望我的应用程序,只有我的应用程序能够将请求发送到PHP文件.我不希望人们在浏览器中输入类似形式的请求(http://www.mydomain.com/check.PHP?string=blahblahblah)并产生同样的影响.
我曾考虑检查HTTP_USER_AGENT或其他变量,但我担心它们也可能很容易被欺骗.我可以在我寻找的应用程序中嵌入一个密钥,但该密钥也可能会受到损害.
下一步是让服务器向我发送一个我正确回应的挑战.或者我甚至可以看看PKI.但是,这是一个相对简单的方法,因为我不是想保护任何有实际价值的东西,只是为了防止轻微的破坏行为.
解决方法
>应用程序和服务器具有相同的硬编码盐字符串,对于移动应用程序的每个后续版本都是唯一的.该字符串必须保密.
>当用户在其设备上安装应用程序时,该应用程序会联系您的服务器并通知其应用程序的版本以及设备的IMEI,您使用的任何移动平台的API都可以让您检索.
>服务器为应用程序实例生成一个唯一密钥,该密钥将发送回应用程序并存储在设备上,并使用IMEI和已安装的版本将其存储在服务器端数据库中.
>在日常操作期间(即在提出问题中概述的请求时),应用程序遵循以下过程:
>检索以下信息:
>设备IMEI
> App键
>应用程序版本
>硬编码盐串
>随机生成的附加盐字符串(当前时间戳的衍生值,以微秒为单位,对于合理数量的熵总是有用的).
>将所有这些信息连接在一起,最好在它们之间使用硬编码填充,并生成结果字符串的哈希值.
>向服务器发送以下信息以及实际的请求数据(可能在cookie中以获得额外的安全性):
>服务器现在使用App密钥从数据库中检索该实例的设备IMEI和应用程序版本,并将该信息与硬编码的salt字符串一起用于版本ID和设备发送的附加salt字符串哈希.如果在服务器上生成的哈希与移动设备生成的哈希匹配,则该请求是好的,如果不拒绝它.
>此过程中的所有通信均通过HTTPS进行.
为了突破该系统并成功欺骗请求,攻击者需要知道以下内容:
>设备IMEI
> App键
>应用程序版本
>硬编码盐
>用于生成哈希的机制(输入字符串的精确格式和哈希算法).
显然,如果你正在使用移动设备1-3很容易提取,但如果没有逆向工程应用程序就无法找到4和5(对于那些有知识和耐心的人来说,实际上没有什么可以阻止的做它).
中间人攻击基本上是不可能的 – 即使在突破SSL(这是非平凡的,至少可以说)和逆向工程应用程序得到4和5之后,1-3无法在没有对哈希进行蛮力攻击,这非常复杂,平均需要数亿年(见this page,看看我是如何达到这个数字的),特别是如果其中一个是可变长度的 – 应用程序版本字符串很容易.