Information Security
appsec web-application php javascript ajax
Updated Thu, 02 Jun 2022 18:34:21 GMT

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


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.

Solution

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.

Comments (2)

  • +0 – I'm just trying to be 'secure enough' or 'a big enough pain in the ass' to prevent the thought of tampering from crossing their minds. There is no one particular area I'm trying to secure. And, yep, there are multiple images, so I'm going to try implementing your suggested process. But this still leaves the issue of someone just firing off Javascript, which there is seemingly no solution for. — Mar 15, 2012 at 15:55  
  • +0 – @daveycroquet - But if they fire off javascript, won't you record them answering a wrong answer most of the time? Say your game is a multiple choice quiz. The client-side submission for any answer should look identical. (A,B,C,D)+token and only once the token arrives server side is it checked to see if its correct. (Again, still vulnerable to eavesdroppers learning the correct answer from a previous user.) — Mar 15, 2012 at 16:00  

References