How can I better protect my php, jquery, ajax requests from malicious users

Question

I send a lot of data through jquerys getJSON method, an example of a function is

function doSomething(sid){
    if(sid){

    $.getJSON("ajax/ajaxDoSomething.php",{sid:""+sid+""}, function(data){
        //alert(data);
        if(data.success == true){
            $('#add_vote_div').html('vote received');
            $('#list_data_div').html(data.html);
        }
        else{
            $('#add_vote_div').html(data.message);
        }
    });
  } 
}`

The problem is that anyone can look at the source and see that the location of the php file its sending the GET data to, therefore you could just point your browser there and append data to the URL. I do checks on the data to make sure its the right data type, but i dont want users to be able to go to the url at all.

I thought maybe put all the ajax files behind the main document root which would work but jquery can't link to absolute paths like

$.getJSON("var/www/ajax/doSomething.php",{sid:""+sid+""}

(main document root is var/www/html/)

if they made a $.postJSON that would work better, but it doesn't exist, any ideas?

Answer 1

What you need to do is hit a few specific types of attacks. Even for very high-profile sites this is typically enough. And for a site that isn't one of the biggest sites around, these things should be more than enough to stop the script-kiddies.

Cross Site Request Forgery:

Essentially, this is what you are attempting to point out in your initial post. What this kind of attack entails is either, as you are pointing out, figuring out the URL that can enact some user-specific action and calling it directly. Or, and harder to protect against, is done by tricking a logged in user to click a link that leads to that user-specific action.

The first kind can be blocked by tagging each call with the session key and ensuring it is valid. However, this cannot prevent the second.

The good news is this attack can be stopped with a secret value that is part of the url, changes often, is remembered on the backend long enough to ensure it was properly called. We are talking about AJAX here, so the easiest way to do this is to on a full page load, you create a random number secret value. This same is true for traditional forms, bear that in mind and run the check on the old secret value before you create a new one. You hold this value in the session data and append it to all AJAX calls or form submits from the subsequent page. If they match, it is the same user. If not, you just ignore the request.

Each time the user loads a whole new page, create a new secret for that user. This means that only if the attacker IS the user, they will be able to find this value. Which means you've defeated this attack type.

Cross Site Scripting:

XSS attacks are different in that they are the opposite side of CSRF attacks, among other things. This one is easy. Just make sure that ALL data that comes from a user or the database is passed through some function that turns html characters into their entities, like htmlentities() in PHP, before you display it on your site. What this will do is prevent a user from using JavaScript to redirect users to action links or other malicious things. It will also prevent flash and other objects from being embedded into the page.

Unfortunately, it will also prevent the use of any HTML in comments or the body of articles. This can be skirted with either a VERY strict white list of tags, or some version of alternative code. (such as this site uses)

There really are no good ways to try to create a black list. I've tried. We've all tried. They don't work.

SQL Injection:

I won't go into great detail here, however, suffice to say the above attacks are nothing compared to the damage this can cause. Learn up on it.

Aside from this, there are just some guidelines you should follow. Such as NEVER falling into the trap of believing that the data you sent to javascript will come back how you expect. Assume the worst. This same thing goes for traditional forms. Data sent to the user should be treated, no matter how you encrypted it, as if it is all-new data from the user.

If you have an edit method for a forum post. Check on submit that the user has permission to edit that post. Make sure they are logged in. Make sure the secret matches. Make sure the data they entered is free of SQL injections.

Do these things, and you'll stop the vast majority of attacks.

Not all of them. The attack type that FireSheep uses will still get through, as will any attack like it that targets the users, and not your site. You can protect against FireSheep by using https and not http. But even this does nothing against the various user-targeting attacks. Such as stealing session cookies off their machine, or physical access to their machine.