GET o POST sono più sicuri dell'altro?

Quando si confronta un HTTP GET con un HTTP POST, quali sono le differenze dal punto di vista della sicurezza? Una delle scelte è intrinsecamente più sicura dell'altra? Se è così, perché?

Mi rendo conto che il POST non espone informazioni sull'URL, ma esiste un valore reale in questo o è solo la sicurezza attraverso l'oscurità? C'è mai un motivo per cui dovrei preferire il POST quando la sicurezza è un problema?

Modifica:
su HTTPS, i dati POST sono codificati, ma gli URL potrebbero essere sniffati da una terza parte? Inoltre, mi occupo di JSP; quando si utilizza JSP o un framework simile, sarebbe corretto affermare che la migliore pratica è quella di evitare l'inserimento di dati sensibili nel POST o GET e di utilizzare invece il codice lato server per gestire le informazioni sensibili?

Per quanto riguarda la sicurezza, sono intrinsecamente gli stessi. Mentre è vero che POST non espone informazioni tramite l'URL, espone altrettante informazioni come un GET nella comunicazione di rete effettiva tra client e server. Se è necessario passare informazioni sensibili, la prima linea di difesa sarebbe passarle usando Secure HTTP.

GET o query string post sono davvero utili per le informazioni necessarie per aggiungere un segnalibro a un elemento particolare o per aiutare a ottimizzare i motori di ricerca e indicizzare gli elementi.

Il POST è valido per i moduli standard utilizzati per inviare dati una tantum. Non userei GET per pubblicare moduli effettivi, se non in un modulo di ricerca in cui si desidera consentire all'utente di salvare la query in un segnalibro o qualcosa del genere.

La richiesta GET è leggermente meno sicura della richiesta POST. Nessuno dei due offre una vera "sicurezza" da solo; l'utilizzo di richieste POST non renderà magicamente sicuro il tuo sito Web da attacchi dannosi di un importo evidente. Tuttavia, l'utilizzo delle richieste GET può rendere insicura un'applicazione altrimenti sicura.

Il mantra che "non è necessario utilizzare le richieste GET per apportare modifiche" è ancora molto valido, ma ha poco a che fare con comportamenti dannosi . I moduli di accesso sono i più sensibili all'invio utilizzando il tipo di richiesta errato.

Cerca ragni e acceleratori web

Questa è la vera ragione per cui dovresti usare le richieste POST per cambiare i dati. I ragni di ricerca seguiranno tutti i collegamenti sul tuo sito Web, ma non invieranno moduli casuali che trovano.

Gli acceleratori Web sono peggiori degli spider di ricerca, poiché vengono eseguiti sul computer client e "fanno clic" su tutti i collegamenti nel contesto dell'utente connesso . Pertanto, un'applicazione che utilizza una richiesta GET per eliminare elementi, anche se richiede un amministratore, obbedirà felicemente agli ordini dell'acceleratore web (non dannoso!) Ed eliminerà tutto ciò che vede .

Vice attacco confuso

Un attacco delegato confuso (in cui il vice è il browser) è possibile indipendentemente dal fatto che si utilizzi una richiesta GET o POST .

Sui siti Web controllati dagli aggressori GET e POST sono ugualmente facili da inviare senza l'interazione dell'utente .

L'unico scenario in cui il POST è leggermente meno suscettibile è che molti siti Web che non sono sotto il controllo dell'aggressore (ad esempio un forum di terze parti) consentono l'incorporamento di immagini arbitrarie (consentendo all'aggressore di iniettare una richiesta GET arbitraria), ma impedisce a tutti modi per iniettare una richiesta POST arbitraria, sia automatica che manuale.

Si potrebbe obiettare che gli acceleratori web sono un esempio di attacco confuso ai vice, ma è solo una questione di definizione. Semmai, un malintenzionato malintenzionato non ha alcun controllo su questo, quindi non è certo un attacco , anche se il vice è confuso.

Registri proxy

