Безопасна ли строка запроса HTTPS?
https://stackoverflow.com/questions/323200
-
11-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я создаю безопасный веб-API, который использует HTTPS;однако, если я разрешу пользователям настраивать его (включая отправку пароля) с использованием строки запроса, будет ли это также безопасно или я должен принудительно выполнить это через POST?
Решение
Да, это так. Но использовать GET для конфиденциальных данных - плохая идея по нескольким причинам:
- В основном утечка HTTP-реферера (внешнее изображение на целевой странице может привести к утечке пароля [1]).
- Пароль будет сохранен в журналах сервера (что, очевидно, плохо).
- Кэширование истории в браузерах
Поэтому, даже несмотря на то, что строка запроса защищена, не рекомендуется передавать конфиденциальные данные через строку запроса.
[1] Хотя я должен отметить, что в RFC указано, что браузер не должен отправлять рефереры с HTTPS на HTTP.Но это не означает, что плохая панель инструментов стороннего браузера или внешнее изображение / flash с сайта HTTPS не приведет к утечке информации.
Другие советы
От & nbsp; нюхать сетевой пакет " с точки зрения GET-запроса является безопасным, поскольку браузер сначала устанавливает безопасное соединение, а затем отправляет запрос, содержащий параметры GET. Но URL-адреса GET будут храниться в истории / автозаполнении браузера пользователя, что не очень удобно для хранения, например. данные паролей. Конечно, это применимо только в том случае, если вы используете более широкий «Веб-сервис». определение, которое может получить доступ к службе из браузера, если вы обращаетесь к ней только из своего пользовательского приложения, это не должно быть проблемой.
Поэтому предпочтительнее использовать post хотя бы для диалогов с паролями. Также, как указано в ссылке, Littlegeek опубликовал URL GET, более вероятно, будет записан в журналы вашего сервера.
Да , строки вашего запроса будут зашифрованы.
Причина в том, что строки запросов являются частью протокола HTTP, который является протоколом прикладного уровня, в то время как часть безопасности (SSL / TLS) происходит от транспортного уровня. Сначала устанавливается SSL-соединение, а затем параметры запроса (принадлежащие протоколу HTTP) отправляются на сервер.
При установке SSL-соединения ваш клиент выполнит следующие шаги по порядку. Предположим, вы пытаетесь войти на сайт с именем example.com и хотите отправить свои учетные данные, используя параметры запроса. Ваш полный URL может выглядеть следующим образом:
https://example.com/login?username=alice&password=12345)
example.com в IP-адрес (124.21.12.31) , используя запрос DNS. При запросе этой информации используется только информация, относящаяся к конкретному домену, то есть будет использоваться только example.com . 124.21.12.31 и попытается подключиться к порту 443 (порт службы SSL, а не порт HTTP по умолчанию 80). example.com отправит свои сертификаты вашему клиенту. Поэтому вы не будете раскрывать конфиденциальные данные. Однако отправка учетных данных через сеанс HTTPS с использованием этого метода - не лучший способ. Вы должны пойти по другому пути.
ДА.Весь текст сеанса HTTPS защищен с помощью протокола SSL.Это включает в себя запрос и заголовки.В этом отношении POST и GET были бы точно такими же.
Что касается безопасности вашего метода, то нет реального способа сказать об этом без надлежащей проверки.
SSL сначала подключается к хосту, поэтому имя хоста и номер порта передаются в виде открытого текста. Когда хост отвечает и вызов успешно завершается, клиент зашифровывает HTTP-запрос фактическим URL-адресом (т. Е. Что угодно после третьего слеша) и отправляет его на сервер.
Есть несколько способов нарушить эту защиту.
Можно настроить прокси-сервер так, чтобы он действовал как «человек посередине». По сути, браузер отправляет запрос на подключение к реальному серверу прокси. Если прокси-сервер настроен таким образом, он будет подключаться через SSL к реальному серверу, но браузер по-прежнему будет взаимодействовать с прокси-сервером. Поэтому, если злоумышленник сможет получить доступ к прокси-серверу, он сможет увидеть все данные, проходящие через него, в виде открытого текста.
Ваши запросы также будут видны в истории браузера. У пользователей может возникнуть желание сделать закладку на сайте. У некоторых пользователей установлены инструменты синхронизации закладок, поэтому пароль может оказаться на deli.ci.us или в другом месте.
Наконец, кто-то, возможно, взломал ваш компьютер и установил регистратор клавиатуры или скребок для экрана (что делают многие вирусы типа «Троянский конь»). Поскольку пароль виден непосредственно на экране (в отличие от «*» в диалоговом окне ввода пароля), это еще одна дыра в безопасности.
Вывод: когда дело доходит до безопасности, всегда полагайтесь на проторенный путь. Слишком много всего, о чем вы не знаете, о чем не будете думать и что сломает вам шею.
Я не согласен с утверждением о [...] утечке реферера HTTP (внешнее изображение на целевой странице может утечь пароль) в Ответ Слау .
RFC HTTP 1.1 прямо заявляет :
Клиенты НЕ ДОЛЖНЫ включать Реферера поле заголовка в (небезопасном) HTTP запросить ссылку на страницу передается по безопасному протоколу.
В любом случае, журналы сервера и история браузера являются более чем достаточными причинами, чтобы не помещать конфиденциальные данные в строку запроса.
Да, пока никто не смотрит через плечо на монитор.
Да, с того момента, как вы установили соединение HTTPS, все в безопасности. Строка запроса (GET) как POST отправляется по SSL.
Вы можете отправить пароль в виде хеш-параметра MD5 с добавлением соли. Сравните его на стороне сервера для аутентификации.
