Безопасна ли строка запроса HTTPS?

Я создаю защищенный веб-интерфейс, который использует HTTPS; однако, если я разрешаю пользователям настраивать его (включая отправку пароля) с помощью строки запроса, это также будет безопасно или я должен заставить его выполнить через POST?

ОТВЕТЫ

Ответ 1

Да, это так. Но использование GET для конфиденциальных данных - это плохая идея по нескольким причинам:

  • В основном утечка HTTP-реферера (внешнее изображение на целевой странице может пропустить пароль [1])
  • Пароль будет храниться в журналах сервера (что явно плохо)
  • История кэшей в браузерах

Поэтому, несмотря на то, что Querystring защищен, не рекомендуется передавать конфиденциальные данные по запросу.

[1] Хотя мне нужно отметить, что RFC заявляет, что браузер не должен отправлять рефереры из HTTPS в HTTP. Но это не означает, что плохая сторонняя панель инструментов браузера или внешнее изображение/флеш с сайта HTTPS не пропустит его.

Ответ 2

С точки зрения "нюхать сетевой пакет" запрос GET безопасен, так как браузер сначала установит безопасное соединение, а затем отправит запрос, содержащий параметры GET. Но GET url будет храниться в истории браузера пользователя/автозаполнения, что не является хорошим местом для хранения, например. данные в пароле. Конечно, это применимо только в том случае, если вы используете более широкое определение "Webservice", которое может обращаться к сервису из браузера, если вы обращаетесь к нему только из своего пользовательского приложения, это не должно быть проблемой.

Поэтому рекомендуется использовать пост, по крайней мере, для диалоговых окон с паролями. Также, как указано в ссылке littlegeek, отправленный URL-адрес GET, скорее всего, будет записан в журналы вашего сервера.

Ответ 3

Да, ваши строки запроса будут зашифрованы.

Причиной этого является то, что строки запросов являются частью протокола HTTP, который является протоколом прикладного уровня, в то время как часть безопасности (SSL/TLS) происходит от транспортного уровня. Сначала устанавливается соединение SSL, а затем параметры запроса (принадлежащие протоколу HTTP) отправляются на сервер.

При установке SSL-соединения ваш клиент выполнит следующие шаги по порядку. Предположим, вы пытаетесь войти на сайт с именем example.com и хотите отправить свои учетные данные, используя параметры запроса. Ваш полный URL может выглядеть следующим образом:

https://example.com/login?username=alice&password=12345)
  1. Ваш клиент (например, браузер/мобильное приложение) сначала разрешит ваше доменное имя example.com в IP-адрес (124.21.12.31) используя запрос DNS. При запросе этой информации используется только информация, относящаяся к конкретному домену, т. example.com Будет использоваться только example.com.
  2. Теперь ваш клиент попытается подключиться к серверу с IP-адресом 124.21.12.31 и попытается подключиться к порту 443 (порт службы SSL не является портом HTTP по умолчанию 80).
  3. Теперь сервер example.com отправит свои сертификаты вашему клиенту.
  4. Ваш клиент проверит сертификаты и начнет обмениваться секретным ключом для вашего сеанса.
  5. После успешного установления безопасного соединения, только тогда параметры вашего запроса будут отправлены через безопасное соединение.

Поэтому вы не будете раскрывать конфиденциальные данные. Однако отправка учетных данных через сеанс HTTPS с использованием этого метода - не лучший способ. Вы должны пойти на другой подход.

Ответ 4

Да. Весь текст сеанса HTTPS обеспечивается SSL. Это включает в себя запрос и заголовки. В этом отношении POST и GET будут точно такими же.

Что касается безопасности вашего метода, нет реального способа сказать без надлежащего контроля.

Ответ 5

SSL сначала подключается к хосту, поэтому имя хоста и номер порта передаются как чистый текст. Когда хост отвечает и вызов преуспевает, клиент будет шифровать HTTP-запрос с фактическим URL (т.е. Что-нибудь после третьего косая черта) и отправить его на сервер.

Существует несколько способов разблокировать эту безопасность.

Можно настроить прокси-сервер как "человека посередине". По сути, браузер отправляет запрос на подключение к реальному серверу с прокси-сервером. Если прокси-сервер настроен таким образом, он будет подключаться через SSL к реальному серверу, но браузер все равно будет разговаривать с прокси-сервером. Поэтому, если злоумышленник может получить доступ к прокси-серверу, он может видеть все данные, которые проходят через него в ясном тексте.

Ваши запросы также будут отображаться в истории браузера. У пользователей может возникнуть соблазн добавить закладку на сайт. У некоторых пользователей установлены инструменты синхронизации закладок, поэтому пароль может оказаться на deli.ci.us или в другом месте.

Наконец, кто-то мог взломать ваш компьютер и установить регистратор клавиатуры или скребок экрана (и много вирусов типа Trojan Horse). Поскольку пароль отображается непосредственно на экране (в отличие от "*" в диалоговом окне пароля), это еще одно отверстие безопасности.

Заключение: когда дело доходит до безопасности, всегда полагайтесь на проторенный путь. Слишком много, что вы не знаете, не подумаете и что сломает вам шею.

Ответ 6

Я не согласен с утверждением о [...] утечке HTTP-реферера (внешнее изображение на целевой странице может привести к утечке пароля) в ответ на сообщение об уязвимости.

HTTP 1.1 RFC явно указывает:

Клиенты НЕ ДОЛЖНЫ включать ссылку поле заголовка в (незащищенном) HTTP-заголовке запросить, если ссылающаяся страница была передается с защищенным протоколом.

В любом случае, журналы сервера и история браузера являются более чем достаточными причинами, чтобы не помещать конфиденциальные данные в строку запроса.

Ответ 7

Да, пока никто не смотрит через плечо на монитор.

Ответ 8

Да, с момента установки HTTPS-соединение безопасно. Строка запроса (GET) как POST отправляется через SSL.

Ответ 9

Вы можете отправить пароль в качестве параметра MD5 с добавлением соли. Сравните его на стороне сервера для авторизации.