È probabile che i server proxy registrino gli URL GET nella loro interezza, senza rimuovere la stringa di query. I parametri di richiesta POST non vengono normalmente registrati. È improbabile che i cookie vengano registrati in entrambi i casi. (esempio)

Questo è un argomento molto debole a favore del POST. In primo luogo, il traffico non crittografato può essere registrato nella sua interezza; un proxy dannoso ha già tutto ciò di cui ha bisogno. In secondo luogo, i parametri di richiesta hanno un uso limitato per un utente malintenzionato: ciò di cui hanno davvero bisogno sono i cookie, quindi se l'unica cosa che hanno sono i log proxy, è improbabile che siano in grado di attaccare un GET o un URL POST.

Esiste un'eccezione per le richieste di accesso: queste tendono a contenere la password dell'utente. Salvare questo nel registro proxy apre un vettore di attacco che è assente nel caso di POST. Tuttavia, l'accesso tramite HTTP semplice è intrinsecamente insicuro.

Cache proxy

I proxy di memorizzazione nella cache potrebbero conservare le risposte GET, ma non le risposte POST. Detto questo, le risposte GET possono essere rese non memorizzabili nella cache con meno sforzo rispetto alla conversione dell'URL in un gestore POST.

"Referer" HTTP

Se l'utente dovesse accedere a un sito Web di terze parti dalla pagina pubblicata in risposta a una richiesta GET, quel sito Web di terze parti vedrà tutti i parametri della richiesta GET.

Appartiene alla categoria di "rivela i parametri di richiesta a una terza parte", la cui gravità dipende da ciò che è presente in tali parametri. Le richieste POST sono naturalmente immuni a questo, tuttavia per sfruttare la richiesta GET un hacker dovrebbe inserire un link al proprio sito Web nella risposta del server.

Cronologia del browser

Questo è molto simile all'argomento "registri proxy": le richieste GET vengono archiviate nella cronologia del browser insieme ai loro parametri. L'attaccante può facilmente ottenerli se hanno accesso fisico alla macchina.

Azione di aggiornamento del browser

Il browser ritenterà una richiesta GET non appena l'utente preme "aggiorna". Potrebbe farlo quando si ripristinano le schede dopo l'arresto. Qualsiasi azione (diciamo, un pagamento) verrà quindi ripetuta senza preavviso.

Il browser non ritenterà una richiesta POST senza un avviso.

Questa è una buona ragione per usare solo le richieste POST per modificare i dati, ma non ha nulla a che fare con comportamenti dannosi e, quindi, sicurezza.

Quindi cosa dovrei fare?

• Utilizzare solo richieste POST per modificare i dati, principalmente per motivi non legati alla sicurezza.
• Utilizzare solo richieste POST per moduli di accesso; fare altrimenti introduce i vettori di attacco.
• Se il tuo sito esegue operazioni sensibili, hai davvero bisogno di qualcuno che sappia cosa stanno facendo, perché questo non può essere coperto in un'unica risposta. È necessario utilizzare HTTPS, HSTS, CSP, mitigare l'iniezione SQL, l'iniezione di script (XSS) , CSRF e una serie di altre cose che potrebbero essere specifiche della propria piattaforma (come la vulnerabilità dell'assegnazione di massa in vari framework: ASP.NET MVC , Ruby on Rails , ecc.). Non esiste una sola cosa che possa fare la differenza tra "sicuro" (non sfruttabile) e "non sicuro".

Su HTTPS, i dati POST sono codificati, ma gli URL possono essere sniffati da una terza parte?

No, non possono essere fiutati. Ma gli URL verranno archiviati nella cronologia del browser.

Sarebbe giusto dire che la migliore pratica è quella di evitare di inserire dati sensibili nel POST o GET del tutto e utilizzare invece il codice lato server per gestire le informazioni sensibili?

