I dati sensibili devono mai essere passati nella stringa di query?

Se la stringa di query è la destinazione di un link cliccabile dall'utente (al contrario di un URL utilizzato da alcuni Javascript), verrà visualizzata nella barra degli URL del browser quando viene caricata la pagina corrispondente. Ha i seguenti problemi:

• L'URL verrà visualizzato. I navigatori di spalla possono vederlo e imparare cose da questo (ad esempio una password).
• L'utente può aggiungerlo ai segnalibri. Questa può essere una caratteristica; ma significa anche che i dati vengono scritti sul disco.
• Allo stesso modo, l'URL arriverà nella "cronologia", quindi verrà comunque scritto sul disco; e potrebbe essere recuperato in seguito. Ad esempio, se il browser è Chrome, un utente malintenzionato deve semplicemente digitare Ctrl + H per aprire la "scheda Cronologia" e ottenere tutte le stringhe di query.
• Se la pagina viene stampata, l'URL verrà stampato, comprese eventuali informazioni sensibili.
• Anche gli URL, comprese le stringhe di query, vengono spesso registrati sul server Web e tali registri potrebbero non essere protetti in modo appropriato.
• Ci sono limiti di dimensioni sulla stringa di query, che dipendono dal browser e dal server (non c'è nulla di veramente standard qui, ma ci si aspetta un problema superiore a circa 4 kB).

Pertanto, se la stringa di query è una semplice destinazione di collegamento in una pagina HTML, i dati sensibili devono essere trasmessi come parte di un modulo POST, non codificato nell'URL stesso. Con i download programmatici (il modo AJAX), questo è molto meno di un problema.

Oltre alle altre risposte qui, la stringa di query viene anche memorizzata nei file di log del server Web, proxy HTTP e può essere vista anche se SSL viene utilizzato insieme a strumenti di monitoraggio SSL come Bluecoat.

No , i dati sensibili non dovrebbero essere inviati tramite un "GET" HTTP e devono sempre essere inviati tramite "POST"

Modifica:

Un motivo in più per utilizzare un POST è perché i GET sono più suscettibili agli attacchi CSRF

I dati sensibili devono essere passati:

1. Cookie sicuri solo HTTP (significato sicuro solo SSL e solo HTTP a cui javascript non può accedere) (ad esempio, un token casuale che identifica l'accesso) o
2. Variabili POST (su SSL).

Tre motivi:

1. Generalmente il tuo computer registra di solito la stringa di query (nella cronologia del browser),
2. Il server web all'altra estremità registra per impostazione predefinita la stringa di query. Questo è sbagliato se si dice che le password vengono passate attorno al fatto che il server web memorizza in modo intelligente solo hash crittografici rinforzati con chiave con sali casuali (ad esempio, bcrypt) per impedire che le password vengano inavvertitamente ottenute dagli autori di attacchi. Ovviamente, non è difficile registrare le variabili POST se è necessario, ma in genere non è fatto.
3. I dati sensibili devono essere generalmente trasmessi solo quando viene eseguita un'azione di qualche tipo sulla base di tali dati sensibili; e nei casi in cui si sta facendo un qualche tipo di azione (come l'accesso, passando i dati protetti da archiviare / agire in un database) si dovrebbe usare POST contro GET.

Generalmente le regole che impediscono le falsificazioni di richieste tra siti (CSRF noto anche come XSRF) vengono attivate solo per le richieste POST. GET è il metodo di richiesta HTTP previsto per il recupero di dati da un server Web che non ha altri effetti (oltre a cose benigne come la compilazione di un file di registro che dice che questa pagina è stata richiesta); POST è il protocollo che consente a un utente di inviare dati per eseguire alcune azioni (ad esempio, come ordinare qualcosa da un sito Web, trasferire denaro dal proprio conto bancario, modificare la password). Questo è un token CSRF casuale in genere è richiesto dalla maggior parte dei framework per le richieste GET, ma sarà spesso richiesto per le richieste POST.

(E mentre Thomas Pornin e makerofthings7 hanno toccato 1 e 2, rispettivamente ho menzionato entrambi precedentemente in una domanda simile .)

Se può essere evitato lo evito sempre. È solo un'altra superficie di attacco che dovrebbe essere lasciata chiusa a meno che non ci sia un bisogno legittimo per consentire il passaggio dei dati nella stringa della query.