Block unwanted AJAX calls

Question

I did a test on Google Plus, turned on Firebug and inserted a post.
When parsing Firebug I recovered the URL it was executed via AJAX.
I copied the URL and ran it in the browser with the active session.

Turns out it returned an error:

Firefox cannot find the file in https://plus.google.com...

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 bypass the system:

function isHttpRequest() {
    if( @$_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest') {
        return true;
    }
    return false;
}

Answer 1

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

• Check how the request was made

You yourself have already researched and found how to do it, but the way you did it is not exactly the most appropriate, programmatically speaking, because you delete an error instead of dealing with it.

Also, you assume a marry specific for comparison which is not certain in view of the existence of several frameworks JS which, 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 origin

Lately here at Sopt much has been said about controlling the origins of an XHR. AJAX is not crossdomain, but can become because of a poorly configured server. Better to prevent than remedy:

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

• Tokens

The most recommended way is to attach to the request URL some random value that you, and only you have to validate.

This can be from an MD5 hash to a uniqid() stored in session despite what if you are EVEN interested in violating your Sesssions application can be captured. I don’t go into detail because I don’t know exactly how it’s done.

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

• SSL

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

Answer 2

start running the URL non-stop, making the site vulnerable

Your site is either vulnerable or has not yet identified any vulnerability, and more hits do not create vulnerabilities.

Ddos attacks cannot be avoided, only mitigated by access control techniques that have nothing to do with your application. It is who deals with your servers who should worry about it.

Vulnerabilities to XSS are also not created by many accesses, but for lack of cleaning data entered in the database and printed back on the screen.

It’s likely that you tried to use a post insertion token but at once, and the G+ system refused, an example of this in an application is:

html form.:

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

php form.:

<?php
    $post = [...]
    if(checar_se_token_foi_usado($post['token']))
        exit('adios');