Dipende da quanto sia sensibile, o più specificamente, in che modo. Ovviamente il cliente lo vedrà. Chiunque abbia accesso fisico al computer del client lo vedrà. Il client può falsificarlo quando lo rispedisce. Se quelli contano allora sì, mantenere i dati sensibili sul server e non lasciarli andare.

Non hai maggiore sicurezza perché le variabili vengono inviate tramite HTTP POST rispetto a quelle che hai inviato con HTTP GET.

HTTP / 1.1 ci fornisce una serie di metodi per inviare una richiesta :

• OPZIONI
• OTTENERE
• TESTA
• INVIARE
• METTERE
• ELIMINA
• TRACCIA
• COLLEGARE

Supponiamo che tu abbia il seguente documento HTML usando GET:

<html>
<body>
<form action="http://example.com" method="get">
    User: <input type="text" name="username" /><br/>
    Password: <input type="password" name="password" /><br/>
    <input type="hidden" name="extra" value="lolcatz" />
    <input type="submit"/>
</form>
</body>
</html>

Cosa chiede il tuo browser? Chiede questo:

 GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Ora facciamo finta di aver cambiato quel metodo di richiesta in un POST:

 POST / HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Content-Length: 49
 Cache-Control: max-age=0
 Origin: null
 Content-Type: application/x-www-form-urlencoded
 Accept: application/xml,application/xhtml+xml,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

 username=swordfish&password=hunter2&extra=lolcatz

ENTRAMBE queste richieste HTTP sono:

• Non criptato
• Incluso in entrambi gli esempi
• Può essere riproposto e soggetto ad attacchi MITM.
• Facilmente riproducibile da terze parti e bot di script.

Molti browser non supportano metodi HTTP diversi da POST / GET.

Molti comportamenti dei browser memorizzano l'indirizzo della pagina, ma ciò non significa che puoi ignorare nessuno di questi altri problemi.

Quindi per essere specifici:

Uno è intrinsecamente più sicuro di un altro? Mi rendo conto che il POST non espone informazioni sull'URL ma esiste un valore reale in questo o è solo sicurezza attraverso l'oscurità? Qual è la migliore pratica qui?

Questo è corretto, perché il software che stai usando per parlare HTTP tende a memorizzare le variabili di richiesta con un metodo ma non un altro impedisce solo a qualcuno di guardare la cronologia del tuo browser o qualche altro attacco ingenuo di un bambino di 10 anni che pensa di capire h4x0r1ng o script che controllano l'archivio della cronologia. Se hai uno script in grado di controllare il tuo archivio della cronologia, potresti semplicemente averne uno che controlla il tuo traffico di rete, quindi tutta questa sicurezza attraverso l'oscurità sta solo fornendo oscurità agli script kiddie e alle fidanzate gelose.

Su https, i dati POST sono codificati, ma gli URL potrebbero essere sniffati da una terza parte?

Ecco come funziona SSL. Ricordi quelle due richieste che ho inviato sopra? Ecco come si presentano in SSL: (ho cambiato la pagina in https://encrypted.google.com/ come example.com non risponde su SSL).

POST su SSL

q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_o
9q1/?q$7yOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4$0sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ x?B?oO@&
Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r

OTTIENI su SSL

rV/O8ow1pc`?058/8OS_Qy/$7oSsU'qoo#vCbOO`vt?yFo_?EYif)
43`I/WOP_8oH0%3OqP_h/cBO&24?'?o_4`scooPSOVWYSV?H?pV!i
?78cU!_b5h'/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__
bb3D?05Dh/PrS6_/&5p@V f $)/xvxfgO'q@y&e&S0rB3D/Y_/fO?
_'woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt
_Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"'DxHwo//P
oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
tr'9/o_7too7q?c2Pv

(nota: ho convertito HEX in ASCII, alcuni di questi non dovrebbero ovviamente essere visualizzabili)

