Domanda:
I dati sensibili devono mai essere passati nella stringa di query?
C. Ross
2013-01-24 02:09:49 UTC
view on stackexchange narkive permalink

I dati sensibili devono mai essere trasmessi tramite la stringa di query invece della richiesta POST? Mi rendo conto che la stringa di query verrà crittografata, ma ci sono altri motivi per evitare di passare dati nella stringa di query, come la navigazione a spalla?

Re: la domanda SO a cui ti sei collegato: sì, l'URL è crittografato, ma un man-in-the-middle può spesso ancora dire quale sito web stai visitando in base all'IP (e ad altre metriche, come la quantità di dati trasferiti) . Se hai abilitato SNI (probabilmente il tuo browser lo fa), il dominio viene effettivamente inviato in testo normale prima dell'aggiornamento a SSL.
@TomMarthenal Ma la parte pertinente (per questa domanda) è che la * stringa di query * viene crittografata durante la trasmissione.
d'accordo, volevo solo buttarlo là fuori per chiunque altro leggesse.
Sei risposte:
#1
+45
Thomas Pornin
2013-01-24 02:20:44 UTC
view on stackexchange narkive permalink

Se la stringa di query è il target di un collegamento cliccabile dall'utente (al contrario di un URL utilizzato da alcuni Javascript), allora apparirà nella barra degli URL del browser quando la pagina corrispondente viene caricata. Presenta i seguenti problemi:

  • Verrà visualizzato l'URL. I surfisti spalla possono vederlo e imparare cose da quello (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 entrerà nella "cronologia", quindi verrà comunque scritto su disco; e potrebbe essere recuperato in seguito. Ad esempio, se il browser è Chrome, un utente malintenzionato dell'ora di pranzo deve semplicemente digitare Ctrl + H per aprire la "scheda cronologia" e ottenere tutte le stringhe di query.
  • Se la pagina viene stampata, l'URL verranno stampati, comprese eventuali informazioni sensibili.
  • Anche gli URL, comprese le stringhe di query, vengono spesso registrati sul server web e tali log potrebbero non essere protetti in modo appropriato.
  • Esistono limiti di dimensione per la stringa di query, che dipende dal browser e dal server (non c'è nulla di veramente standard qui, ma aspettati problemi oltre i 4 kB circa).

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

anche l'URL verrà stampato se l'utente va a stampare quella pagina.
Puoi anche aggiungere che se i segnalibri sono sincronizzati tra i dispositivi, le informazioni sensibili vanno avanti.
Anche gli URL con qstring vengono registrati frequentemente sul server web e tali log potrebbero non avere la migliore sicurezza applicata.
Anche la trasmissione di dati sensibili nei moduli non è un proiettile d'argento, nel caso in cui tu abbia un difetto XSS ovunque nel tuo sito che può raggiungere quel modulo.
#2
+32
goodguys_activate
2013-01-24 02:32:12 UTC
view on stackexchange narkive permalink

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 devono sempre essere inviati tramite "POST"

Modifica:

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

Bello! Ho dimenticato tutto sui log di IIS. Mi vergogno!
Grazie DavidStratton, anche se l'ho imparato da @drjimbob su questa domanda Sec.Se simile qui: http://security.stackexchange.com/a/12535/396
#3
+19
dr jimbob
2013-01-24 03:53:46 UTC
view on stackexchange narkive permalink

I dati sensibili devono essere trasmessi:

  1. Cookie solo HTTP protetti (sicuro significa solo SSL; e solo HTTP significa che javascript non può accedere) (ad esempio, un token casuale che lo identifica hai effettuato l'accesso) o
  2. variabili POST (su SSL).

Tre motivi:

  1. Il tuo computer per impostazione predefinita in genere registra la stringa di query (nella cronologia del browser),
  2. Il server web all'altra estremità registra per impostazione predefinita la stringa di query. Questo è negativo se diciamo che le password vengono passate in giro che il server web archivia in modo intelligente solo hash crittografici forti con chiave con sali casuali (ad esempio, bcrypt) per impedire che le password vengano ottenute inavvertitamente dagli aggressori. Ovviamente, non è difficile registrare le variabili POST se necessario, ma in genere non viene fatto.
  3. I dati sensibili dovrebbero generalmente essere passati solo quando un'azione di qualche tipo viene eseguita sulla base di tali dati sensibili; e nei casi in cui stai eseguendo una sorta di azione (come accedere; passare dati protetti da memorizzare / agire in un database) dovresti usare POST contro GET.

Generalmente le regole che impediscono la falsificazione di richieste tra siti (CSRF noto anche come XSRF) vengono attivati ​​solo per le richieste POST. GET è il metodo di richiesta HTTP previsto per il recupero dei dati da un server web che non ha altri effetti (oltre a cose benigne come popolare un file di registro che dice che questa pagina è stata richiesta); POST è il protocollo che consente a un utente di inviare dati per eseguire un'azione (ad esempio, ordinare qualcosa da un sito Web; trasferire denaro dal tuo 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 rispettivamente 1 e 2, ho menzionato entrambi in precedenza in una domanda in qualche modo simile.)

Stavo cercando quella risposta! In effetti ti do tutto il merito poiché quella risposta è dove ho appreso per prima cosa di questo problema di IIS.
Immagino che anche il passaggio di dati sensibili nelle intestazioni tramite SSL sarebbe sicuro?e forse dovrebbe essere aggiunto come n. 3.
#4
+4
David Stratton
2013-01-24 02:19:05 UTC
view on stackexchange narkive permalink

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

C'è sempre anche la possibilità che tu o un futuro sviluppatore non filtriate / disinfettate adeguatamente i dati e aprite la superficie di attacco ancora più ampia. Anche in un'app non sicura, se permetti accidentalmente un'iniezione, un utente malintenzionato dannoso e inietti script XSS e XSRF nel tuo database e usi la tua app non sensibile per attaccare gli altri, quindi è meglio giocare sul sicuro.

Il surf a spalla è un'altra preoccupazione legittima, a seconda dell'ambiente. Se la tua app verrà utilizzata in un luogo in cui è 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 sono tutte nelle stanze in cui è puntata la scrivania in modo che la navigazione a spalla non sia un problema, non preoccuparti. ma se non lo sai con certezza e non sai che sempre sarà così, è una preoccupazione.

#5
  0
xeranic
2020-02-21 13:12:06 UTC
view on stackexchange narkive permalink

Basato su OWASP REST Security Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html

Nelle richieste GET devono essere trasferiti dati sensibili in un HTTPHeader.

#6
-2
mcfedr
2020-09-03 16:00:50 UTC
view on stackexchange narkive permalink

Vale la pena notare che per molti versi le stringhe di query sono sicure quanto altre parti della richiesta

  • Le stringhe di query sono crittografate con HTTPS - senza un https MITM nessun altro lo vedrà fuori dal computer degli utenti

  • I dati del post sono visibili all'utente finale, negli strumenti per sviluppatori

  • Intestazioni sono visibili anche negli strumenti.

Non è raro trasmettere dati sensibili nelle stringhe di query

  • Quasi molto OAuth2 / SAML Il processo invierà un token di accesso dall'IdP all'SP in una stringa di query - questi token tendono ad essere di breve durata / monouso - poiché l'SP lo sostituirà utilizzando una richiesta POST da server a server.

  • I link per la reimpostazione della password nelle email avranno un token, ma normalmente vengono invalidati dopo l'uso.

  • I link di accesso Magic, usati da Slack e altri, hanno ancora token monouso nella stringa di query.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...