Without using SSL, what's the most secure way to make an AJAX request to a PHP page?

Question

It was suggested over at stackoverflow that I try my question here. This is it verbatim:

So, it's impossible to do AJAX requests securely without using SSL. I get it. You can either view-source the data that's being sent via Javascript, or you can directly access the PHP page by spoofing headers, yada yada.

But let's say this web app doesn't particularly require true security, and instead it's just a sort of game to keep most reverse-engineers at bay. What sort of hurdles should I employ?

I'm not looking for some ridiculously over-the-top Javascript implementation of an encryption algorithm. I want simplicity as well as mild security... if that isn't contradictory by nature. So, what would you guys recommend?

For example, I'm running a contest where if a user clicks an image successfully (jQuery), it passes their userid and a timestamp to a PHP page, both MD5 salted by random data and then encoded with MIME. The PHP page then validates this userid and timestamp, then returns a winning "code" in the form of another salted MD5 hash. I'm also employing multiple header checks to help ensure the request is from a valid location. Am I missing anything, or is that about all I can do? It seems like someone could just fire the jQuery click event and ruin the whole thing, but I don't see how I can prevent that.

I'll be awarding the answer to anyone who comes up with an ingenious faux-security mechanism! Or... just whomever tells me why I'm stupid this time.

Answer 1

Specifically, what are you trying to be secure against?

Eavesdroppers recording or intercepting messages between the client and host? You basically need SSL to ensure no one can eavesdrop, or create your own encryption protocol (say as a browser extension or javascript on the page), though I strongly recommend against the create-your-own encryption method (will be slower/weaker and almost undoubtedly have major flaws if you do not have it examined by several crypto experts). Granted if your users only have computers on separate networks from each other (and the host machine) and do not control intermediate networks (e.g., work at one of your ISPs), they won't be able to eavesdrop.

I'm not sure what the point of your game is:

For example, I'm running a contest where if a user clicks an image successfully (jQuery), it passes their userid and a timestamp to a PHP page, both MD5 salted by random data and then encoded with MIME. The PHP page then validates this userid and timestamp, then returns a winning "code" in the form of another salted MD5 hash. I'm also employing multiple header checks to help ensure the request is from a valid location. Am I missing anything, or is that about all I can do? It seems like someone could just fire the jQuery click event and ruin the whole thing, but I don't see how I can prevent that.

Are there multiple images and only one image is correct and they are only allowed to guess once? I'd suggest having them use a server-issue token of some sort.

A correct process would be (a) they use their secret credentials (username, password) to request a one-time guess token (a unique random string) from the server. They then make their guess (by clicking an image) which submits the username, guess token, and the image they chose. The server records the image if the submitted guess token was valid and has not been previously used; otherwise it says token not valid and throws out their answer. This still let's an eavesdropper figure out the correct answer.

Answer 2

This seems like more of a question of a client tampering and firing Javascript, which SSL doesn't prevent.

It seems like someone could just fire the jQuery click event and ruin the whole thing, but I don't see how I can prevent that.

That is pretty much correct, client side scripting, especially Javascript are impossible to lock down against stuff like event triggering.

The PHP page then validates this userid and timestamp

I foresee bugs due to latency/clock differences (being as Javascript is going to pull from the local PC) depending on the granularity of your timestamp, and how far forward/back you're going to hash out to see if there are any adjacent matches.

Plus having the algorithm someone really determined will look for hash collisions due to MD5 being terrible (if I'm understanding your implementation correctly and are only passing the hashes).

However, no matter what you use for encryption, it's client side scripting, so I can just fire whatever method you use to post the data to your server or easily reverse engineer it.

Answer 3

It sounds like your game provides "quiz-like" behavior, where there are a bunch of places the user could click, and only one of them is correct. The server knows which one is correct, and the puzzle for the game player is to figure out which one to click. Is that right?

It sounds like what you are currently doing is sending the solution to the quiz (the location of the correct place to click) to the client, and using Javascript on the client to check each click to see whether it is correct. If it does seem to be correct, then you send it up to the server with some other gunk. Of course, this is inherently insecure, because if the user is malicious, they can tamper with the Javascript (or the Javascript execution environment), peek inside it, figure out which is the correct place to click, and then win the quiz.

The secure way to do this is to do all of your solution-checking on the server. Don't send the correct solution to the client. When the user clicks on a location, send the location to the server via an AJAX query. Have the server code check whether the user's click was correct or not, keep track of this, and send back a response. That way, no matter how much the user messes with the client-side Javascript code, they can't see the correct solution and they don't get any advantage at solving the quiz.

The general rule of thumb is: you can control the server, so if you code up the server-side application correct, you can trust it. However, you cannot control the client (the browser is under the user's control, not your control), so you cannot trust the client or the client-side code. Never trust the client: put your security checks on the server.

Answer 4

the following book is great in Ajax security Ajax Security , have a look at it