如何限制对PHP文件的访问？ [英] How to restrict access to a PHP file?

问题描述

我想限制访问我服务器上的PHP文件。此PHP文件从HTTP GET请求获取数据并将其附加到文件。简单。但是我不想要执行这个PHP文件，除非从我开发的智能手机应用程序中生成HTTP请求。

I'd like to restrict access to a PHP file on my server. This PHP file takes data from an HTTP GET request and appends it to a file. Simple. But I don't want this PHP file executed unless the HTTP request is generated from within the smartphone app I've developed.

我不想验证每个用户个别。我希望我的应用程序，只有我的应用程序能够将请求发送到PHP文件。我不希望人们在浏览器中输入类似形式的请求（http://www.mydomain.com/check.php?string=blahblahblah）并产生同样的影响。

I don't want to authenticate each user individually. I want my app, and only my app, to be able to send the request to the PHP file. I don't want people typing in a similarly formed request (http://www.mydomain.com/check.php?string=blahblahblah) into a browser and have the same impact.

我考虑过检查HTTP_USER_AGENT或其他一些变量，但我担心它们也可能很容易被欺骗。我可以在我的应用程序中嵌入一个密钥，但是该密钥也可能会被泄露。

I have thought about checking the HTTP_USER_AGENT, or some other variable, but I fear that they might be easy to spoof too. I could embed a key into my app that I look for, but that key could also be compromised.

下一步是让服务器向我发送一个挑战我的回答是恰当的。或者我甚至可以看看PKI。但是，这是一种相对简单的方法，因为我并不是想保护任何真正有价值的东西，只是为了防止轻微的破坏行为。

The next step would be to have the server send me a challenge to which I respond appropriately. Or I could even look into PKI. But what's a relatively easy way to do this, given that I am not trying to protect anything of real value, just to prevent minor vandalism.

我是否想要重新发明在这里转？有没有一种简单，经过验证的方法可以做到这一点？

Am I trying to reinvent the wheel here? Is there already an easy, proven way to do this?

推荐答案

FWIW，这是我能想到的最安全的方法严重影响性能 - 本质上是RESTful（ish）方式，为了进一步提升它需要存储在服务器上的多个请求和连接状态信息：

FWIW, here is the most secure method I can think of without seriously affecting performance - essentially the RESTful(ish) way, as to ramp it up any further would require multiple requests and connection state information stored on the server:

• 应用程序和服务器具有相同的硬编码盐字符串，对于每个后续版本的移动应用程序都是唯一的。此字符串必须保密。


• 当用户在其设备上安装应用时，该应用会与您的服务器联系并通知其应用版本，和设备的 IMEI ，您使用的任何移动平台的API都可以让您检索。


• 服务器为应用程序实例生成一个唯一密钥，该密钥将发送回应用程序并存储在设备上，并使用IMEI将其存储在服务器端数据库中。已安装的版本。


• 在日常操作中（即在提出问题中概述的请求时），应用程序遵循以下步骤：
  
  
  
  
  • 检索以下信息：
    
  • The app and the server have an identical salt string hard-coded, unique to each successive version of the mobile app. This string must be kept private.
  • When a user installs the app on their device, the app contacts your server and informs it of the version of the app, and the device's IMEI, which the APIs for whatever mobile platform you are working with should enable you to retrieve.
  • The server generates a unique key for that instance of the app which is sent back to the app and stored on the device, and stores it in the server-side database with the IMEI and the installed version.
  • During day-to-day operation (i.e. when making the request outlined in the question) the app follows this procedure:
    
    • Retrieve the following information:
    
    
    1. 设备IMEI
    
    
    2. 应用密钥
    
    
    3. 应用程序版本
    
    
    4. 硬编码盐字符串
    
    
    5. 随机生成的字符串用于额外的盐（当前的衍生物）带有微秒的时间戳对于合理数量的熵总是好的。）
    
    
    1. Device IMEI
    2. App key
    3. App version
    4. Hard-coded salt string
    5. Randomly generated string for additional salt (derivative of the current timestamp with microseconds is always good for a reasonable amount of entropy).

  
  
  • 将所有这些信息连接在一起，最好是硬编码在它们之间填充并生成结果字符串的散列。
  
  
  • 向服务器发送以下信息以及实际请求数据（可能在 tiny 额外的安全性）：
    

  • Concatenate all these pieces of information together, preferably with hard-coded padding between them and produce a hash of the resulting string.
  • Send to the server the following pieces of information along with the actual request data (maybe in cookies for a tiny extra bit of security):
    
    
    1. 生成的哈希
    
    
    2. 应用密钥
    
    
    3. 随机生成用作附加盐的字符串
    
    

  
  

  为了突破这个系统并成功欺骗请求，攻击者需要知道以下内容：

  In order to break through this system and successfully spoof a request, an attacker would need to know the following:

  
  
  1. 设备IMEI
  
  
  2. 应用密钥
  
  
  3. 应用版本
  
  
  4. 硬编码盐
  
  
  5. 用于生成散列的机制（输入字符串的精确格式和散列算法）。
  
  
  1. Device IMEI
  2. App key
  3. App version
  4. Hard-coded salt
  5. The mechanism that you use to generate the hash (the precise format of the input string and the hashing algorithm).

  显然，如果你正在使用移动设备1-3很容易提取，但如果没有逆向工程应用程序就无法找到4和5（对于那些有知识和耐心去做的人来说，实际上没有什么可以阻止的。）

  Obviously if you are working with the mobile device 1 - 3 are easy to extract, but 4 and 5 cannot be found without reverse engineering the app (which there is literally nothing you can do to prevent, for people with the knowledge and the patience to do it).

  中间人攻击将是基本上不可能 - 即使在突破SSL之后（哪个至少可以说是非平凡的，并且反向设计应用程序以获得4和5，如果没有对哈希进行强力攻击就无法检索到1-3，这非常复杂，平均需要几亿年（请参阅此页面以了解我是如何得出这个数字的），特别是如果其中一个三个是可变长度 - 应用程序版本字符串可以很容易。

  A man-in-the-middle attack would be basically impossible - even after breaking through the SSL (which is non-trivial, to say the least) and reverse engineering the app to get 4 and 5, 1-3 cannot be retrieved without a brute force attack on the hash, which is sufficiently complex that this would take an average of several hundred million years (see this page to see how I arrived at that figure), especially if one of the three is of a variable length - which the app version string could easily be.

  这篇关于如何限制对PHP文件的访问？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！