Jak Bezpieczny jest POST HTTP?

<shameless plug>mam post na blogu , który opisuje, jak wygląda żądanie HTTP i jak żądanie GET porównuje się do żądania POST. Dla zwięzłości, 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

I 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

(CRLF to tylko nowa linia)

Jak widać, jedyną różnicą z punktu widzenia tworzenia żądania* jest to, że żądanie POST używa słowa POST, a dane formularza są wysyłane w treści żądania vs URI. Tak więc korzystanie z HTTP POST jest zabezpieczeniem przez zaciemnienie. Jeśli chcesz chronić dane, powinieneś użyć SSL.

* zauważ, że tam są inne różnice .

To zależy od twoich okoliczności, ile kosztowałoby przechwycenie poświadczeń?

Jeśli jest to tylko logowanie do oprogramowania Q+A witryna wtedy SSL może nie być konieczne, jeśli jest to strona bankowości internetowej lub przechowujesz dane karty kredytowej, to jest.
To biznes, a nie decyzja techniczna.

HTTP POST nie jest szyfrowany, może zostać przechwycony przez sniffer sieciowy, przez proxy lub wyciekł w logach serwera z dostosowanym poziomem logowania. Tak, POST jest lepszy niż GET, ponieważ dane POST nie są zazwyczaj rejestrowane przez proxy lub serwer, ale nie są bezpieczne . Aby zabezpieczyć hasło lub inne poufne dane, musisz użyć protokołu SSL lub zaszyfrować dane przed opublikowaniem. Inną opcją byłoby użycie uwierzytelniania Digest w przeglądarce (patrz RFC 2617). Pamiętaj, że (home grown) szyfrowanie nie wystarczy, aby zapobiec atakom replay, musisz połączyć nonce i inne dane (np. realm) przed szyfrowaniem (zobacz RFC 2617, jak to się robi w Digest Auth).

SSL jest koniecznością:)

HTTP Post jest przesyłany w postaci zwykłego tekstu. Na przykład, Pobierz i użyj Fiddler do oglądania ruchu HTTP. Możesz łatwo zobaczyć tam cały post (lub za pomocą monitora ruchu sieciowego, takiego jak WireShark)

To nie jest bezpieczne. POST można wąchać równie łatwo, jak GET.

Nie...Poczta nie jest wystarczająco bezpieczna. SSL jest koniecznością.

POST tylko skutecznie ukrywa parametry w łańcuchu zapytania. Parametry te mogą być nadal odbierane przez każdego, kto patrzy na ruch między przeglądarką a punktem końcowym.

Najbezpieczniejszym sposobem jest nie wysyłanie poświadczeń w ogóle.

Jeśli używasz Digest Authentication , wtedy SSL jest , a nie koniecznością.

(NB: nie sugeruję, że uwierzytelnianie Digest przez HTTP jest zawsze bezpieczniejsze niż używanie POST przez HTTPS).

POST jest zwykłym tekstem.

Bezpieczne połączenie jest koniecznością.

Dlatego nazywa się to bezpiecznym połączeniem.

Nie, użyj SSL.

Z POST wartości są nadal przesyłane jako zwykły tekst, chyba że używany jest protokół SSL.

Jedyną różnicą między HTTP GET i HTTP POST jest sposób kodowania danych. W obu przypadkach jest wysyłany jako zwykły tekst.

Aby zapewnić jakiekolwiek zabezpieczenie danych logowania, HTTPS jest koniecznością.

Nie potrzebujesz drogiego certyfikatu, aby zapewnić HTTPS. Istnieje wielu dostawców, którzy wydadzą bardzo podstawowe certyfikaty za około 20 USD. Do droższych należą weryfikacja tożsamości, która bardziej dotyczy e-commerce miejsca.

Samo żądanie POST nie jest bezpieczne, ponieważ wszystkie dane są "podróżujące" w zwykłym tekście.

Potrzebujesz SSL, aby było bezpieczne.

Dane POST są wysyłane w postaci zwykłego tekstu, jeśli używasz niezaszyfrowanego połączenia HTTP. Jeśli jest to wystarczająco bezpieczne, zależy od użycia(wskazówka: nie jest).

Jeśli zarówno serwer, maszyna kliencka, jak i wszystkie maszyny między nimi są częścią kontrolowanej, w pełni zaufanej sieci, może to być w porządku.

Poza tymi bardzo ograniczonymi okolicznościami (a czasami nawet wewnątrz nich) uwierzytelnianie tekstowe prosi o kłopoty.

Zobacz ten świetny artykuł:

Ochrona przed złośliwymi żądaniami POST

Https://perishablepress.com/protect-post-requests/