Qual è la differenza tra HTTP-Get e HTTP-POST e perché HTTP-POST è più debole in termini di sicurezza

Question

Qualcuno può spiegare la differenza tra un HTTP-GET e HTTP-POST? E perché la gente dice che un HTTP-POST è più debole in termini di sicurezza?

Answer 1

In una richiesta HTTP GET, coppie chiave/valore sono specificati nella URL:

http://server/something?value1=foo&value2=bar.

In una richiesta POST HTTP, le coppie chiave/valore vengono inviate come parte della richiesta HTTP dopo le intestazioni. Per esempio:

 
POST /something HTTP/1.1 
Host: server 
Content-Length: 21 
Content-Type: application/x-www-form-urlencoded 

value1=foo&value2=bar 

E 'difficile da descrivere davvero uno come più o meno sicuro rispetto agli altri, ma i dati HTTP POST non è visibile nell'URL, e al momento della presentazione dei dati a un sito web, un HTTP POST di solito può può essere eseguito solo a seguito dell'interazione dell'utente (ad esempio facendo clic su un pulsante "Invia").

Ciò significa che un utente non può essere indotto a visitare un URL come http://server/update_profile?name=I_suck e i dati sensibili non sono esposti nell'URL.

È anche possibile utilizzare nonces e altri token anti-contraffazione con moduli html (che utilizzano POST) per impedire altre forme di falsi di richieste tra siti.

In generale, il POST deve essere utilizzato per le richieste che potenzialmente modificano lo stato sul server e GET deve essere utilizzato per le operazioni di sola lettura.

Answer 2

Non chiamerei POST più o meno sicuro di GET. Certo, i parametri vengono visualizzati come parte dell'URL quando si utilizza GET, quindi tutti i dati sensibili saranno immediatamente visibili all'utente. Tuttavia, è banale visualizzare e persino modificare qualsiasi parte della richiesta HTTP, quindi solo perché il POST non passa i dati attraverso l'URL può essere facilmente letto. A meno che tu non stia utilizzando HTTPS, GET e POST trasferiranno i dati in una forma facilmente accessibile.

Answer 3

Il GET method è pensato solo per il recupero dei dati e should not have any side-effects. Ma POST è pensato per quello scopo specifico: modificare i dati sul lato server.

Le richieste GET possono essere facilmente rinegoziate (vedere Cross-Site Request Forgery) semplicemente posizionando un'immagine su una pagina mentre la creazione di richieste POST non è così semplice (questo è anche un motivo per cui è necessario consentire solo le richieste POST autorizzate).

Answer 4

Il HTTP specification differenzia POST e GET in termini di loro intento:

GET è idempotente: è per l'ottenimento di una risorsa, senza cambiare nulla sul server. Di conseguenza, dovrebbe essere perfettamente sicuro reinviare una richiesta GET.

POST no: serve per aggiornare le informazioni sul server. Pertanto non si può presumere che sia sicuro inviare nuovamente la richiesta, motivo per cui la maggior parte dei browser richiede conferma quando si effettua il refresh su una richiesta POST.

In termini di sicurezza, nessuna differenza. POST è più oscuro, forse, ma è una cosa molto diversa. La sicurezza deve essere aggiunta a un altro livello, ad esempio SSL.

Answer 5

Alcune note su richieste GET:

1. richieste GET possono essere memorizzate nella cache
2. richieste GET rimangono nella cronologia del browser
3. richieste GET possono essere contrassegnate
4. richieste GET non dovrebbe mai essere utilizzato quando si tratta con dati sensibili
5. Le richieste GET hanno restrizioni di lunghezza
6. Le richieste GET devono essere utilizzate solo per Dati trieve

Alcune note sulle richieste POST:

1. richieste POST non vengono mai memorizzate nella cache
2. richieste POST non resterà nella storia del browser
3. richieste POST non possono essere segnalibro
4. richieste POST non hanno restrizioni sulla lunghezza dei dati

(Sour ce: W3 Schools)