Esiste una differenza tra GET e POST per la sicurezza delle applicazioni Web?

L'opzione 1 può introdurre comunque un numero di problemi non correlati alla sicurezza:

• L'URL risultante potrebbe essere memorizzato nella cache dal browser o inserito nei segnalibri, causando la reinvio degli utenti.
• L'URL risultante può essere condiviso dagli utenti, causando l'invio di terze parti.
• L'URL può essere inviato a il fornitore del browser , che potrebbe colpire il sito .

Ma questo riguarda la sicurezza e introduce alcuni rischi non presenti nell'opzione 2:

• L'URL con il suo parametro può finire nei registri del proxy di tutto il percorso, rivelando i tuoi dati.
• La tua funzione di decodifica è ora un vettore di attacco aggiuntivo. (Gestisce unicode correttamente? Ha delle restrizioni di lunghezza?)
• Potresti essere tentato di pensare alla tua stringa codificata come in qualche modo sicura, quando è solo sicurezza attraverso l'oscurità (e non molto oscurità), o forse più appropriatamente, teatro sicurezza .

Ciò detto però; altrimenti sono ampiamente equivalenti nella sicurezza che offrono . Entrambi inviano dati di testo in chiaro nell'intestazione HTTP, e base64 non è esattamente scienza missilistica (e puoi codificare in base64 la tua versione POST).

Nessuno dei due offre alcuna protezione significativa per i tuoi dati.

Se si tratta di informazioni che non vuoi che l'utente veda; perché lo stai inviando all'utente per cominciare? Considera l'architettura che stai utilizzando e verifica se esiste un modo per rimuovere completamente il rischio non gestendo tali informazioni sul lato client.

Quindi, per rispondere alla domanda: per quanto riguarda l'invio di dati - entrambi rivelano le stesse informazioni a un utente malintenzionato; scegli quale opzione è più appropriata per la situazione ( questo post del blog Treehouse può aiutarti ), ma non dovresti fare affidamento su entrambi i metodi per proteggere effettivamente qualsiasi cosa.

È facile effettuare richieste di cross-site GET includendo un semplice tag <img> in una pagina Web. Ad esempio, in una pagina da www.evilhacker.com , alcuni Javascript generano un lungo flusso di tag <img> con percorsi scelti da attaccanti, tutti puntati su www.targetbank.com - e il tuo browser includerà la banca cookie in tutte le richieste.

Questo solo significa che è meglio non supportare GET richieste che implicano qualsiasi modifica sul sito di destinazione. Come regola generale, le richieste di GET devono essere riservate alle operazioni per le quali gli attacchi di riproduzione non rappresentano un problema, ad es. in pratica, leggi gli accessi ai dati statici solo .

Usa il POST per inviare richieste che modificano i dati sul server.

