Насколько безопасен HTTP POST? - PullRequest
64 голосов
/ 17 июня 2009

Достаточно ли безопасен POST для отправки учетных данных?

Или SSL-соединение должно ?

Ответы [ 14 ]

74 голосов
/ 17 июня 2009

SSL является обязательным. POST не более безопасен, чем GET, поскольку он также отправляет в незашифрованном виде. SSL будет охватывать всю связь HTTP и шифровать данные HTTP, передаваемые между клиентом и сервером.

40 голосов
/ 17 июня 2009

<shameless plug> У меня есть сообщение в блоге , в котором подробно описывается, как выглядит HTTP-запрос, и как запрос GET сравнивается с запросом POST. Ради краткости, ПОЛУЧИТЕ:

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

и 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 - просто новая строка)

Как видите, единственные отличия с точки зрения того, как формируется запрос *, заключается в том, что запрос POST использует слово POST, а данные формы отправляются в теле запроса против URI. Таким образом, использование HTTP POST является безопасностью по неизвестности. Если вы хотите защитить данные, вы должны использовать SSL.

* Обратите внимание, что есть другие различия .

8 голосов
/ 17 июня 2009

Это зависит от ваших обстоятельств, сколько будет стоить кому-то перехват учетных данных?

Если это просто вход на сайт программного обеспечения Q + A, тогда SSL может не понадобиться, если это сайт онлайн-банкинга или вы храните данные кредитной карты, тогда это так. Это бизнес, а не техническое решение.

6 голосов
/ 17 июня 2009

HTTP POST не зашифрован, он может быть перехвачен сетевым анализатором, прокси-сервером или просочиться в журналы сервера с настроенным уровнем ведения журнала. Да, POST лучше, чем GET, потому что данные POST не обычно регистрируются прокси или сервером, но они не безопасны . Чтобы защитить пароль или другие конфиденциальные данные, вы должны использовать SSL или зашифровать данные перед отправкой. Другой вариант - использовать дайджест-аутентификацию в браузере (см. RFC 2617). Помните, что (собственноручно) шифрования недостаточно для предотвращения повторных атак, вы должны объединить одноразовые и другие данные (например, область) перед шифрованием (см. RFC 2617, как это делается в Digest Auth).

5 голосов
/ 17 июня 2009

SSL является обязательным:)

Сообщение HTTP передается в виде простого текста. Например, загрузите и используйте Fiddler для просмотра HTTP-трафика. Вы можете легко увидеть весь пост там (или через монитор сетевого трафика, например, WireShark)

4 голосов
/ 17 июня 2009

Это не безопасно. POST может быть обнаружен так же легко, как GET.

2 голосов
/ 17 июня 2009

Самый безопасный способ - вообще не отправлять учетные данные.

Если вы используете Дайджест-аутентификацию , тогда SSL является НЕ обязательным.

(Примечание: я не имею в виду, что дайджест-аутентификация по HTTP всегда более безопасна, чем при использовании POST через HTTPS).

2 голосов
/ 17 июня 2009

Нет ... POST недостаточно безопасен. SSL ОБЯЗАТЕЛЬНО.

POST только эффективно скрывает параметры в строке запроса. Эти параметры все еще может быть выбран любым, кто просматривает трафик между браузером и конечной точкой.

1 голос
/ 17 июня 2009

Единственная разница между HTTP GET и HTTP POST заключается в способе кодирования данных. В обоих случаях оно отправляется в виде простого текста.

Чтобы обеспечить какую-либо защиту учетных данных, HTTPS является обязательным.

Вам также не нужен дорогой сертификат для предоставления HTTPS. Есть много провайдеров, которые будут выдавать очень простые сертификаты на сумму около 20 долларов США. Более дорогие из них включают проверку личности, что больше всего беспокоит сайты электронной торговли.

1 голос
/ 17 июня 2009

Нет, используйте SSL.

При POST значения по-прежнему отправляются в виде простого текста, если не используется SSL.

...