Domanda:
I parametri URL delle richieste GET e POST su HTTPS sono sicuri?
ddyer
2020-06-26 05:10:25 UTC
view on stackexchange narkive permalink

È risaputo che le richieste GET con ? xx = yy argomenti incorporati possono essere modificate durante il transito e quindi non sono sicure.

Se cambio la richiesta in POST e utilizzo HTTPS, quindi i parametri sono nel corpo del messaggio, che è crittografato e quindi difficile da hackerare, corretto?

Altri due casi mi riguardano. Supponiamo che parametri di stile GET siano stati aggiunti a una richiesta POST: tali parametri verrebbero ignorati in modo affidabile?

Che ne dici di una sorta di attacco di downgrade della sicurezza? Se il manipolatore dell'URL forza il fallimento delle transazioni HTTPS, il client / server "utilmente" effettua il downgrade a HTTP, il che consentirebbe la manipolazione del corpo POST non crittografato.

Le richieste POST non sono più sicure delle richieste GET in transito.Perché vuoi che i parametri di query vengano ignorati?Puoi consultare le specifiche HTTP.
"È noto" - ** Citazione necessaria! **
La domanda viene fuori come se fosse documentata da qualche parte.Consiglio vivamente di comprendere meglio come funzionano i metodi HTTP e cosa fa TLS alla richiesta HTTP.Forse vederlo in azione usando WireShark.Lo dico dopo aver visto che la risposta di @ThoriumBR copre correttamente la domanda (più su come ottenere una migliore comprensione di ciò che sta accadendo).
@multithr3at3d Sono preoccupato per i parametri che vengono alterati durante il transito.Se utilizzo POST e SSL, diventa molto più difficile da fare, ma se MITM può aggiungere parametri? Xx = yy a un URL POST e non vengono ignorati, la crittografia potrebbe essere discutibile.
@ddyer Per quanto riguarda MitM, non c'è differenza tra i parametri POST body e GET.Entrambi sono protetti con HTTPS e non protetti senza.Ora ci sono 5 risposte che spiegano tanto, ma sembri determinato a discutere.Onestamente mi chiedo perché hai fatto questa domanda se non accetti la nostra risposta?
@ddyer La maggior parte delle tue risposte qui riguardano ciò che accade quando si ripiega erroneamente su HTTP a causa di problemi, reali o immaginari, con la connessione o il certificato HTTPS.È un problema reale o immaginario, ma non è quello che hai chiesto qui nella tua domanda.
Ho un caso reale di un https GET che è stato violato durante il trasporto.Sto solo cercando di evidenziare le sfumature in modo da poter capire quali contromisure sono disponibili e quanto efficaci posso aspettarmi che siano.
@ddyer Come ha detto il marchese di Lorne, sembri molto preoccupato per il fatto di tornare a HTTP.Ti consiglierei di porre una domanda specifica sulle tue preoccupazioni lì in modo che possiamo affrontarle direttamente.Se lo trovi utile, ho costruito una bozza della domanda per te in base ai tuoi commenti: (https://pastebin.com/WuKuVTRi, scade il 13/07/2020).Ho una risposta per te che sarei felice di fornirti non appena la domanda si pone, e non riguarda "mantieni meglio i tuoi certificati SSL".
@TheHansinator grazie, fatto.
Sette risposte:
#1
+53
ThoriumBR
2020-06-26 06:27:52 UTC
view on stackexchange narkive permalink

TL; DR: HTTPS fornisce la crittografia ed è l'unica cosa che protegge i parametri.

È risaputo che le richieste GET con? xx = yy argomenti incorporati possono essere modificati durante il trasporto e quindi non sono sicuri.

Se non si utilizza la crittografia, tutto è insicuro: HTTP, Telnet, FTP, TFTP, IRC, SNMP, SMTP, IMAP, POP3 , DNS, Gopher ...

Se cambio la richiesta in POST ...

... non cambia nulla.

e usa HTTPS ...

HTTPS cambia tutto.

Qualsiasi richiesta HTTP non protetta da TLS non è protetta. Non importa se usi GET, POST, PUT, se è un'intestazione personalizzata, nessuno cambia nulla.

Ad esempio, questa è una richiesta GET:

  GET / test? field1 = value1&field2 = value2 HTTP / 1.1Host: foo.examAccept: text / html  

E questa è una richiesta POST:

  POST / test HTTP / 1.1Host: foo.exampleContent-Type: application / x-www-form-urlencodedContent-Length: 27field1 = value1&field2 = value2  

Qual è la differenza? Sulla richiesta GET, i parametri sono sulla prima riga e sul POST, i parametri sono sull'ultima riga. Solo quello. Le ragioni tecniche dietro GET o POST non sono il punto qui.

Supponiamo che i parametri di stile GET siano stati aggiunti a una richiesta POST: quei parametri verrebbero ignorati in modo affidabile?

Dipende interamente dall'applicazione. Su PHP, ad esempio, se l'applicazione si aspetta $ username = $ _POST ['username'] , l'invio come parametro GET non cambia nulla, poiché l'applicazione riceverà il parametro POST.

Che dire di una sorta di attacco di downgrade della sicurezza? Se il manipolatore dell'URL impone il fallimento delle transazioni HTTPS, il client / server "utilmente" effettua il downgrade a HTTP, il che consentirebbe la manipolazione del corpo POST non crittografato.

Non facile per server configurati correttamente. Se usano l'intestazione HTTP Strict Transport Security, forza il client ad accedere al sito solo utilizzando HTTPS, anche se l'utente forza HTTP e la porta 80. Il browser aggiornerà utilmente a HTTPS, non viceversa.

Anche su server che non utilizzano intestazioni HSTS, se il primo accesso viene effettuato tramite HTTPS, non è banale eseguire il downgrade a HTTP. L'autore dell'attacco deve inviare un certificato contraffatto e il client deve accettare il certificato contraffatto affinché una connessione HTTPS possa essere reindirizzata a HTTP. Ma se l'attaccante ha avuto successo, di solito continuerà a utilizzare HTTPS poiché il client ha già accettato comunque il suo certificato falso.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/110265/discussion-on-answer-by-thoriumbr-are-url-parameters-of-get-and-post-requests-ov).
#2
+23
Ángel
2020-06-27 06:23:53 UTC
view on stackexchange narkive permalink

No, no, no.

HTTPS protegge l'intera richiesta HTTP. Il percorso dell'URL, i parametri, i cookie, le intestazioni http, il corpo ... L'unica cosa che non protegge (oltre ai parametri tcp come indirizzi ip e porte) è il nome host a cui ti stai connettendo, che è trapelato tramite SNI estensione (questo dovrebbe essere corretto con tls-esni, solo una bozza per ora)

Pertanto, quando si utilizza HTTPS, l'invio di parametri "sensibili" (come utente e password, o conto bancario per fatturare) in GET non è insicuro perché un utente malintenzionato potrebbe cambiarlo.

(e se non si utilizza HTTPS, è una cattiva idea anche con POST)

Tuttavia, è comunque problematico.

  • I parametri GET fanno parte dell'URL e compaiono nei log del server, nella cronologia del browser, nell'analisi del sito Web, nella stampa della pagina, nell'analisi antivirus della pagina ...
  • Le richieste GET sono definite come idempotenti . Riprovare una richiesta GET (anche automaticamente) non avrà effetti collaterali. Puoi immaginare cosa potrebbe accadere se la richiesta significasse "trasferire questo importo sul conto ###"
  • D'altra parte, POST non ha questo comportamento. Avrai sicuramente notato che il tuo browser ti avvisa prima di inviare nuovamente una richiesta POST, avvertendoti delle azioni innescate da tale potenziale ripetizione.
  • Avere determinati parametri tramite GET potrebbe aiutare con gli attacchi di riparazione della sessione (come caricare un url che ti registra con l'utente e la password dell'aggressore, prima di addebitare il "tuo" credito online)
  • In generale, è molto più facile che qualcuno carichi una pagina con alcuni parametri che tramite POST (ancora possibile utilizzando javascript, tuttavia, utilizza token anti-XSS).

Supponiamo che i parametri di stile GET siano stati aggiunti a una richiesta POST: questi parametri verrebbero ignorati in modo affidabile?

Dipende dal sito web. Possono accettare alcuni parametri solo come GET e altri solo come POST, ma anche accettarne alcuni come GET o POST. Se il parametro a con lo stesso nome viene fornito in entrambi i modi, probabilmente sceglierebbero quello POST, ma potrebbe essere configurato per utilizzare GET o anche l'errore.

Che ne dici di un qualche tipo dell'attacco al downgrade della sicurezza? Se il manipolatore dell'URL impone il fallimento delle transazioni HTTPS, il client / server esegue il downgrade "utilmente" a HTTP, il che consentirebbe la manipolazione del corpo del POST non crittografato.

Un client che ha eseguito automaticamente il downgrade una richiesta HTTPS a HTTP (che, come noti, può essere facilmente eseguita da un utente malintenzionato sulla rete) è completa e completamente non funzionante . Si prega di inviare un CVE per questo.

#3
+20
Pedro
2020-06-26 19:55:51 UTC
view on stackexchange narkive permalink

È risaputo che le richieste GET con? xx = yy argomenti incorporati possono essere alterate durante il transito e quindi non sono sicure.

Questo è generalmente un riferimento a situazioni in cui GET le richieste vengono registrate nei registri della cronologia, incluso il browser locale ed eventualmente il software o i proxy di ispezione del contenuto. Altrimenti non ci sono differenze funzionali nella sicurezza nell'utilizzo di HTTP GET e richieste POST su TLS.

Altri due casi mi riguardano. Supponiamo che i parametri di stile GET siano stati aggiunti a una richiesta POST: quei parametri verrebbero ignorati in modo affidabile?

Dipende interamente dal codice della tua applicazione.

Che ne dici di un qualche tipo dell'attacco al downgrade della sicurezza? Se il manipolatore dell'URL impone il fallimento delle transazioni HTTPS, il client / server esegue il downgrade "utilmente" a HTTP, il che consentirebbe di manipolare il corpo del POST non crittografato.

Puoi affrontare quelli sotto HTTP utilizzando Strict Transport Security (HSTS) facoltativamente con precaricamento . Questo indica ai browser di rifiutarsi di accedere a un determinato sito in HTTP ... entro un certo timeout. E c'è una richiesta iniziale che, a meno che tu non stia utilizzando preload , il browser deve sapere che HSTS è abilitato.

è indesiderabile che l'intero sito si oscuri se SSL fallisce.Il mantenimento di certificati SSL validi è di per sé un tapis roulant.Suppongo che non puoi averlo in entrambi i modi!
SSL non è così difficile in questi giorni.
@ddyer, è sufficiente installare [letsencrypt] (https://letsencrypt.org/) [certbot] (https://certbot.eff.org/instructions) (server fisici o virtualizzati) o [cert-manager] (https: // cert-manager.io/) (nuvole orchestrate) e lascia che si occupi delle cose.
Non c'è motivo oggi per non utilizzare TLS.Né le prestazioni né la disponibilità sono ragioni valide.Mi scuso per il disaccordo diretto, ma questi sono argomenti della vecchia scuola che non tengono l'acqua.I servizi TLS falliscono esattamente come quelli di testo normale.
Mi scuso anche @thoriumbr poiché ho appena realizzato che molto di ciò che ho scritto era sulla tua risposta.
Certamente l'uso di certbot è un buon inizio, ma il problema diventa mantenere in esecuzione certbot.Ci sono molti punti di possibile errore e la maggior parte di essi verrà scoperta solo quando il tuo sito diventa improvvisamente inaccessibile.Tutta questa danza sulla sicurezza è un compromesso tra rendere il tuo sito più sicuro e renderlo meno affidabile e / o più costoso da mantenere.
@ddyer _ "la maggior parte di essi verrà scoperta solo quando il tuo sito diventa improvvisamente inaccessibile" _ - Ho creato uno strumento di monitoraggio dei certificati per i miei certificati all'interno di Kubernetes.Se scadono entro 10 giorni ricevo un'e-mail.certbot dovrebbe rinnovarli un mese prima della scadenza, IIRC, quindi questo mi dà un ulteriore livello di protezione se qualcosa va storto.Con queste due cose impostate, i certificati SSL generalmente non sono il mio problema ora.
#4
+6
mentallurg
2020-06-26 09:28:35 UTC
view on stackexchange narkive permalink

Se vedi l'URL nel browser, non significa che l'URL viene inviato sulla rete in tale forma. In caso di HTTPS, un utente malintenzionato può vedere solo l'host di destinazione e la porta della richiesta. L'aggressore non può vedere niente di più come metodo, URL, intestazioni, corpo.

Se usi HTTPS, i tuoi dati non possono essere modificati durante il percorso verso l'host e la porta di destinazione. Questo vale anche per l'URL: non è visibile a nessuno e non può essere manipolato.

L'URL è visibile solo sul lato server, dopo che il server ha decrittato la tua richiesta.

Le transazioni HTTP non si verificano solo nei browser: i programmi eseguono richieste http invisibili all'utente, ma possono essere visualizzate e manipolate inserendo un uomo nel mezzo tra il server previsto e il client.
* ma possono essere visti e manipolati inserendo un uomo nel mezzo tra il server previsto e il client * - no.Se il client è implementato correttamente, richiede il certificato del server, verifica che sia valido.Quindi crittografa il traffico.MiM non è possibile.Ovviamente puoi manipolare la tua rete, DNS.Oppure puoi installare direttamente il certificato della MiM, se vuoi aiutarli a leggere il tuo traffico :) Ma per applicazioni che implementano correttamente TLS / SSL e che sono configurate correttamente (es. Nessun certificato di CA dannose nel trust store) MiMnon è possibile.
Tutto il traffico sul mio computer passa attraverso un portale, il router e il modem al mio ISP.Se controllo il portale e rilevo una richiesta DNS per il sito X (le richieste DNS non sono ancora crittografate!) Posso rispondere con il mio sito, che può fornire un certificato valido di qualche tipo, e quindi agire come MITM per l'attualeluogo.Come viene impedito questo?
@ddyer Un certificato valido può essere creato solo da una CA di cui il client si fida già.Quindi, a meno che tu non possa in qualche modo manipolare il dispositivo client facendogli fidare della tua CA MITM, non puoi generare un certificato valido.
@ddyer: Qualsiasi sistema operativo (Windows, LInux, MacOS, Android) dispone di certificati CA preinstallati.Se crei un certificato e provi a dire che sei Google e il certificato è stato rilasciato da Verisign o da un'altra CA attendibile, non sarà considerato attendibile, perché il dispositivo (e tutto il software su questo dispositivo) conosce il vero certificato di Verisign.Tali certificati CA di primo livello sono preinstallati su qualsiasi sistema operativo (Windows, Linux, Mac, Android).Ci vorranno molti sforzi per un utente malintenzionato per costringere l'utente ad accettare un certificato non attendibile.Ma questa è un'altra storia.Pubblica una domanda a riguardo e possiamo discutere :)
@mentallurg Registro "phishingrus.com" e ottengo un certificato SSL per questo.Tu provi a connetterti a goodguyrus.com, io controllo il DNS e invece ti do l'IP per il sito di phishing.Come fai a sapere che stai parlando al sito sbagliato con un certificato perfettamente valido - non hai alcuna conoscenza preliminare di come dovrebbe apparire quel certificato - tutto quello che sai è che è valido.O c'è qualcosa che mi manca?
@ddyer: 1) Chi ha emesso il certificato?Un utente ha preinstallato certificati CA di tali CA come Comodo, DigiCert, GeoTrust, GlobalSign, Thawte ecc. Indipendentemente da ciò che accade con DNS.Se l'emittente del certificato non è considerato attendibile dall'utente (non è installato nel truststore), il certificato non sarà attendibile e quindi la connessione TLS / SSL non verrà stabilita.2) Se vuoi presentare un certificato emesso da una CA fidata ma non appartenente a qualche altro sito, non puoi dimostrare di essere il proprietario perché non hai la chiave privata per esso.Anche in questo caso, non verrà stabilito alcun TLS / SSL.
@ddyer Un certificato SSL dice a quale nome di dominio è destinato.Quando fornisci il certificato sbagliato, il browser mostra una pagina di errore.Puoi verificarlo aggiungendo una riga al file hosts del tuo sistema per impostare l'IP di un sito uguale all'IP di un altro sito.
@boann se provo a connettermi a Google e ottengo un certificato che dice alfabeto (genitore di Google), sarebbe perfettamente normale.Non è possibile correlare i certificati che ricevo effettivamente con il sito a cui pensavo di connettermi.Tutto quello che so è che una CA di cui mi fido dice che le informazioni nel certificato sono valide, non che è il sito a cui pensavo di connettermi.
@ddyer, il compito della CA è garantire l'identità del sito.Questo è ciò che ti fidi di fare.Quindi, quando ricevi un certificato da quella CA che dice che è per esempio.com e stavi cercando di connetterti a esempio.com, sai che la connessione è valida.Se stavi tentando di connetterti a example.com ma ricevi un certificato dalla CA che dice che è per phishing.com, sai che c'è un problema e interrompi.Allo stesso modo, se ricevi un certificato che dice che è per esempio.com ma non è emesso dalla tua CA di fiducia, sai che c'è un problema e interrompi.
@ddyer Le CA che rilasciano accidentalmente certificati non validi sono tenuti a revocarli immediatamente.Le CA inaffidabili vengono eliminate dai browser.Il progetto [Certificate Transparency] di Google (https://www.certificate-transparency.org/) è uno sforzo per controllare e rilevare i certificati non validi.Se ricordo bene, Google Chrome rifiuta anche di accettare qualsiasi certificato per un dominio Google da una CA non Google, quindi il tuo esempio specifico non funzionerebbe lì.Allo stesso modo, poiché nel tuo caso d'uso hai un tuo client, puoi programmarlo per accettare solo un certificato specifico.
#5
+2
Boann
2020-06-28 01:37:12 UTC
view on stackexchange narkive permalink

Con HTTPS, l'intera richiesta HTTP passa attraverso la pipe SSL crittografata, quindi entrambi i parametri GET e POST, il percorso dell'URL, i cookie e tutte le altre parti della richiesta sono protetti da manomissioni MitM in transito.

Questo non può garantire che il server e il client siano senza compromessi, ma significa che non devi fidarti di ogni computer casuale tra i due.

Il nome host e il numero di porta sono osservabili da un MitM, ma non possono essere manomessi, se non interrompendo la connessione.

I tempi di traffico e le dimensioni (riempite) sono osservabili e queste informazioni potrebbero essere utilizzate da un osservatore motivato per dedurre cosa viene trasferito. Ad esempio, un file di grandi dimensioni potrebbe essere un video o una dimensione di file specifica corrisponde a un file specifico.

I sistemi non tornano automaticamente a HTTP se HTTPS non riesce; sarebbe catastrofico. Senza SSL, nulla è protetto dalla registrazione e / o modifica totale.

Il caso che mi interessa è quello in cui il client ha hackerato il proprio computer per inserire un MITM allo scopo di attaccare il server.
@ddyer SSL protegge solo i dati in transito.Non tenta di affermare il dominio sui computer alle due estremità.Non è possibile proteggere completamente un computer in casa di qualcun altro.È impossibile impedire a un utente sufficientemente motivato di inviare una richiesta modificata che desidera, creando un client personalizzato o modificando il proprio.SSL renderà tutto più frustrante, ma non impossibile.
è quello che pensavo anch'io.Non puoi fidarti di quei clienti!
#6
+1
fraxinus
2020-06-27 02:27:57 UTC
view on stackexchange narkive permalink

Le altre risposte sono valide per quanto riguarda SSL (si chiama TLS in questi giorni, ma chi se ne frega), hanno quasi bypassato

Supponiamo che i parametri di stile GET siano stati aggiunti a una richiesta POST - quei parametri sarebbero ignorato in modo affidabile?

No. Esistono persino framework di applicazioni che consentono un mix gratuito tra URL e parametri del corpo della richiesta in una richiesta POST.

In JavaEE, ad esempio, è necessario fare del lavoro extra per determinare se un parametro specificato è arrivato dall'URL o dal corpo della richiesta. E generalmente non interessa a nessuno.

Non importa nemmeno dal punto di vista della sicurezza: chiunque può passare un parametro URL al server può passare anche un parametro del corpo della richiesta. Se la connessione non è crittografata, un uomo nel mezzo può manipolarla come meglio crede.

Se la connessione è crittografata con SSL / TLS, viene crittografata nel suo insieme, prima che possa verificarsi qualsiasi interazione HTTP e rimane crittografato finché non viene chiuso.

L'unica cosa che un uomo nel mezzo può fare per una connessione correttamente crittografata è interromperla. (Bene, si può anche sfruttare qualche vulnerabilità di protocollo o implementazione, ma oggigiorno sono rari)

#7
+1
Matthew Steeples
2020-06-28 16:51:33 UTC
view on stackexchange narkive permalink

Oltre alle altre risposte, c'è un'altra dimensione di sicurezza da considerare, che ha a che fare con ciò che accade all'URL. Nessuna delle seguenti opzioni consente di intercettare o modificare i valori, indicare semplicemente dove potrebbero essere letti . Tutti questi si applicano anche a HTTP e HTTPS; la presenza di HTTPS non ne mitiga nessuno.

  1. Anche utilizzando HTTPS, l'URL completo viene trasmesso a tutti i server di terze parti che caricano componenti sulla pagina tramite il referer intestazione. Ciò significa che qualsiasi parametro GET potrebbe essere potenzialmente esposto a terze parti. Questo può essere mitigato impostando una Referr-Policy sulla tua richiesta.

  2. I server Web in genere registrano le richieste HTTP nel file system. Per impostazione predefinita, questi sono configurati per registrare l'URL che è stato inviato al server, il che significa che qualsiasi parametro GET potrebbe essere visibile nei tuoi log e disponibile a chiunque abbia accesso ad essi. Alcuni server proxy registrano anche gli URL che sono stati visitati (ma il fatto che un server proxy possa vedere il tuo traffico crittografato è un altro livello di fiducia del tutto).

  3. Il tuo browser potrebbe memorizzare nella cache un elenco di URL che hai visitato, che includerebbe anche i parametri GET.

Inoltre, alcuni proxy MitM che sono comuni nelle impostazioni aziendali (e interrompono la protezione TLS end-to-end con false CA affidabili) potrebbero registrare le richieste (come i server) e hanno meno probabilità di registrare l'intero corpo.è un requisito di conformità comune non inviare dati sensibili nell'URL anche quando la protezione https funziona in linea di principio.Soprattutto perché possono anche finire nei file dei segnalibri o potrebbero essere inviati a servizi abbreviati o cose come i controlli della reputazione.Per non parlare dell'usabilità degli URL che non sono facilmente leggibili.


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