Tramite la specifica HTTP , le richieste GET (ad esempio i parametri nell'URL) dovrebbero essere utilizzate solo per le richieste per recuperare (da cui il nome GET) ma non modificare i dati. Le richieste POST (parametri non visibili, ma ancora non crittografate nella richiesta HTTP) devono essere utilizzate ogni volta che la richiesta crea / aggiorna / modifica i dati che devono essere memorizzati nel database (diversi dai registri standard). Questo lo rende leggermente più difficile per gli hacker di fare falsi di richieste tra siti diversi e meno probabilità di inviare o archiviare accidentalmente informazioni segrete nei log della cronologia delle pagine web / server web.

La variabile pin è un segreto?

Ciò che stai facendo al momento sembra che potrebbe non essere sicuro a seconda del significato della variabile pin . Questo deve essere tenuto segreto da potenziali intercettatori o le persone che intercettano la spilla possono attaccare? In tal caso, utilizzare HTTPS (per la crittografia end-to-end sul livello di trasporto) per ogni richiesta con questi dati segreti. Il valore base-64 che hai usato sembrava essere 3000670269 (concesso di dover aggiungere due segni di uguale per renderlo una codifica b64 corretta).

Che cosa accadrebbe se un utente malintenzionato tentasse di utilizzare altri pin?

Diciamo il mio pin='300670269' , ma per testare il tuo sistema ho inviato MzAwMDY3MDI1OQ (per pin='3000670259' ). Ciò consentirebbe loro di penetrare efficacemente in un altro account utente? Se è così, per lo meno, dovresti fare qualcosa come avere una variabile POST in più come checksum=SHA256(pin+secret_server_side_string) dove secret_server_side_string è una lunga stringa casuale (es. Qualcosa come de10RRORX50UAUhx0dDIxJnzXKBAs68yjdWVz8QQ - 40 random superiore + inferiore + caratteri numerici ha lg (62) * 40 = 238 bit di entropia) e le tue applicazioni agiscono solo sul pin se il checksum corrisponde al pin. La tua applicazione dovrebbe generare il checksum (senza rivelare secret_server_side_string al client). Devi anche fare attenzione che l'applicazione esegua confronti di stringhe a tempo costante quando controlli il checksum con il pin, quindi l'applicazione non è vulnerabile agli attacchi di temporizzazione.

C'è un recente attacco interessante che è stato sfruttato per eludere le regole del firewall dell'applicazione Web, noto come " HTTP Parametro Pollution attack ". Spiegherò con un esempio come

POST /index.aspx?par=1&par=2 HTTP/1.1
User-Agent: Mozilla/5.0
Host: Host
Cookie: par=5; par=6
Content-Length: 19
par=3&par=4 

Per questo post, il comportamento dell'applicazione dipenderà dallo sviluppatore e mi piace per java.

1. javax.servlet.ServletRequestInterface (analisi diretta della stringa di query)
2. java.lang.StringgetParameter (java.lang.Stringname) Restituisce il valore di un parametro di richiesta come String, o null se il parametro non esiste
3. java.lang.String [] getParameterValues (java.lang.Stringname) Restituisce una matrice di String     oggetti contenenti tutti i valori del parametro di richiesta specificato     ha, o null se il parametro non esiste.

Oltre alla risposta di Bob, c'è un altro svantaggio di sicurezza quando si utilizzano le richieste GET con parametri sensibili.

L'URL, che include le informazioni sensibili, viene inviato a server Web di terze parti che ospitano risorse a cui fa riferimento la pagina HTML risultante.

Esempio:

Prima richiesta:

GET /someCode/pages/somePage.jsf?pin=MzAwMDY3MDI2OQ HTTP/1.0
Host: domain

Risposta a quella richiesta:

HTTP/1.0 OK
Content-type: text/html

<img src="http://thirdparty/hello.jpg" />

Il browser Web esegue il rendering dell'HTML e tenta di ottenere l'immagine come segue:

GET /hello.jpg HTTP/1.0
Host: thirdparty
Referer: http://domain/someCode/pages/somePage.jsf?pin=MzAwMDY3MDI2OQ

Questo può essere specialmente un problema quando l'HTML reso sulla pagina è controllato da un aggressore (in una certa misura, con l'html nella whitelist). Ad esempio, un servizio di posta Web che colloca la sessione nell'URL consentirebbe agli autori di attacchi di inviare un'immagine nel corpo HTML dell'email che punta al server / script web dell'attaccante. Quindi l'utente malintenzionato deve semplicemente seguire l'URL nell'intestazione Referer inviata dal browser Web della vittima durante il rendering dell'immagine. Questo tipo di vulnerabilità ha in effetti influenzato la posta Excite (stiamo parlando di cronologia qui :)) e alcuni altri servizi di webmail in passato.

Un altro fattore di sicurezza da considerare è che i log di accesso del server Web in genere acquisiscono gli URL richiesti, inclusi i parametri della stringa di query. Se non si desidera che la stringa di query venga registrata, potrebbe essere necessario ricorrere a una richiesta POST.

Ci sono, ovviamente, fattori non legati alla sicurezza da considerare quando si decide tra le richieste GET e POST, come il comportamento del browser quando si ricarica la pagina o quando la pagina viene richiamata tramite il pulsante Indietro del browser.

Sì. dovresti usare "post" per inserire, aggiornare, cancellare e "ottenere" come parametri di query

insert into table1 values postvalue1,postvalue2
select * from table1 where column1=getvalue1

parametrizza sia contro sql injection (o escape), poiché il client è autorizzato a inviare qualsiasi cosa, qualunque sia il codice javascript o html che scrivi.