Qual è il punto dell'intestazione X-Requested-With?

JQuery e altri framework aggiungono la seguente intestazione:

Richiesto X con: XMLHttpRequest

Perché è necessario? Perché un server dovrebbe voler trattare le richieste AJAX in modo diverso rispetto alle richieste normali?

AGGIORNAMENTO : Ho appena trovato un esempio di vita reale usando questa intestazione: https://core.spreedly.com/manual/payment-methods/adding-with-js . Se il processore di pagamento viene richiesto senza AJAX, al termine verrà reindirizzato al sito Web originale. Quando viene richiesto con AJAX, non viene eseguito alcun reindirizzamento.

Un buon motivo è per la sicurezza: questo può impedire gli attacchi CSRF perché questa intestazione non può essere aggiunta al dominio incrociato della richiesta AJAX senza il consenso del server tramite CORS .

Sono consentite solo le seguenti intestazioni tra domini:

• Accettare
• Accept-Language
• Content-Language
• Last-Event-ID
• Tipo di contenuto

eventuali altri causano l'emissione di una richiesta "pre-flight" nei browser supportati da CORS.

Senza CORS non è possibile aggiungere X-Requested-Withuna richiesta XHR tra domini.

Se il server sta verificando che questa intestazione sia presente, sa che la richiesta non è stata avviata dal dominio di un utente malintenzionato nel tentativo di effettuare una richiesta per conto dell'utente con JavaScript. Questo verifica anche che la richiesta non sia stata POSTATA da un normale modulo HTML, di cui è più difficile verificare che non sia interdominio senza l'uso di token. (Tuttavia, il controllo Origindell'intestazione potrebbe essere un'opzione nei browser supportati, anche se lascerai vulnerabili i vecchi browser .)

Nuovo bypass Flash scoperto

Potresti voler combinare questo con un token , perché Flash in esecuzione su Safari su OSX può impostare questa intestazione se c'è un passaggio di reindirizzamento . Sembra che abbia funzionato anche su Chrome , ma ora è riparato. Maggiori dettagli qui tra cui diverse versioni interessate.

OWASP consiglia di combinarlo con un controllo Origin e Referer :

Questa tecnica di difesa è discussa specificamente nella sezione 4.3 di Difese robuste per contraffazione di richieste su più siti. Tuttavia, i bypass di questa difesa usando Flash sono stati documentati già nel 2008 e di nuovo nel 2015 da Mathias Karlsson per sfruttare un difetto del CSRF in Vimeo. Tuttavia, riteniamo che l'attacco Flash non possa falsificare le intestazioni Origin o Referer, quindi controllandoli entrambi riteniamo che questa combinazione di controlli dovrebbe impedire gli attacchi CSRF di bypass Flash. (NOTA: se qualcuno può confermare o confutare questa convinzione, fatecelo sapere in modo da poter aggiornare questo articolo)

Tuttavia, per i motivi già discussi, controllare Origin può essere complicato.

Aggiornare

Ho scritto un post sul blog più approfondito su CORS, CSRF e X-Requested-With qui .

Assicurati di leggere la risposta di SilverlightFox. Evidenzia un motivo più importante.

Il motivo è principalmente che se conosci l'origine di una richiesta potresti volerla personalizzare un po '.

Ad esempio, supponiamo che tu abbia un sito Web che ha molte ricette. E usi un framework jQuery personalizzato per far scorrere le ricette in un contenitore in base a un link su cui fanno clic. Il link potrebbe esserewww.example.com/recipe/apple_pie

Ora normalmente restituisce una pagina intera, intestazione, piè di pagina, contenuto della ricetta e annunci. Ma se qualcuno sta navigando nel tuo sito Web alcune di queste parti sono già caricate. Quindi è possibile utilizzare un AJAX per ottenere la ricetta selezionata dall'utente, ma per risparmiare tempo e larghezza di banda non caricare l'intestazione / piè di pagina / annunci.

Ora puoi semplicemente scrivere un endpoint secondario per i dati come www.example.com/recipe_only/apple_pie ma è più difficile da mantenere e condividere con altre persone.

Ma è più semplice rilevare che si tratta di una richiesta Ajax che effettua la richiesta e quindi restituisce solo una parte dei dati. In questo modo l'utente spreca meno larghezza di banda e il sito appare più reattivo.

I framework aggiungono semplicemente l'intestazione perché alcuni potrebbero trovare utile tenere traccia di quali richieste sono ajax e quali no. Ma dipende interamente dallo sviluppatore utilizzare tali tecniche.

In realtà è un po 'simile all'intestazione Accept-Language. Un browser può richiedere un sito Web, mostrami una versione russa di questo sito Web senza dover inserire / ru / o simili nell'URL.

Alcuni framework utilizzano questa intestazione per rilevare le richieste xhr, ad esempio grails spring security utilizza questa intestazione per identificare la richiesta xhr e fornire una risposta json o html come risposta.

La maggior parte delle librerie Ajax (Prototype, JQuery e Dojo a partire dalla v2.1) includono un'intestazione X-Requested-With che indica che la richiesta è stata fatta da XMLHttpRequest invece di essere attivata facendo clic su un collegamento ipertestuale regolare o sul pulsante di invio del modulo.

Fonte: http://grails-plugins.github.io/grails-spring-security-core/guide/helperClasses.html