L'intera conversazione HTTP è crittografata, l'unica parte visibile della comunicazione è sul livello TCP / IP (ovvero l'indirizzo IP e le informazioni sulla porta di connessione).

Vorrei fare una dichiarazione audace qui. Il tuo sito Web non offre una sicurezza maggiore rispetto a un metodo HTTP di quanto non sia un altro, hacker e neofiti di tutto il mondo sanno esattamente come fare ciò che ho appena dimostrato qui. Se si desidera la sicurezza, utilizzare SSL. I browser tendono a memorizzare la cronologia, è consigliato da RFC2616 9.1.1 di NON utilizzare GET per eseguire un'azione, ma pensare che POST fornisca sicurezza è completamente sbagliato.

L'unica cosa a cui POST è una misura di sicurezza? Protezione dai tuoi ex gelosi sfogliando la cronologia del tuo browser. Questo è tutto. Il resto del mondo è registrato nel tuo account ridendo di te.

Per dimostrare ulteriormente perché POST non è sicuro, Facebook utilizza le richieste POST ovunque , quindi come possono esistere software come FireSheep ?

Nota che potresti essere attaccato con CSRF anche se usi HTTPS e il tuo sito non contiene vulnerabilità XSS . In breve, questo scenario di attacco presuppone che la vittima (l'utente del tuo sito o servizio) sia già loggata e abbia un cookie adeguato e quindi al browser della vittima viene richiesto di fare qualcosa con il tuo sito (presumibilmente sicuro). Se non si dispone di protezione contro CSRF, l'attaccante può comunque eseguire azioni con le credenziali delle vittime. L'aggressore non può vedere la risposta del server perché verrà trasferita nel browser della vittima, ma il danno è di solito già fatto a quel punto.

Non c'è sicurezza aggiuntiva.

I dati di post non vengono visualizzati nella cronologia e / o nei file di registro, ma se i dati devono essere protetti, è necessario SSL.
Altrimenti, chiunque annusa il filo può comunque leggere i tuoi dati.

Anche se POSTnon offre alcun reale vantaggio in termini di sicurezza rispetto a GET, per i moduli di accesso o qualsiasi altro modulo con informazioni relativamente sensibili, assicurati di utilizzare POSTcome:

1. Le informazioni POSTnon verranno salvate nella cronologia dell'utente.
2. Le informazioni sensibili (password, ecc.) Inviate nel modulo non saranno visibili in seguito nella barra dell'URL (utilizzando GET, saranno visibili nella cronologia e nella barra dell'URL).

Inoltre, GETha un limite teorico di dati. POSTnon lo fa.

Per informazioni sensibili reali, assicurati di utilizzare SSL( HTTPS)

Nessuno dei due GET e POST è intrinsecamente "più sicuro" dell'altro, proprio come nessuno dei fax e del telefono è "più sicuro" dell'altro. Vengono forniti i vari metodi HTTP in modo da poter scegliere quello più adatto al problema che si sta tentando di risolvere. OTTENERE è più appropriato per le query idempotenti mentre il POST è più appropriato per le query "di azione", ma è possibile sparare in piedi altrettanto facilmente con una qualsiasi di esse se non si capisce l'architettura di sicurezza per l'applicazione che si sta mantenendo.

Probabilmente è meglio se leggi il Capitolo 9: Definizioni dei metodi della RFC HTTP / 1.1 per avere un'idea generale di ciò che GET e POST erano originariamente previsti o cattivi.

La differenza tra GET e POST non dovrebbe essere vista in termini di sicurezza, ma piuttosto nelle loro intenzioni verso il server. GET non dovrebbe mai modificare i dati sul server, almeno se non nei registri, ma POST può creare nuove risorse.

I proxy piacevoli non memorizzano nella cache i dati POST, ma possono memorizzare nella cache i dati GET dall'URL, quindi si potrebbe dire che il POST dovrebbe essere più sicuro. Ma i dati POST sarebbero ancora disponibili per i proxy che non giocano bene.

Come menzionato in molte delle risposte, l'unica scommessa sicura è tramite SSL.

Ma assicurati che i metodi GET non eseguano il commit di nessuna modifica, come l'eliminazione delle righe del database, ecc.

La mia solita metodologia per la scelta è qualcosa di simile:

• OTTIENI per gli elementi che verranno recuperati successivamente dall'URL
  • Ad esempio, la ricerca dovrebbe essere GET in modo da poter eseguire search.php? S = XXX in seguito
• POST per gli articoli che verranno inviati
  • Questo è relativamente invisibile per GET e più difficile da inviare, ma i dati possono ancora essere inviati tramite cURL.

Questo non è legato alla sicurezza ma ... i browser non memorizzano nella cache le richieste POST .

Nessuno dei due conferisce magicamente sicurezza a una richiesta, tuttavia GET implica alcuni effetti collaterali che generalmente ne impediscono la sicurezza.

OTTIENI gli URL visualizzati nella cronologia del browser e nei log del server web. Per questo motivo, non dovrebbero mai essere utilizzati per cose come moduli di accesso e numeri di carte di credito.

Tuttavia, anche solo POSTARE quei dati non li rende sicuri. Per questo vuoi SSL. Sia GET che POST inviano i dati in testo normale via cavo quando utilizzati su HTTP.

Esistono anche altre buone ragioni per i dati POST, come la possibilità di inviare quantità illimitate di dati o nascondere parametri agli utenti occasionali.

Il rovescio della medaglia è che gli utenti non possono aggiungere i segnalibri ai risultati di una query inviata tramite POST. Per questo, hai bisogno di OTTENERE.

Considera questa situazione: un'API sciatta accetta richieste GET come:

http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1

In alcune impostazioni, quando si richiede questo URL e se si verifica un errore / avviso relativo alla richiesta, l'intera riga viene registrata nel file di registro. Peggio ancora: se si dimentica di disabilitare i messaggi di errore nel server di produzione, queste informazioni vengono visualizzate semplicemente nel browser! Ora hai appena dato la tua chiave API a tutti.

Sfortunatamente, ci sono API reali che funzionano in questo modo.

Non mi piacerebbe l'idea di avere alcune informazioni sensibili nei registri o di visualizzarle nel browser. POST e GET non sono gli stessi. Utilizzare ciascuno dove appropriato.

1. SICUREZZA come sicurezza dei dati IN TRANSITO: nessuna differenza tra POST e GET.

2. SICUREZZA come sicurezza dei dati SUL COMPUTER: POST è più sicuro (nessuna cronologia URL)

Il concetto di sicurezza non ha senso se non si definisce ciò che si desidera proteggere.

Se vuoi essere sicuro contro la cronologia del browser memorizzata, alcuni tipi di registrazione e le persone che guardano i tuoi URL, POST è più sicuro.

Se vuoi essere sicuro contro qualcuno che annusa la tua attività di rete, allora non c'è differenza.

Molte persone adottano una convenzione (citata da Ross) secondo cui GET richiede solo il recupero dei dati e non modifica alcun dato sul server e le richieste POST vengono utilizzate per tutte le modifiche ai dati. Anche se uno non è più intrinsecamente sicuro rispetto l'altro, se si fa seguire questa convenzione, è possibile applicare la logica della sicurezza trasversale (ad esempio, solo le persone con account possono modificare i dati, i posti in modo non autenticati vengono rifiutati).

È più difficile modificare una richiesta POST (richiede uno sforzo maggiore rispetto alla modifica della stringa di query). Modifica: in altre parole, è solo sicurezza per oscurità, e a malapena.

Non sto per ripetere tutte le altre risposte, ma c'è un aspetto che non ho ancora visto menzionato: è la storia della scomparsa dei dati. Non so dove trovarlo, ma ...

Fondamentalmente si tratta di un'applicazione web che misteriosamente ogni poche notti ha perso tutti i suoi dati e nessuno sapeva perché. L'ispezione dei log in seguito ha rivelato che il sito è stato trovato da Google o da un altro ragno arbitrario, che OTTENGONO felicemente (leggi: OTTENUTO) tutti i collegamenti trovati sul sito, incluso "elimina questa voce" e "sei sicuro?" collegamenti.

In realtà - una parte di questo è stata menzionata. Questa è la storia dietro "non modificare i dati su GET ma solo su POST". I crawler seguiranno felicemente GET, mai POST. Anche robots.txt non aiuta a non comportarsi male con i crawler.

Dovresti anche essere consapevole del fatto che se i tuoi siti contengono link ad altri siti esterni che non controlli utilizzando GET inserirai quei dati nell'intestazione del refeerer sui siti esterni quando premono i link sul tuo sito. Quindi il trasferimento dei dati di accesso tramite i metodi GET è SEMPRE un grosso problema. Poiché ciò potrebbe esporre le credenziali di accesso per un facile accesso semplicemente controllando i registri o cercando in Google Analytics (o simili).

RFC7231:

"Gli URI devono essere condivisi, non protetti, anche quando identificano risorse protette. Gli URI vengono spesso visualizzati sui display, aggiunti ai modelli quando viene stampata una pagina e memorizzati in una varietà di elenchi di segnalibri non protetti. Non è quindi saggio includere informazioni all'interno di un URI sensibili, identificabili personalmente o che potrebbero essere divulgate.

Gli autori dei servizi dovrebbero evitare i moduli basati su GET per l'invio di dati sensibili poiché tali dati verranno inseriti nella destinazione richiesta. Molti server, proxy e agenti utente esistenti registrano o visualizzano la destinazione richiesta in luoghi in cui potrebbe essere visibile a terzi. Tali servizi dovrebbero invece utilizzare l'invio di moduli basati su POST. "

Questo RFC afferma chiaramente che i dati sensibili non devono essere inviati utilizzando GET. A causa di questa osservazione, alcuni implementatori potrebbero non gestire i dati ottenuti dalla parte della query di una richiesta GET con la stessa cura. Sto lavorando su un protocollo che garantisce l'integrità dei dati. Secondo queste specifiche non dovrei garantire l'integrità dei dati GET (cosa che farò perché nessuno aderisce a queste specifiche)

Come in precedenza alcune persone hanno detto, HTTPS offre sicurezza.

Tuttavia, POST è un po 'più sicuro di GET perché GET potrebbe essere memorizzato nella cronologia.

Ma ancora di più, purtroppo, a volte l'elezione di POST o GET non dipende dallo sviluppatore. Ad esempio, un hyperlink viene sempre inviato da GET (a meno che non venga trasformato in un modulo di posta utilizzando javascript).

OTTENERE è visibile a chiunque (anche quello sulla tua spalla ora) e viene salvato nella cache, quindi è meno sicuro dell'uso di posta, btw post senza qualche routine di crittografia non è sicuro, per un po 'di sicurezza devi usare SSL ( https)

Uno dei motivi per cui POST è peggio per la sicurezza è che GET è registrato per impostazione predefinita, i parametri e tutti i dati sono quasi universalmente registrati dal tuo server web.

Il POST è l' opposto , non è quasi universalmente registrato , il che rende molto difficile individuare l'attività dell'attaccante.

Non compro l'argomento "è troppo grande", non è un motivo per non registrare nulla , almeno 1 KB, farebbe molto per le persone a identificare gli attaccanti che lavorano via in un punto di ingresso debole fino a quando non si apre, quindi POST lo fa un doppio dis-servizio, consentendo a qualsiasi back-door basato su HTTP di passare silenziosamente quantità illimitate di dati.

La differenza è che GET invia i dati aperti e POST nascosti (nell'intestazione http).

Quindi ottenere è meglio per i dati non sicuri, come le stringhe di query in Google. I dati di autenticazione non devono mai essere inviati tramite GET, quindi utilizzare POST qui. Ovviamente l'intero tema è un po 'più complicato. Se vuoi leggere di più, leggi questo articolo (in tedesco).

Recentemente è stato pubblicato un attacco che consente a man in the middle di rivelare il corpo della richiesta di richieste HTTPS compresse. Poiché le intestazioni e l'URL della richiesta non sono compressi da HTTP, le richieste GET sono meglio protette da questo particolare attacco.

Esistono modalità in cui anche le richieste GET sono vulnerabili, SPDY comprime le intestazioni delle richieste, TLS fornisce anche una compressione facoltativa (utilizzata raramente). In questi scenari l'attacco è più facile da prevenire (i fornitori di browser hanno già fornito correzioni). La compressione a livello HTTP è una funzionalità più fondamentale, è improbabile che i fornitori la disabilitino.

È solo un esempio che mostra uno scenario in cui GET è più sicuro di POST, ma non penso che sarebbe una buona idea scegliere GET su POST da questo motivo di attacco. L'attacco è piuttosto sofisticato e richiede prerequisiti non banali (l'attaccante deve essere in grado di controllare parte del contenuto della richiesta). È meglio disabilitare la compressione HTTP negli scenari in cui l'attacco sarebbe dannoso.

Dichiarazione di non responsabilità: i seguenti punti sono applicabili solo per le chiamate API e non per gli URL dei siti Web.

Sicurezza in rete : è necessario utilizzare HTTPS. GET e POST sono ugualmente sicuri in questo caso.

Cronologia del browser : per applicazioni front-end come Angular JS, React JS ecc. Le chiamate API sono chiamate AJAX effettuate dal front-end. Questi non diventano parte della cronologia del browser. Quindi, POST e GET sono ugualmente sicuri.

Registri lato server : con l'utilizzo del set di scrittura del mascheramento dei dati e del formato dei registri di accesso è possibile nascondere tutti o solo i dati sensibili dall'URL della richiesta.

Visibilità dei dati nella console del browser: per qualcuno con intenti maliziosi, è quasi lo stesso sforzo per visualizzare i dati POST tanto quanto GET.

Quindi, con le giuste pratiche di registrazione, l'API GET è sicura come l'API POST. Seguire POST ovunque, impone definizioni API scadenti e dovrebbe essere evitato.

Post è il più sicuro insieme a SSL installato perché è trasmesso nel corpo del messaggio.

Ma tutti questi metodi sono insicuri perché il protocollo a 7 bit che usa sotto è hackerabile con scappamento. Anche attraverso un firewall per applicazioni Web di livello 4.

Nemmeno i socket sono garantiti ... Anche se in alcuni modi è più sicuro.

Questo è un vecchio post, ma vorrei obiettare ad alcune delle risposte. Se stai trasferendo dati sensibili, ti consigliamo di utilizzare SSL. Se si utilizza SSL con un parametro GET (ad es.? Userid = 123), i dati verranno inviati in testo normale! Se invii utilizzando un POST, i valori vengono inseriti nel corpo crittografato del messaggio e pertanto non sono leggibili dalla maggior parte degli attacchi MITM.

La grande distinzione è dove vengono trasmessi i dati. Ha senso solo che se i dati sono inseriti in un URL, NON POSSONO essere crittografati altrimenti non saresti in grado di indirizzare al server perché solo tu potresti leggere l'URL. Ecco come funziona un GET.

In breve, è possibile trasmettere in modo sicuro i dati in un POST su SSL, ma non è possibile farlo con un GET, utilizzando SSL o meno.

Anche POST accetta richieste GET. Supponiamo di avere un modulo con input come user.name e user.passwd, che dovrebbero supportare nome utente e password. Se aggiungiamo semplicemente un? User.name = "my user & user.passwd =" my password ", la richiesta sarà accettata" bypassando la pagina di accesso ".

Una soluzione per questo è implementare i filtri (filtri java come e) sul lato server e rilevare che nessuna query su stringa viene passata come argomento GET.