Qual è una tipica risposta dal server web per la richiesta POST?

La domanda sembrava riguardare il metodo di risposta HTTP scelto e il suo impatto sulla memorizzazione nella cache. Vedi "POST Caching" di seguito per la risposta a questa domanda.

Le spiegazioni dell'OP nei commenti suggeriscono che il team di sicurezza si occupa del browser ricordando i valori immessi nei moduli di campo, in modo tale che siano accessibili per l'utilizzo "back" o "autocomplete". Ciò è completamente estraneo alla risposta HTTP che il server sceglie di emettere; anche se viene utilizzato un reindirizzamento, ciò aumenta il numero di clic "di ritorno" necessari per tornare alle informazioni.

L' attributo di completamento automatico della forma HTML e l'attributo di completamento automatico dell'input HTML viene utilizzato per richiedere che il browser non ricordi i valori immessi. Tuttavia, queste sono richieste, non proibizioni. I browser possono fare tutto ciò che vogliono e sono stati conosciuti per ignorare o interpretare erroneamente questi tag e per escludere qualsiasi cosa trovino interessante dall'essere loro soggetti. Chrome, ad esempio, ha avuto questa cosa dove "off" non funziona ma "false" fa .

Quindi - ci sono cose che puoi fare per aiutarlo, ma non per controllarlo. E un 302 invece di un 200 non è uno di questi.

Memorizzazione nella cache POST

Un POST con una risposta di 200 non verrà memorizzato nella cache a meno che intestazioni HTTP aggiuntive nella risposta lo richiedano specificamente. Vedi E 'possibile memorizzare nella cache i metodi POST in HTTP? da StackOverflow; per citare la loro citazione di RFC 2616 :

9.5 POST

...

Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.

Il tuo team addetto alla sicurezza ha avuto una buona idea, ma non è riuscito a chiederti se gli architetti di HTTP sono riusciti a ottenere lo stesso pensiero prima.

In termini pratici, questo è perché il tuo browser ti avvisa quando tenti di ricaricare una pagina che è stata la risposta a un invio di moduli POST - ti dice che la richiesta verrà ritrasmessa al server, perché il browser non ha memorizzato nella cache la risposta originale.

Ho sentito parlare del problema e sì questo è qualcosa che puoi osservare in molte applicazioni web usando l'estensione di intestazione HTTP live. In effetti restituiscono 302 anziché 200 come codice di stato. Tuttavia, ci sono anche altri controlli che dovrebbero essere usati in combinazione, le intestazioni di controllo della cache HTTP .

Riguardo a SSL; Hai ragione quando ti riferisci al punto che non ci sono ulteriori rischi nell'osservare le credenziali in transito. Il problema che questa soluzione risolve è in una fase precedente: il browser stesso. C'è stato un momento in cui è possibile disconnettersi da un'applicazione Web e premere il pulsante di ritorno per accedere nuovamente. Ciò ha funzionato anche se l'applicazione Web ha distrutto la sessione, poiché la cache del browser conteneva le credenziali di autenticazione e veniva nuovamente autenticata. Pertanto, il problema che risolve è che nessuno che utilizza il browser può autenticare con credenziali precedentemente utilizzate e memorizzate nella cache.

Un reindirizzamento a un altro sito non fa dimenticare al browser i dati inseriti nel modulo. Se torni indietro nella storia, possono ancora essere inviati nuovamente. Cercare di "cancellare" il browser dai dati sensibili è probabilmente comunque discutibile, dal momento che l'utente malintenzionato dovrebbe trovarsi all'interno del browser per accedere a questi dati e in questo caso avrebbe potuto acquisire i dati già al momento dell'inserimento nella pagina o inviati al server, che probabilmente richiede meno sforzo.

Sono a conoscenza del fatto che la scoperta riportata dal team di sicurezza è valida. Consente di analizzare lo scenario che probabilmente hanno segnalato poiché anch'io l'ho visto nelle valutazioni delle applicazioni manuali.

Scenario 1: Prendiamo ad esempio la pagina di accesso di un'applicazione o, meglio ancora, un modulo di richiesta della carta di credito. Dopo che tutti i campi del modulo sono stati compilati e si è fatto clic sul pulsante "Invia", il client invia i dati sensibili in una richiesta POST al server. Se la risposta del server è "200 OK", il browser manterrà i dati POST nella memoria del browser consentendo attacchi di riproduzione. Come indicato in una precedente risposta, si potrebbe premere il pulsante "indietro", quindi "Avanti", quindi "Aggiorna", in cui il browser rinvia nuovamente i dati sensibili POST. Spesso riceverai un messaggio pop-up dal tuo browser che ti informa che sta per inviare nuovamente i dati precedentemente inviati.

