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

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

вопрос задан 27.11.2008
John
18258 репутация

9 ответов


  • 391 рейтинг

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

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

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

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

    ответ дан dr. evil, с репутацией 16902, 27.11.2008
  • 63 рейтинг

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

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

    ответ дан VolkA, с репутацией 23070, 27.11.2008
  • 25 рейтинг

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

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

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

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

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

    ответ дан Ruchira Randana, с репутацией 2383, 28.03.2016
  • 24 рейтинг

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

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

    ответ дан shoosh, с репутацией 47457, 27.11.2008
  • 21 рейтинг

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

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

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

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

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

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

    ответ дан Aaron Digulla, с репутацией 240530, 27.11.2008
  • 10 рейтинг

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

    ответ дан Ali Afshar, с репутацией 32346, 27.11.2008
  • 9 рейтинг

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

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

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

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

    ответ дан Arnout, с репутацией 2620, 27.11.2008
  • 7 рейтинг

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

    ответ дан Drejc, с репутацией 9363, 27.11.2008
  • -3 рейтинг

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

    ответ дан Amareswar, с репутацией 1696, 8.11.2012