Block unwanted AJAX calls

10

I tested Google Plus, turned on Firebug and inserted a post. When analyzing Firebug I retrieved the URL where it was executed via AJAX.
I copied the URL and ran it in the browser with the active session.

It turned out to be an error:

  

Firefox can not find the file at link ...

How to block an AJAX request so that only the system can execute it? I found this solution that identifies whether the request is via AJAX or not, but I do not know if it is enough, if somehow it is possible to circumvent the system:

function isHttpRequest() {
    if( @$_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest') {
        return true;
    }
    return false;
}
    
asked by anonymous 05.06.2014 / 13:59

2 answers

4

No system is foolproof. Score! What you can do is add sequential layers of protection.

  • Verify how the request was made

You've already researched and figured out how to do it, but the way you did it is not exactly the most appropriate, programmatically, because you suppress an error rather than deal with it.

Also, you assume a specific case for comparison, which is not certain since there are several JS frameworks that, assuming they send this header automatically, can suddenly, capitalize some letters differently, for example.

That said:

function isXmlHttpRequest() {

    $header = ( array_key_exists( 'HTTP_X_REQUESTED_WITH', $_SERVER ) ?
              $_SERVER['HTTP_X_REQUESTED_WITH'] : '' );

    return ( strcmp( $header, 'xmlhttprequest' ) == 0 );
}

if( ! isXmlHttpRequest() ) {

   // Acesso negado
}
  • Restrict XHR source

Lately here in SOpt a lot has been said about controlling the origins of an XHR. AJAX is not crossdomain, but may turn out to be because of a misconfigured server. Better safe than sorry:

header("Access-Control-Allow-Origin: http://www.domain.com");
  • Tokens

The most recommended way is to append to the request URL some random value which you, and only you can validate.

This can be from an MD5 hash of a uniqid () stored in session, despite what if you are EVEN interested in violating your application sessions can be captured. I do not go into details because I do not know exactly how this is done.

Or token "for real", which may even come from the same uniqid () but encrypted with a standard algorithm (things of RIJNDAEL 256 bits or more), stored in a database associated with the user ID, of short duration, being regenerated constantly.

  • SSL

SSL should come first, but whether for acquisitive availability or deployment complexity, I left it last. ;)

    
05.06.2014 / 19:03
3
  

start running the URL without stopping, making the site vulnerable

Your site is either vulnerable or has not yet been uncovered some vulnerability, and more hits do not create vulnerabilities.

DDoS attacks can not be avoided, only mitigated by access control techniques that have nothing to do with your application. It's the one who deals with your servers who should care about it.

XSS vulnerabilities are also not created by many accesses, but for lack of data cleansing inserted in the database and printed back on the screen.

It is likely that you tried to use a post insertion token more than once, and the G + system declined, an example of this in an application is:

form.html:

<input type="text" name="mensagem" />
<input type="hidden" name="token" value="<?php echo $token_de_um_so_acesso ?>" />
<button type="submit" value="enviar"/>

form.php:

<?php
    $post = [...]
    if(checar_se_token_foi_usado($post['token']))
        exit('adios');
    
05.06.2014 / 14:56