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.

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.

È 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.

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.

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.

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)

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.