57
È un POST abbastanza sicuro da inviare le credenziali di accesso?Quanto è sicuro un POST HTTP?
Oppure una connessione SSL a deve?
A
risposta
69
SSL è un must. Il POST non è più sicuro di GET in quanto viene anche inviato in chiaro. SSL coprirà l'intera comunicazione HTTP e crittograferà l'invio di dati HTTP tra il client e il server.
+6
Un must? Per un forum di fan di My Little Pony? È necessario anche un terminale protetto da pernice bianca, crittografia quantistica e una linea dedicata testata? –
+12
@mgb: affittato? Mi stai prendendo in giro. Se non possiedi il rame fino in fondo, come puoi essere sicuro che sia sicuro ?! –
+108
Sì, perché le persone usano la stessa password per il forum dei fan di My Little Pony e il loro conto in banca. – erickson
5
SSL è un must :)
HTTP Post è trasmesso in formato testo. Per un esempio, scarica e usa Fiddler per guardare il traffico HTTP. Puoi facilmente vedere l'intero post lì (o tramite un monitor del traffico di rete come WireShark)
2
No ... POST non è abbastanza sicuro. SSL è un MUST.
POST solo in modo efficace nasconde i parametri nella stringa di query. Questi parametri possono ancora essere rilevati da chiunque guardi il traffico tra il browser e il punto finale.
4
Non è sicuro. Un POST può essere annusato con la stessa facilità di un GET.
8
A seconda delle circostanze, quanto costerebbe l'intercettazione delle credenziali a qualcuno?
Se si tratta solo di un accesso a un sito Q + A software, SSL potrebbe non essere necessario, se si tratta di un sito di banking online o se si memorizzano i dati delle carte di credito, allora lo è.
Questo è un business non una decisione tecnica.
+12
downvoted perché le persone riutilizzano le password. – Malfist
+1
Malfist: le persone riutilizzano sempre le password, ma se intercettate una password casuale, sapete dove altro usarla? – TheTXI
+2
se stai ascoltando il traffico per prendere le credenziali puoi vedere qualsiasi sito visitato dall'utente. SSL non nasconde l'indirizzo, solo i dati – Jim
1
POST è testo in chiaro.
Una connessione sicura è un must.
Ecco perché si chiama connessione sicura.
0
Una richiesta POST non è sicura perché tutti i dati "viaggiano" in testo normale.
È necessario SSL, per renderlo sicuro.
1
No, utilizzare SSL.
Con POST i valori vengono ancora inviati come testo normale a meno che non venga utilizzato SSL.
0
I dati POST vengono inviati in testo normale se si utilizza una connessione HTTP non crittografata. SE questo è abbastanza sicuro dipende dal tuo utilizzo (suggerimento: non lo è).
Se il server, la macchina client e TUTTE LE MACCHINE FRA LORO sono parte di una rete controllata e completamente affidabile, ciò potrebbe essere corretto.
Al di fuori di queste circostanze molto limitate (e talvolta anche all'interno di esse) l'autenticazione in testo semplice sta creando problemi.
1
L'unica differenza tra HTTP GET e HTTP POST è il modo in cui i dati sono codificati. In entrambi i casi viene inviato come testo normale.
Al fine di fornire qualsiasi tipo di protezione per le credenziali di accesso, HTTPS è un must.
Non è necessario un certificato costoso per fornire HTTPS.Ci sono molti fornitori che emetteranno certificati di base per circa $ 20 USD. Quelli più costosi includono la verifica dell'identità, che è più preoccupante per i siti di e-commerce.
+0
[Startcom] di Eddy Nigg (https://www.startcom.org/) emetterà un certificato per [gratuito] (https://www.startssl.com/?app=25#90). I loro certificati sono considerati affidabili dalla [maggior parte dei browser] (https://www.startssl.com/?app=40). Fanno pagare per la revoca perché è lì che risiede la maggior parte del costo. – jww
-3
Dipende da dove lo si sta utilizzando e dalla sicurezza di cui si ha realmente bisogno.
Non è possibile per qualcuno ottenere i dati POST inviati da casa a meno che non si utilizzi un proxy (TOR) o qualcuno stia toccando i fili.
Tuttavia, se si è preoccupati che qualcuno effettui l'accesso utilizzando una rete wireless non protetta, è importante che ssl sia importante.
Se sei una banca, non puoi nemmeno correre questo rischio. Se sei un tecnico con gli accessi per vedere i compiti, allora dovresti stare bene
+0
Ci scusiamo per -1, ma come potrebbe essere "nessun modo per qualcuno" di vedere i dati tra casa e un server? –
+0
Per favore, spiega. Questo post è stato realizzato su SO dal mio computer di casa. Anche supponendo che tu - Ilya - conoscessi i miei indirizzi IP (e quelli di SO), non saresti ancora in grado di intercettare i dati che ho postato su SO. Non puoi sapere che cosa è lì a meno che tu non possa intercettarlo. [E spesso, quando puoi intercettarlo, una connessione SSL non sarà d'aiuto.] Se ritieni che ciò sia un errore, provalo. – SamGoody
+1
@SamGoody Ciò dimostra la completa ignoranza su cosa sia un attacco man-in-the-middle e su come SSL lo previene. So che questo è un vecchio commento e potrebbe non riflettere più la tua comprensione attuale, se è il caso dovresti rimuoverlo ed eliminare questa risposta, poiché sono entrambi assolutamente sbagliati. – meagar
6
HTTP POST non è crittografato, può essere intercettato da uno sniffer di rete, da un proxy o trapelato nei registri del server con un personalizzato livello di registrazione. Sì, il POST è migliore di GET perché i dati POST non sono al solito registrati da un proxy o server, ma non è protetto. Per proteggere una password o altri dati riservati, è necessario utilizzare SSL o crittografare i dati prima del POST. Un'altra opzione sarebbe quella di utilizzare l'autenticazione del digest con il browser (vedere RFC 2617). Ricorda che la crittografia (home grown) non è sufficiente per prevenire attacchi di replay, devi concatenare un nonce e altri dati (ad esempio realm) prima di crittografare (vedi RFC 2617 per come è fatto in Auth Digest).
+0
+1 per notare le differenze nella registrazione –
2
Il modo più sicuro è di non inviare le credenziali.
Se si utilizza Digest Authentication, SSL è NON un must.
(NB: non sto insinuando che l'autenticazione del digest su HTTP sia sempre più sicura rispetto all'utilizzo del POST su HTTPS).
36
<shameless plug> Ho un blog post che descrive l'aspetto di una richiesta HTTP e il modo in cui una richiesta GET viene confrontata con una richiesta POST. Per l'amor di brevità, GET:
GET /?page=123 HTTP/1.1 CRLF
Host: jasonmbaker.wordpress.com CRLF
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 CRLF
Connection: close CRLF
e POST:
POST/HTTP/1.1 CRLF
Host: jasonmbaker.wordpress.com CRLF
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 CRLF
Connection: close CRLF
CRLF
page=123
(Il CRLF è solo un ritorno a capo)
Come si può vedere, le uniche differenze dal punto di vista di come una richiesta è formato * è che una richiesta POST utilizza la parola POST e i dati del modulo vengono inviati nel corpo della richiesta rispetto all'URI. Quindi, l'uso del POST HTTP è sicurezza per oscurità. Se si desidera proteggere i dati, è necessario utilizzare SSL.
* Si noti che ci are other differences.
0
Si prega di vedere questo grande articolo:
proteggere contro dannoso POST Richieste
vedi domanda precedente (http://stackoverflow.com/questions/1008539/how-secure-is -a-http-get--si-codifica URL quando-the-dati). –
Hey Matt, prima che tu lo chieda, sì, devi hash la password di accesso che hai memorizzato sul server. – erickson
Penso che sia una domanda seria. Dai un'occhiata alle altre domande di Matt e vedrai che probabilmente è un novizio, da qui la domanda apparentemente ingenua. – JohnFx