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


351

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

Ответы:


453

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

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

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

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


4
А как насчет ссылок https на https ? Если я получаю изображение со стороннего сайта, используя https? Будет ли браузер отправлять всю строку запроса из моего предыдущего запроса на сторонний сервер?
Jus12

4
@ Jus12 да, да, это не имеет смысла, но так оно и задумано.
доктор зло

2
Тогда почему спецификация OAuth2 не рекомендует отправлять конфиденциальные данные в параметрах запроса (в URL)? Хотя рекомендуется всегда использовать TLS (HTTPS). Обратитесь к последнему пункту в tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16#section-4.3 CC @volka
gihanchanuka

@ dr.evil Не могли бы вы уточнить, в чем проблема, History caches in browsersили добавить ссылку на них?
ЖЖ

1
Чтобы завершить этот ответ свежей информацией: securitynewspaper.com/2016/08/01/… (хак с прокси-сервером позволяет перехватывать URL-адреса HTTPS)
Том

78

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

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


48

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

Причина в том, что строки запроса являются частью протокола 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будет использоваться.
  2. Теперь ваш клиент попытается подключиться к серверу с IP-адресом 124.21.12.31и попытается подключиться к порту 443 (порт службы SSL, а не порт HTTP по умолчанию 80).
  3. Теперь сервер example.comотправит свои сертификаты вашему клиенту.
  4. Ваш клиент проверит сертификаты и начнет обмениваться секретным ключом для вашего сеанса.
  5. После успешного установления безопасного соединения, только тогда параметры вашего запроса будут отправлены через безопасное соединение.

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


2
Но посмотрите ответ @dr. зло, строка карьера может оказаться в файлах журналов и кешах, поэтому она не может быть защищена на сервере.
Zaph

3
Привет, zaph, с точки зрения безопасности HTTPS, цель состоит в том, чтобы безопасно отправлять данные на сервер, и никто в середине не сможет их перехватить. Хотя это возможно и отвечает на вопрос, действительно трудно контролировать, что сервер делает потом. Вот почему я также упомянул, что это не правильный путь. Кроме того, вы никогда не должны посылать свой пароль от клиента. Вы должны всегда хешировать его на устройстве и отправлять хеш-значение на сервер.
Рухира Рандана

С точки зрения безопасности отправка конфиденциальной информации в строке карьера небезопасна, лучше всего отправлять ее по почте. Также пароль обычно хэшируется на сервере, а не на клиенте. Заявление «Вы никогда не должны посылать уры пароля от клиента» находится в конфликте с ответом: (e.g http://example.com/login?username=alice&password=12345).
Zaph

Хэширование @RuchiraRandana на клиенте не имеет смысла, потому что закрытый ключ легко извлекается из внешнего интерфейса.
Джеймс В.

@JamesW " тогда закрытый ключ легко извлекается из внешнего интерфейса " Какой ключ?
любопытный парень

28

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

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


27
Безопасность - это не только общение между браузером и сервером
JoeBloggs,

26

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

Есть несколько способов сломать эту безопасность.

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

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

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

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


3
«браузер по-прежнему будет взаимодействовать с прокси-сервером», что не совсем верно, ему необходимо предоставить браузеру действительный сертификат, который прокси-сервер может генерировать только в том случае, если он контролирует ЦС, которому доверяет браузер.
Питер


10

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

RFC HTTP 1.1 явно заявляет :

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

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


2
Это слово «должен» снова. Доверяете ли вы каждой версии каждого браузера свой пароль?
JoeBloggs

1
Как именно это связано с GET против POST? Будет ли «каждая версия каждого браузера» безопасным, если вы используете POST поверх HTTPS?
Арно

2
Кроме того, веб-страница HTTPS может извлекать внешнее изображение через HTTPS - в этом случае браузер ДОЛЖЕН включать заголовок referer и, таким образом, раскрывать ваш пароль ...
AviD

3
@Arnout: Пожалуйста, прочитайте этот RFC, который говорит вам, что НЕ ДОЛЖЕН означать: ietf.org/rfc/rfc2119.txt Это НЕ то же самое, что НЕ ДОЛЖНО, так что указанная вами часть не является действительно релевантной, и агенты браузера могут по-прежнему включать реферер в HTTP.
Энди

8

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


-4

Вы можете отправить пароль в виде хеш-параметра MD5 с добавлением соли. Сравните это на стороне сервера для аутентификации.


11
MD5 не подходит хэш-функция для паролей.
slawek

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

« не подходит хеш-функция для паролей » Еще лучше, чем отправлять пароли в виде
открытого текста
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.