PHP - Passing data from a site to another site sec

Question

I have a site that can take requests from multiple sites. Sort of like a upgrade check. These sites will send info like user names, passwords, app version etc, then my site will send a response based on this info.

Basically this is a $_GET request, something like:

http://www.mysite.com/?user=boo&password=foo&version=4

I was wondering if there would be any security issues doing stuff like this. Could this data be "intercepted" somehow?

Answer 1

Use .htaccess to modify and cloak the url of your website. eg:

www.mysite.com/index.php?cat=1234&foo=5678

will be looking like:

www.mysite.com/cat-1234-foo-5678-index.html

when u successfully create the .htaccess file, both the urls will act the same.

Answer 2

Well, I would highly suggest not sending the username / password across plain text under any circumstance (even when under SSL). Instead, I'd suggest using a Digest form of authentication.

Instead, I would suggest generating a large authentication token (a random string of large size, 128 characters would work). Then, the users would install this "token" in their app.

Now, when the app checks for updates, it first fires a request to your server asking for a digest token. This is a random, one time use token that's only used for exactly one request. Your application should generate a token, store it in a durable format (file, memory, database, etc) along with the timestamp, and then send it back.

Now, your application receives this digest token (called $dt here). Then, you hmac it with the pre-configured authentication token that was already given.

$authBit = $username . ':' . $authToken;
$hash = hash_hmac('sha256', $authBit, $digestToken);
$authField = $username . ':' . $hash . ':' . $digestToken;

Then, you send the $authField to the server. The server will then split the parts:

list ($user, $hash, $digestToken) = explode(':', $authField);

Now, you first lookup the user's authentication token in the database and store it in $authToken. Then, you lookup the $digestToken to make sure that it exists and that it was created less than 60 seconds ago (you can adjust this if it's too short, but don't make it significantly longer). Either way, delete it from the db at this point (to prevent it from being reused).

Now, if the $digestToken exists and is valid, and you can find a $authToken, then just do the following check:

$stub = $user . ':' . $authToken;
if ($hash == hash_hmac('sha256', $stub, $digestToken)) {
    //valid user
} else {
    //Not valid
}

It has the benefit of changing the sent token each and ever single http request (anyone reading the request stream won't be able to get any sensitive information from the request, other than the username which you could mask further if you'd like)...

Answer 3

Security trough obscurity does not work, and using POST in stead of GET only makes the information slightly harder to snatch up if you're actually looking the user over the shoulder.

The real issue here is preventing people from intercepting the traffic in transit between the servers. The only way to deal with that is encryption, such as SSL. It's a good idea to always try to use SSL when you're transmitting sensitive information like passwords. This can be slightly harder to implement, but it's definitely worth it in terms of security.

However, the best way to keep sensitive data from being snatched up is to not transmit it in the first place. Consider whether it's an option to have your application check for updates without transmitting a password. If an update is available you can send the user to a webpage using HTTPS to download the update, which saves you the trouble of implementing SSL yourself.