Насколько безопасный POST HTTP?

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

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

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

Сам по себе запрос POST небезопасен, потому что все данные «перемещаются» в виде обычного текста.

Для обеспечения безопасности необходим SSL.

Нет, использовать SSL.

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

POST - это открытый текст.

Безопасное соединение является обязательным.

Вот почему оно называется безопасным соединением.

Данные POST отправляются в виде обычного текста, если вы используете незашифрованное соединение HTTP. ЕСЛИ это достаточно безопасно, зависит от вашего использования (подсказка: это не так).

Если и сервер, и клиентская машина, и ВСЕ МАШИНЫ МЕЖДУ НИМИ являются частью управляемой, полностью доверенной сети, это может быть нормально.

Вне этих очень ограниченных обстоятельств (а иногда даже в их пределах) аутентификация с использованием обычного текста вызывает проблемы.

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

Если вы используете Digest Authentication , то SSL НЕ обязателен.

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

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

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

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

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

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

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

<бессовестная вилка> I есть сообщение в блоге , в котором подробно описывается, как выглядит HTTP-запрос и как GET-запрос сравнивается с POST-запросом. Для краткости 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

и 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.

Нет ... POST совсем не безопасен. SSL является ОБЯЗАТЕЛЬНЫМ.

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