Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
3  
lol. Weirdest question of the week. –  k to the z Mar 15 '12 at 13:52
    
Hi Daveycroqet, welcome to Information Security. Please take a moment to read the FAQ. Can you elaborate a bit more, on your specific requirements? Why do you not need security, and if so why are you bothering to do anything? What kind of data / functionality do you have. Are you only trying to hide your diary from your kid brother? –  AviD Mar 15 '12 at 14:12
    
I don't need end-to-end SSL because this is just a game for a few people, so yes, you could consider it like hiding my diary from my kid brother. Likewise, implementing SSL for the pages this game is currently embedded in would be an undertaking in itself. Basically, I'm just wanting something that's secure enough to discourage them from trying to cheat the system (they are fairly technically savvy). As for data/functionality, I'm not sure how I could elaborate more than what I've already stated in the question. Could you be more specific on what you're looking for? –  daveycroqet Mar 15 '12 at 14:18
2  
This is possibly not the best place to ask for a solution that looks secure but isn't :) –  Andy Smith Mar 15 '12 at 14:52
    
If you care about security, then you should it with ssl. period –  Rook Mar 15 '12 at 17:59

4 Answers 4

up vote 4 down vote accepted

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.

share|improve this answer
    
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. –  daveycroqet Mar 15 '12 at 15:55
    
@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.) –  dr jimbob Mar 15 '12 at 16:00

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
I wish I could give two correct answers. You basically reaffirmed everything I thought. And you were absolutely spot on with how I'm doing everything (re: timestamps). –  daveycroqet Mar 15 '12 at 15:52

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.