POSTing di moduli interdominio

145

Ho visto articoli e post dappertutto (incluso SO) su questo argomento e il commento prevalente è che la politica della stessa origine impedisce un modulo POST tra domini. L'unico posto in cui ho visto qualcuno suggerire che la politica sulla stessa origine non si applica ai post dei moduli, è qui .

Mi piacerebbe avere una risposta da una fonte più "ufficiale" o formale. Ad esempio, qualcuno conosce la RFC che affronta il modo in cui la stessa origine fa o non influisce su un modulo POST?

chiarimento : non sto chiedendo se un GET o POST può essere costruito e inviato a qualsiasi dominio. Sto chiedendo:

se Chrome, IE o Firefox consentiranno ai contenuti del dominio "Y" di inviare un POST al dominio "X"
se il server che riceve il POST vedrà effettivamente qualsiasi valore di modulo. Lo dico perché la maggior parte dei tester di record di discussione online afferma che il server ha ricevuto il post, ma i valori del modulo erano tutti vuoti / eliminati.
Quale documento ufficiale (es. RFC) spiega quale sia il comportamento previsto (indipendentemente da ciò che i browser hanno attualmente implementato).

Per inciso, se la stessa origine non influenza i POST della forma, allora rende un po 'più ovvio il motivo per cui sono necessari token anti-contraffazione. Dico "un po '" perché sembra troppo facile credere che un utente malintenzionato possa semplicemente emettere un HTTP GET per recuperare un modulo contenente il token anti-contraffazione e quindi creare un POST illecito che contenga lo stesso token. Commenti?

— Brent Arias
fonte

Sì, un utente malintenzionato potrebbe farlo ... con un normale browser web.

— Michael Hampton,

Forse non ci sono RFC per lo stesso motivo per cui non ci sono RFC che dicono: "non pubblicare la password sul tuo sito Web". Gli standard Web sono richiesti solo quando più parti devono lavorare insieme per ottenere qualcosa: la stessa politica di origine è più un insieme complesso di "migliori pratiche di sicurezza" che impediscono agli utenti di essere hackerati.

— Ciro Santilli 3 冠状病六四事件法轮功

@Ciro Ti preghiamo di dire esplicitamente. Le regole per il cross-posting su altri siti non influiscono su più parti. Non c'è bisogno del linguaggio nebbioso.

— Little Alien,

Risposte:

175

La stessa politica di origine è applicabile solo per i linguaggi di programmazione lato browser. Quindi, se si tenta di pubblicare su un server diverso rispetto al server di origine utilizzando JavaScript, entra in gioco la stessa politica di origine ma se si inserisce direttamente dal modulo, ad esempio l'azione punta a un server diverso come:

<form action="http://someotherserver.com">

e non ci sono javascript coinvolti nella pubblicazione del modulo, quindi la stessa politica di origine non è applicabile.

Vedi Wikipedia per ulteriori informazioni

— Suresh Kumar
fonte

Mi dispiace trascinare una vecchia domanda, cosa accadrebbe se l'azione fosse cambiata usando JS ma il modulo fosse pubblicato usando un pulsante? Ciò consentirebbe un post tra domini di successo?

— Chris,

AFAIK non dovrebbe essere un problema ma non l'ho provato da solo. Sarebbe interessante scoprirlo.

— Suresh Kumar,

Sono dello stesso pensiero. In realtà ero preoccupato per la sicurezza, alcuni JS / virus di terze parti stavano cambiando l'azione per pubblicare il modulo da qualche parte malevolo, ma mi sono reso conto che questo poteva essere fatto su qualsiasi modulo di ricezione pagamenti tra domini o meno e il risultato sarebbe stato lo stesso. Lezione qui davvero: controlla eventuali file JS di terze parti;)

— Chris

In breve: SÌ, è consentito il POST tra domini.

— Christian Davén,

-1 per: la stessa politica di origine non ha nulla a che fare con l'invio di richieste a un altro URL (protocollo o dominio o porta diversi), si tratta solo di limitare l'accesso ai dati di risposta (lettura) da un altro URL (e quindi impedire a javascript di aggiornare il documento con moduli che dispongono di token di sicurezza da altri URL).

— Mohsenme,

È possibile creare una richiesta GET o POST arbitraria e inviarla a qualsiasi server accessibile al browser delle vittime. Ciò include i dispositivi sulla rete locale, ad esempio stampanti e router.

Esistono molti modi per creare un exploit CSRF. Un semplice attacco CSRF basato su POST può essere inviato usando il .submit()metodo. Attacchi più complessi, come gli attacchi CSRF di upload di file su più siti , sfrutteranno l' uso CORS del comportamento xhr.withCredentals .

CSRF non viola la politica della stessa origine per JavaScrip t poiché lo SOP si occupa di JavaScript che legge la risposta del server a una richiesta dei client. Gli attacchi CSRF non si preoccupano della risposta, si preoccupano di un effetto collaterale o del cambiamento di stato prodotto dalla richiesta, come l'aggiunta di un utente amministrativo o l'esecuzione di codice arbitrario sul server.

Assicurati che le tue richieste siano protette utilizzando uno dei metodi descritti nel foglio informativo sulla prevenzione CSRF di OWASP . Per ulteriori informazioni su CSRF consultare la pagina OWASP su CSRF .

— Mikey
fonte

Ho aggiornato la mia domanda per chiarire. Inoltre, il link WordPress che hai fornito riguarda exploit avviati dall'interno della stessa origine X, piuttosto che avviati da Y tra domini ... quindi non è lo scenario giusto da quello che vedo.

— Brent Arias,

@Brent Arias sì, quello che stai descrivendo in 1 e 2 è esattamente uguale a quello che esegue un attacco CSRF, forse dovresti provare a eseguire uno degli exploit CSRF forniti e annusare il traffico. Ho aggiornato il mio post, dovresti leggere ogni link fornito perché risponderà a queste domande in modo accurato. Il punto di un attacco di "contraffazione di richieste tra siti" (CSRF) è che la richiesta proviene da un altro dominio, tutti gli exploit forniti soddisfano pienamente questo requisito fondamentale.

— Mikey,

La stessa politica di origine non ha nulla a che fare con l'invio di richieste a un altro URL (protocollo o dominio o porta diversi).

Si tratta solo di limitare l'accesso ai (leggere) dati di risposta da un altro URL. Quindi il codice JavaScript all'interno di una pagina può postare su un dominio arbitrario o inviare moduli all'interno di quella pagina ovunque (a meno che il modulo non sia in un iframe con URL diverso).

Ma ciò che rende inefficienti queste richieste POST è che queste richieste mancano di token antiforgery, quindi vengono ignorate dall'altro URL. Inoltre, se JavaScript tenta di ottenere tali token di sicurezza, inviando la richiesta AJAX all'URL della vittima, viene impedito l'accesso a tali dati dalla stessa politica di origine.

Un buon esempio: qui

E una buona documentazione di Mozilla: qui

— Mohsenme
fonte