Ajax Security (i hope)

Question

I'm building a browser game and im using a heavy amount of ajax instead of page refreshs. I'm using php and javascript. After alot of work i noticed that ajax isnt exactly secure. The threats im worried about is say someone wants to look up someones information on my SQL server they'd just need to key in right information to my .php file associated with my ajax calls. I was using GET style ajax calls which was a bad idea. Anyways after alot of research i have the following security measures in place. I switched to POST (which isnt really any more secure but its a minor deterent). I have a referred in place as well which again can be faked but again its another deterrent.

The final measure i have in place and is the focus of this question, when my website is loaded i have a 80 char hex key generated and saved in the session, and when im sending the ajax call i am also sending the challenge key in the form of

challenge= <?php $_SESSION["challenge"]; ?>

now when the ajax php file reads this it checks to see if the sent challenge matchs the session challenge. Now this by itself wouldnt do much because you can simply open up firebug and see what challenge is being sent easily. So what I'm having it do is once that challenge is used it generates a new one in the session.

So my question is how secure is this from where im standing it looks one could only see what the challenge key was after it was sent and then it renews and they couldnt see it again until it is sent, making it not possible to send a faked request from another source. So does anyone see any loop hole to this security method or have any addition thoughts or ideas.

Answer 1

Your definition of "secure" is vague. You seem less interested in preventing data from being intercepted, and more interested in keeping people from submitting custom requests to your server. That isn't security, that is just good application design - your program shouldn't accept requests which cause the internal state to break.There is absolutely nothing you can do to prevent people from submitting whatever data they want to. The solution is to validate the data they're submitting server-side, not to try to prevent them from submitting the data client-side, which will always fail.

I switched to POST

You shouldn't bother; that has nothing to do with security. Use whichever HTTP verb is appropriate for the request. Are you querying information? Use a get request. Are you updating/inserting/deleting information? Use post.

say someone wants to look up someones information on my SQL server they'd just need to key in right information to my .php file associated

You should be authenticating all requests to make sure they have access to the data they're querying. SSL will help you perform the authentication securely.

when my website is loaded i have a 80 char hex key generated and saved in the session, and when im sending the ajax call i am also sending the challenge key

This isn't going to help. The entire premise of your question seems to be that the user has Firebug or a similar HTTP debugging tool installed. If they do, your session key is rendered useless.

Answer 2

See the answer by 'meagar'.

I'd like to mention:

By passing around an identifier in Session, you're doing what the Session is already doing. There's usually a cookie with a unique identifier similar to the one you're generating, which is telling your application, essentially, who that person is. This is how PHP sessions work, in general.

What you would need to do, in this case, is check that for a given request - POST or GET - that the particular user (whose unique user ID, or similar, is stored in the Session) has permission to add/change/delete/whatever with that particular request.

So for a "search" request, you would only return results that User X has permission to view. That way, you don't worry about what they send - if the user doesn't have permission to do something, the system knows not to let them do it.

Hence "you should be authenticating all requests".

Someone feel free to add to this.