Являются ли проблемы безопасности отправкой пароля с использованием запроса GET через https?

Ответ 1

Эти два подхода принципиально различны:

• https://myusername:[email protected]/foo/bar/metadata
• https://myserver.com/?user=myUsername&pass=MyPasswort

myusername:[email protected] - это "Информация о пользователе" (эта форма фактически устарела в последнем RFC URI), тогда как ?user=myUsername&pass=MyPasswort является частью запроса.

Если вы посмотрите на этот пример из RFC 3986:

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment
      |   _____________________|__
     / \ /                        \
     urn:example:animal:ferret:nose

myusername:[email protected] является частью полномочий. На практике для передачи этой информации обычно используются HTTP-заголовки (Basic) аутентификации. На стороне сервера заголовки, как правило, не регистрируются (и если они есть, то не имеет значения, будет ли клиент вводить их в свою адресную строку или через диалог ввода). В целом (хотя это зависит от реализации), браузеры не хранят его в строке адреса или, по крайней мере, удаляют пароль. Похоже, что Firefox сохраняет информацию о пользователе в истории браузера, а Chrome - нет (и IE не поддерживает их без обходного пути).

Напротив ?user=myUsername&pass=MyPasswort - это запрос, гораздо более неотъемлемая часть URI, и он отправляется как HTTP Request-URI. Это будет в истории браузера и журналах сервера. Это также будет передано в реферер.

Проще говоря, myusername:[email protected] явно предназначено для передачи информации, которая потенциально чувствительна, и браузеры, как правило, предназначены для соответствующей обработки, тогда как браузеры не могут угадать, какая часть запросов является чувствительной, а какая нет: ожидайте информацию утечка там.

Информация реферера будет также, как правило, не просочиться третьими лицами, так как Referer заголовок приходит со страницы HTTPS обычно посылаются только с другим запросом на HTTPS на тот же хост. (Конечно, если вы использовали https://myserver.com/?user=myUsername&pass=MyPasswort, это будет в журналах того же хоста, но вы не сильно его зарабатываете, так как он остается на том же сервере журналы.)

Это указано в спецификации HTTP (раздел 15.1.3):

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

Хотя это просто "НЕ СЛЕДУЕТ", Internet Explorer, Chrome и Firefox, похоже, реализуют это таким образом. Относится ли это к HTTPS-запросам от одного хоста к другому, зависит от браузера и его версии.

Теперь можно переопределить это поведение, как описано в этом вопросе и в этом проекте спецификации, с помощью заголовка <meta>, но вы не сделаете этого на чувствительной странице, которая использует ?user=myUsername&pass=MyPasswort любом случае.

Обратите внимание, что остальная часть спецификации HTTP (раздел 15.1.3) также имеет отношение:

Авторам сервисов, которые используют протокол HTTP, НЕ СЛЕДУЕТ использовать формы GET для представления конфиденциальных данных, поскольку это приведет к тому, что эти данные будут закодированы в Request-URI. Многие существующие серверы, прокси и пользовательские агенты будут регистрировать URI запроса в каком-то месте, где он может быть виден третьим лицам. Серверы могут использовать отправку форм на основе POST

Использование ?user=myUsername&pass=MyPasswort - это то же ?user=myUsername&pass=MyPasswort, что использование формы на основе GET, и, хотя проблема Referer может быть устранена, проблемы с журналами и историей остаются.

Ответ 2

Отправка любых конфиденциальных данных через GET опасна, даже если это HTTPS. Эти данные могут оказаться в файлах журналов на сервере и будут включены в заголовок Referer в ссылках или с других сторон. Они также будут сохранены в истории браузера, чтобы злоумышленник мог попытаться угадать и проверить исходное содержимое ссылки с атакой на историю.

Кроме того, вам лучше задавать такие вопросы на security.stackexchange.com.

Ответ 3

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

https://www.site.com/?username=alice&password=b0b123!

HTTPS

Прежде всего. HTTPS не связан с этой темой. Поскольку использование POST или GET не имеет значения с точки зрения злоумышленника. Атакующие могут легко захватывать конфиденциальные данные из строки запроса или непосредственно тела запроса POST, когда трафик является HTTP. Поэтому это не имеет никакого значения.

Журналы сервера

Мы знаем, что Apache, Nginx или другие службы регистрируют каждый HTTP-запрос в файле журнала. Это означает, что строка запроса (? Username = alice & password = b0b123!) Будет записана в файлы журнала. Это может быть опасно из-за того, что ваш системный администратор также может получить доступ к этим данным и получить все учетные данные пользователя. Также может произойти другой случай, когда ваш сервер приложений будет компрометирован. Я считаю, что вы храните пароль как хешированный. Если вы используете мощный алгоритм хеширования, такой как SHA256, ваш клиентский пароль будет более защищен от хакеров. Но хакеры могут обращаться к файлам журналов напрямую, чтобы получить пароли в виде простого текста с очень простыми сценариями оболочки.

Информация о реферере

Мы предположили, что клиент открыл ссылку выше. Когда клиентский браузер получит html-контент и попытается его проанализировать, он увидит тег изображения. Эти изображения могут размещаться в вашем домене (постим или аналогичные службы или непосредственно в домене под управлением хакера). Браузер делает HTTP-запрос, чтобы получить изображение. Но текущий url https://www.site.com/?username=alice&password=b0b123! который будет референтной информацией!

Это означает, что Алиса и ее пароль будут переданы в другой домен и могут быть доступны непосредственно из веб-журналов. Это действительно важная проблема безопасности.

Этот раздел напоминает мне об уязвимостях, связанных с фиксацией сеанса. Пожалуйста прочитайте следующую статью OWASP для почти того же недостатка безопасности с сеансами. (https://www.owasp.org/index.php/Session_fixation) Стоит прочитать его.

Ответ 4

Сообщество представило широкий взгляд на соображения, выше сказанное касается вопроса. Однако запросы GET могут, в общем, нуждаться в аутентификации. Как отмечалось выше, отправка имени пользователя/пароля как части URL-адреса никогда не является правильной, однако обычно это не так, как обычно обрабатывается информация аутентификации. Когда запрос на ресурс отправляется на сервер, сервер обычно отвечает заголовком 401 и Аутентификация в ответе, против которого клиент отправляет заголовок авторизации с информацией об аутентификации (в базовой схеме). Теперь этот второй запрос от клиента может быть POST или GET-запросом, ничто не мешает этому. Таким образом, как правило, это не тип запроса, а способ передачи информации находится под вопросом.

Обратитесь http://en.wikipedia.org/wiki/Basic_access_authentication

Ответ 5

Учти это:

https://www.example.com/login

Javascript на странице входа в систему:

$.getJSON("/login?user=joeblow&pass=securepassword123");

Каким будет реферер сейчас?

Если вы беспокоитесь о безопасности, дополнительный слой может быть:

var a = Base64.encode(user.':'.pass);
$.getJSON("/login?a="+a);

Хотя данные не зашифрованы, по крайней мере, данные скрыты от глаз.