it-swarm.com.ru

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

У нас есть веб-страница, которая использует sapui5 -рамку для создания spa . Связь между браузером и сервером использует https . Взаимодействие для входа на страницу следующее:

  1. Пользователь открывает сайт, введя https://myserver.com в браузере
  2. Отображается диалог входа в систему с двумя полями формы для ввода имени и пароля. 
  3. После ввода username и password и нажатия login-button 
  4. ajax-запрос отправляется с помощью GET на URL: https://myusername:[email protected]/foo/bar/metadata 

Насколько я понимаю, использование GET для отправки конфиденциальных данных никогда не было хорошей идеей. Но этот ответ на HTTPS - это строка URL-адреса secure , которая говорит следующее

HTTPS Establishes an underlying SSL conenction before any HTTP data is
transferred. This ensures that all URL data (with the exception of
hostname, which is used to establish the connection) is carried solely
within this encrypted connection and is protected from
man-in-the-middle attacks in the same way that any HTTPS data is.

В другом ответе в той же теме:

These fields [for example form field, query strings] are stripped off
of the URL when creating the routing information in the https packaging 
process by the browser and are included in the encrypted data block.

The page data (form, text, and query string) are passed in the
encrypted block after the encryption methods are determined and the
handshake completes.

Но похоже, что при использовании get могут возникнуть проблемы с безопасностью:

Это относится к URL, как?

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

Дополнительные вопросы по этой теме:

На security.stackexchange есть дополнительная информация:

Но на мой взгляд, некоторые аспекты до сих пор не ответил

Вопрос

На мой взгляд, упомянутые пункты являются действительными возражениями против не использовать get. Это случай; использует get для отправки паролей плохая идея?

Это варианты атаки, есть еще?

  • история браузера 
  • журналы сервера (при условии, что URL хранится в журналах в незашифрованном или зашифрованном виде)
  • информация о реферере (если это действительно так)

Какие варианты атаки существуют при отправке конфиденциальных данных (пароля) через https с использованием get?

Спасибо

21
surfmuggle

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

  • 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 - это query, гораздо более неотъемлемая часть 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 аналогично использованию формы на основе GET, и, хотя проблема Referer может быть устранена, проблемы, связанные с журналами и историей, остаются.

17
Bruno

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

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

24
Steffen Ullrich

Учти это:

https://www.example.com/login

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

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

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

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

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

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

0
Jay

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

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

HTTPS

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

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

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

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

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

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

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

0
Mehmet Ince

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

См. http://en.wikipedia.org/wiki/Basic_access_authentication

0
Ironluca