Ответы:
Да, это так. Но использование GET для конфиденциальных данных - плохая идея по нескольким причинам:
Поэтому, хотя Querystring защищен, не рекомендуется передавать конфиденциальные данные по строке запроса.
[1] Хотя я должен отметить, что RFC заявляет, что браузер не должен отправлять ссылки с HTTPS на HTTP. Но это не значит, что плохая сторонняя панель инструментов браузера или внешнее изображение / флэш-память с сайта HTTPS не пропустят ее.
History caches in browsers
или добавить ссылку на них?
С точки зрения «анализировать сетевой пакет» запрос GET безопасен, так как браузер сначала устанавливает безопасное соединение, а затем отправляет запрос, содержащий параметры GET. Но URL-адреса GET будут храниться в истории / автозаполнении браузера пользователя, что не подходит для хранения, например, данных пароля. Конечно, это применимо только в том случае, если вы берете более широкое определение «Webservice», которое может получить доступ к службе из браузера, если вы получаете доступ к нему только из своего пользовательского приложения, это не должно быть проблемой.
Поэтому использование сообщений хотя бы для диалогов с паролями должно быть предпочтительным. Также, как указано в ссылке, 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 с использованием этого метода - не лучший способ. Вы должны пойти на другой подход.
(e.g http://example.com/login?username=alice&password=12345)
.
Да. Весь текст сеанса HTTPS защищен SSL. Это включает в себя запрос и заголовки. В этом отношении POST и GET будут абсолютно одинаковыми.
Что касается безопасности вашего метода, то без надлежащего осмотра нет реального способа сказать.
SSL сначала подключается к хосту, поэтому имя хоста и номер порта передаются в виде открытого текста. Когда хост отвечает и вызов успешно выполняется, клиент зашифровывает HTTP-запрос фактическим URL-адресом (т. Е. После третьего слеша) и отправляет его на сервер.
Есть несколько способов сломать эту безопасность.
Можно настроить прокси, чтобы он действовал как «человек посередине». По сути, браузер отправляет запрос на подключение к реальному серверу прокси. Если прокси-сервер настроен таким образом, он будет подключаться через SSL к реальному серверу, но браузер по-прежнему будет взаимодействовать с прокси-сервером. Поэтому, если злоумышленник может получить доступ к прокси-серверу, он может видеть все данные, проходящие через него, в виде открытого текста.
Ваши запросы также будут видны в истории браузера. У пользователей может возникнуть желание сделать закладку на сайте. У некоторых пользователей установлены инструменты синхронизации закладок, поэтому пароль может оказаться на сайте deli.ci.us или в другом месте.
Наконец, кто-то, возможно, взломал ваш компьютер и установил регистратор клавиатуры или скребок для экрана (что делают многие вирусы типа «Троянский конь»). Поскольку пароль виден непосредственно на экране (в отличие от «*» в диалоговом окне ввода пароля), это еще одна дыра в безопасности.
Вывод: когда дело доходит до безопасности, всегда полагайтесь на проторенный путь. Слишком много всего, о чем вы не знаете, о чем не будете думать и что сломает вам шею.
Да, пока никто не смотрит через плечо на монитор.
Я не согласен с утверждением о [...] утечке реферера HTTP (внешнее изображение на целевой странице может утечь пароль) в ответе Слау .
RFC HTTP 1.1 явно заявляет :
Клиенты НЕ ДОЛЖНЫ включать поле заголовка Referer в (незащищенный) HTTP-запрос, если ссылающаяся страница была передана по безопасному протоколу.
В любом случае, журналы сервера и история браузера являются более чем достаточными причинами, чтобы не помещать конфиденциальные данные в строку запроса.
Вы можете отправить пароль в виде хеш-параметра MD5 с добавлением соли. Сравните это на стороне сервера для аутентификации.