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

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

Или это SSL-соединение?

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

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

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

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

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

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

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

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

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

Нет … POST недостаточно безопасен. SSL является ДОЛЖНЫ.

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

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

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

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

POST – открытый текст.

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

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

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

С помощью POST значения по-прежнему отображаются как обычный текст, если не используется SSL.

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

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

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

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

Вам нужен SSL, чтобы он был безопасным.

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

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

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

Пожалуйста, ознакомьтесь с этой замечательной статьей:

Защита от вредоносных запросов POST

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

Interesting Posts

Извлечь строку, соответствующую минимальному значению переменной по группе

Почему я получаю ошибку gcc «undefined reference», пытающуюся создать общие объекты?

неопределенная ссылка на `pthread_key_create ‘(ошибка компоновщика)

Как вычесть n дней с текущей даты в java?

Как заставить Windows 8 запускать 2 приложения Metro на каждом дисплее расширенного дисплея?

Строковая интерполяция в представлении «Бритва»?

Спящий режим по сравнению с потреблением энергии в режиме гибернации и безопасностью

Должен ли я быть обеспокоен, если мой хостинг-провайдер Git хранит пароли в открытом виде?

Инструмент для автоматического комбинирования большого числа сводных таблиц во многих больших листах Excel?

Упрощенная пирамида наseleniumия в ggplot2

Выбор нескольких строк в JTable

ServiceStack Запросить дизайн DTO

Можно ли вызвать абстрактный метод из конструктора в Java?

USB-накопитель постоянно отключается и снова подключается

Как заблокировать определенный HTTPS-трафик?

Давайте будем гением компьютера.