it-swarm.dev

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

Dovrebbero mai essere passati dati sensibili tramite stringa di query al contrario di POST? Mi rendo conto che la stringa di query verrà crittografata , ma ci sono altri motivi per evitare il passaggio di dati nella stringa di query, come la navigazione a spalla?

46
C. Ross

Se la stringa di query è la destinazione di un collegamento selezionabile 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 surfisti delle spalle possono vederlo e imparare cose da ciò (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 passerà alla "cronologia", quindi verrà comunque scritto su disco; e potrebbe essere recuperato in seguito. Ad esempio, se il browser è Chrome, un utente malintenzionato all'ora di pranzo deve solo digitare Ctrl + H per aprire la "scheda cronologia" e ottenere tutte le stringhe di query.
  • Se la pagina viene stampata, verrà stampato l'URL, comprese le informazioni sensibili.
  • Anche gli URL, incluse le stringhe di query, vengono spesso registrati sul server Web e tali registri potrebbero non essere protetti in modo appropriato.
  • Esistono limiti di dimensione sulla stringa di query, che dipendono dal browser e dal server (non esiste nulla di veramente standard qui, ma si aspettano problemi oltre i 4 KB circa).

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

41
Thomas Pornin

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

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

Modificare:

Un motivo in più per cui dovresti usare un POST è perché i GET sono più suscettibili a attacchi CSRF

32

I dati sensibili devono essere passati:

  1. Cookie protetti solo HTTP (sicuro che significa solo SSL; e solo HTTP che significa javascript non può accedere) (ad es. Un token casuale che identifica che hai effettuato l'accesso), oppure
  2. Variabili POST (su SSL).

Tre motivi:

  1. Per impostazione predefinita, il computer in genere registra la stringa di query (nella cronologia del browser),
  2. Il server web all'altra estremità registra automaticamente la stringa di query. Questo è un male se si dice che vengono passate delle password che il server web memorizza in modo intelligente solo hash crittografici potenziati da chiavi con sali casuali (ad esempio bcrypt) per impedire che le password vengano inavvertitamente ottenute dagli attaccanti. Ovviamente, non è difficile registrare POST se necessario, ma in genere non è fatto.
  3. I dati sensibili dovrebbero generalmente essere passati solo quando viene eseguita un'azione di qualche tipo basata su tali dati sensibili; e nei casi in cui si sta eseguendo una sorta di azione (come l'accesso; passaggio di dati sicuri su cui archiviare/agire in un database) è necessario utilizzare POST contro GET.

Generalmente le regole che impediscono falsi di richieste tra siti (CSRF noto anche come XSRF) vengono attivate solo per POST. GET è il metodo di richiesta HTTP previsto per il recupero di dati da un server Web che non ha altro effetto (oltre a cose benigne come la compilazione di un file di registro che dice che questa pagina è stata richiesta); POST è il protocollo per 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 spesso richiesto per POST richieste.

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

19
dr jimbob

Se può essere evitato, lo evito sempre. È solo un'altra superficie di attacco che dovrebbe essere lasciata chiusa a meno che non vi sia una legittima necessità per consentire il passaggio dei dati la stringa di query.

C'è sempre anche la possibilità che tu o un futuro sviluppatore non filtriate/disinfetti correttamente i dati e apriate la superficie di attacco ancora più ampia. Anche in un'app non sicura, se consenti accidentalmente un'iniezione, un utente malintenzionato e inietta script XSS e XSRF nel tuo DB e usi la tua app non sensibile per attaccare gli altri, quindi è meglio giocarla in sicurezza.

Il surf sulle spalle è un'altra preoccupazione legittima, a seconda dell'ambiente. Se la tua app verrà utilizzata in un luogo dove è possibile (una biblioteca, un cubicolo in cui qualcuno può guardare e un ufficio con una scrivania rivolta nella direzione sbagliata, ecc.) È una potenziale preoccupazione. Se le persone che utilizzano la tua app si trovano tutte nelle stanze in cui la scrivania è puntata in modo che il surf sulle spalle non sia un problema, non preoccuparti. ma se non lo sai con certezza e non sai che sarà sempre essere quello a proposito, è una preoccupazione.

4
David Stratton

Basato su OWASP REST Security Cheat Sheet https://owasp.org/www-project-cheat-sheets/cheatsheets/REST_Security_Cheat_Sheet

Nelle richieste GET i dati sensibili devono essere trasferiti in un'intestazione HTTP.

0
xeranic