Perché i browser non bloccano i POST tra siti per impostazione predefinita?

In teoria il tuo suggerimento è perfettamente ragionevole. Se i browser bloccavano tutte le richieste POST di origine incrociata per impostazione predefinita e richiedeva una politica CORS per sbloccarle, molte delle vulnerabilità CSRF in quel caso scomparivano magicamente. Come sviluppatore, devi solo assicurarti di non modificare lo stato del server sulle richieste GET. Non sarebbero necessari token. Sarebbe bello.

Ma non è così che Internet è stato costruito nel corso della giornata, e non c'è modo di cambiarlo ora. Esistono molti usi legittimi delle richieste POST di origine incrociata. Se i browser cambiassero improvvisamente le regole a metà partita e proibirono questo, i siti che si basavano sulle vecchie regole avrebbero smesso di funzionare. Rompere i siti esistenti in questo modo è qualcosa che cerchiamo di evitare nella misura più ampia possibile. Purtroppo dobbiamo vivere con il nostro passato.

Quindi c'è un modo in cui potremmo ottimizzare il sistema per funzionare meglio senza rompere nulla? Un modo sarebbe quello di introdurre un nuovo verbo HTTP, chiamiamolo PEST, che funziona proprio come il POST solo che tutte le richieste PEST sono preflight e soggette alle politiche CORS. Questa è solo una sciocca proposta che ho inventato, ma mostra come possiamo sviluppare gli standard senza romperli.

Il problema non è il metodo di richiesta: CSRF potrebbe anche essere fatto con una richiesta GET. Il problema è invece che le informazioni di autenticazione come i cookie (di sessione) o l'intestazione Authorization vengono automaticamente incluse nella richiesta cross-site, rendendo così possibile CSRF. Pertanto, la mitigazione non sarebbe quella di vietare l'utilizzo di tali metodi all'interno di richieste cross-site, ma di non inviare tali informazioni di autenticazione.

Con i cookie esiste una proposta per una bandiera samesite che garantisce che il cookie non venga inviato all'interno richieste cross-site. Purtroppo la bandiera al momento è solo disponibile in Chrome , ma diventerà disponibile per Firefox con v60 maggio 2018 Inoltre, sarebbe stato molto meglio se questa restrizione fosse abilitata per impostazione predefinita e avrebbe dovuto essere esplicitamente modificata per essere meno sicura (come in CORS) invece di essere precaria per impostazione predefinita. Solo questo significherebbe un serio cambiamento nel comportamento attuale e probabilmente interromperà molte applicazioni esistenti.

In parte non sono d'accordo con Anders su

But that is not how the internet was built back in the day, and there is no way to change it now.

Gli sviluppatori dei principali browser hanno praticamente il potere di cambiare Internet e guidare gli sviluppatori web nella direzione che vogliono. L'eliminazione dei dati POST incrociati sarebbe possibile se fosse considerata una delle principali minacce. Ci sono esempi di tali progressi su altre cose, anche se non è né improvviso né veloce:

• Flash. Mentre in passato era visto come il futuro del Web, i principali browser hanno annunciato di non supportarlo in futuro e gli sviluppatori web si stanno adeguando.

• HTTPS è stato lentamente forzato dai browser, con piccoli passi verso l'avvertimento che il semplice HTTP è insicuro. Potremmo finalmente vedere un mondo in cui il semplice HTTP viene lentamente soffocato a morte.

Mi piacerebbe vederlo sviluppare per dare priorità alla sicurezza rispetto alla compatibilità più ampiamente. Ovviamente, un cambiamento così grande non sarebbe qualcosa da fare quasi allaperto, ma dando prima alternative e scoraggiandole . Il percorso per raggiungere questo potrebbe essere come questo:

1. Introduzione di un'intestazione di criterio Same-Origin per% richieste diPOST, che consente il consenso esplicito.
2. Inizia a mostrare un avviso di possibile problema di sicurezza in caso di cross-site POST senza il consenso.
3. I siti che hanno ancora bisogno di questa funzionalità si avviano lentamente per adattarsi, per eliminare l'avviso.
4. Dopo un lungo periodo di transizione, l'azione potrebbe essere modificata in modo più approssimativo.

Scoraggiare POST su un semplice HTTP è abbastanza vicino a scoraggiare il cross-site POST , entrambi contro gli standard. Questa è solo una perdita cosciente di compatibilità con le versioni precedenti, per aumentare la sicurezza.