Scenario 2: Gli stessi dati vengono inviati tramite una richiesta POST al server. Questa volta, il server risponde con un codice di stato di 300 tipi, probabilmente un reindirizzamento 302 che invia il client a qualunque sia la pagina successiva. Tuttavia, il browser client che ha ricevuto una risposta di tipo 300 NON conserva o memorizza nella cache i dati POST nella memoria del browser. NON È POSSIBILE ripetere il retro, inoltrare, aggiornare l'esperimento e sperare di vedere ripetuti i dati POST precedenti. Tutto dipende dalla risposta del server.

Puoi testarlo da solo se hai accesso a un proxy locale come Burp. Imposta il browser in modo che punti al tuo proxy. Accedi alla pagina Web vulnerabile. Compila i campi, premi Invia e guarda la richiesta inviata nel tuo strumento proxy. Dovresti vedere i vari campi del modulo contenenti dati sensibili nella sezione dati della richiesta POST. Supponendo che la risposta del server fosse un passaggio "200 OK" al passaggio successivo. Sul browser, premi il pulsante Indietro, quindi avanti, quindi aggiorna. Dovresti ricevere il messaggio popup dal tuo browser che ti avvisa che sta per inviare nuovamente i dati inviati in precedenza. Hit OK. Ora guarda l'ultima richiesta nel tuo strumento proxy. Avrà risentito la richiesta POST e gli stessi dati sensibili di prima. ORA, prova questo stesso esperimento su un sito Web che restituisce 302 reindirizzamenti ai dati POST. NON sarai in grado di ottenere il browser per riprodurre i dati pubblicati.

Quindi, qual è il rischio o la minaccia che potresti chiedere? Innanzitutto sono gli attacchi di replay. La tua più grande preoccupazione dovrebbe essere il malware. Il tuo secondo più grande vettore di minacce sarebbe un dispositivo condiviso. La preoccupazione è che sia il malware che una persona con accesso al dispositivo possano "riprodurre" la richiesta e quindi essere in grado di vedere i dati sensibili inviati nella richiesta POST. Il malware leggerà i dati direttamente dalla memoria del browser. Una persona dovrebbe usare uno strumento per vedere di nuovo la richiesta POST.

*** Alcuni avvertimenti:

* L'utilizzo di Autocomplete = off impedisce solo l'archiviazione dei dati nei contenitori di archiviazione dei campi modulo. È indipendente e non ha alcuna relazione con questo problema. Suggerirei comunque di garantire che tutti i campi modulo che accettano informazioni sensibili debbano avere il completamento automatico impostato su "off". Il malware spesso cerca e legge i dati dei campi dei moduli salvati in quanto solitamente contiene informazioni succose.

** L'uso di intestazioni di controllo della cache non ha alcuna rilevanza in questo problema, come per le pagine che sono memorizzate nella cache del disco (directory Internet temporanee). Ancora una volta, dovresti utilizzare le direttive di controllo della cache e impedire che i dati riservati vengano archiviati in chiaro sul tuo sistema.

*** Risposta "200 OK" sui dati POST in una richiesta JSON è un non-problema. È l'unico scenario fuori dalla mia testa che posso pensare a dove non è possibile eseguire l'attacco di replay quando il server risponde con un '200 OK'.

Spero che questo aiuti. Sono sicuro che non è elencato come una vulnerabilità di alto livello a causa delle limitazioni del vettore di attacco. Comunque, è solo uno degli innumerevoli strati della sicurezza!

Come hanno affermato altre risposte, rispondere a un POST con un reindirizzamento non farà nulla per impedire che il contenuto del modulo venga ricordato. Tuttavia, risolve un problema diverso: se il server risponde con un 200 "OK", l'utente fa clic su un collegamento sulla pagina e quindi fa clic sul pulsante Indietro, il browser può inviare nuovamente l'intero modulo in modalità silenziosa. Se il server ha risposto al POST con un reindirizzamento, questo non avverrà (il browser ricaricherà la pagina in cui è stato reindirizzato).