How to restrict access to a PHP file?

Question

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 fi

Answer 1

If you don't want anything per-user, but only per-app, you will have to rely on a secret built into the application. Anyone disassembling the application will eventually be able to find that, so some obfuscation might help, but it won't keep determined people off your page.

That said, there is little point in using any public key crypto. As the app-side is what spoofers might be interested in, they'd already have access to the more valuable half of a key pair. So you might as well use some approach using a shared secret.

What you really want to check is the authenticity of the transferred data. So simply take the core of that data (i.e. all fields which really matter), concatenate them with the shared secret, hash the result and transfer it as a message digest. The server performs the same calculation and checks that the computed digest matches the transferred one. If it does, the sender of that message must have known the shared secret.

There still is some chance for a replay attack, i.e. someone recording a valid message and repeating it later on. You can detect exact duplicates on the server side, and prevent delayed replay by including a timestamp in the signed part of the message. If your server allows for a huge difference between client and server timestamps, it will have to keep duplicate information for that same amount of time. If it only accepts small differences, it can work with a smaller duplicate cache, but users with malconfigured devices might be annoyed as the server is more likely to reject their requests as being too old.

One more note: you wrote about a GET request causing a write to some file. I would always associate some state-changing operation with a POST instead. If the app is your own, it doesn't matter that much, but browsers are known to retransmit GET requests without asking the user, thereby causing duplicate requests for some action.

Answer 2

Firstly you would need to implement ssl into your app else someone with little knowledge could simply have there phone connected on there wifi and sniff the traffic between the app and your site with wireshark or cain and abel ect. and get the url and any parameters passed, no need to disassemble anything.

App connects to your site and user logs in, whether its a guest or a member your server assigns the app a request id and this key/token is passed along with every request & validated within a session on your server.

The token would look like: UNIQUE_REQUEST_ID_ASSIGNED_BY_SERVER:APPsIP:APPsTIME Encrypt this string and send it as a $_GET['token']

Then on your server decrypt the string and explode() the string into its parts and check against a database or session that the request id,ip and the time match ect, if all is good do which ever.

Much like a secure login system assign a unique salt for each user and store that along side the users request id.

The bottom line is, just make it hard for an abuser to abuse the system. 99% of people wont even think to fiddle and the other 1% get there ips blocked.

Answer 3

HTTP requests can be built character by character in whatever way the sender wants. Spoofing will always be possible.

Answer 4

There's no guarantee method. You can use oauth authentication... Depending upon what platform your using and how your deploying app to the phone, maybe perhaps you can compile your key into the application itself? Anything can & will always be cracked, there is no 100% security... But no shame in trying. :)

Personally what I use for my mobile apps is RESTful authentication with regular login/pass pair the token based communication till it expires. :)

Answer 5

Just add authorisation (logins, passwords, sessions etc and/or "API keys") to your PHP application and then let your phone app to authorise first before sending the needed requests. You probably didn't consider that because if your script is simple that might add some clutter to it, but then again almost every web system needs that, and you will face that as well eventually.

Let you phone application to log into your PHP app via HTTPS to exclude interception.

Answer 6

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:

• 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. 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).
  • 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. Generated hash
    2. App key
    3. Randomly generated string used as additional salt
• The server now uses the App key to retrieve the device IMEI and app version of that instance from the database, and uses that information along with the hard-coded salt string for the version ID and the additional salt string sent by the device to construct the hash. If the hash generated on the server matches the hash generated by the mobile device, the request is good, if not reject it.
• All communication in this process is over HTTPS.

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

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).

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).

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.