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

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

• https://myusername:myPassword@myserver.com/foo/bar/metadata
• https://myserver.com/?user=myUsername&pass=MyPasswort

myusername:myPassword@ - это "Информация О Пользователе" (эта форма фактически устарела в последнем URI RFC), тогда как ?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:myPassword@ является частью авторитет. На практике используйте http (Basic) аутентификацию заголовки обычно используются для передачи этой информации. На стороне сервера заголовки обычно не регистрируются (и если это так, то не имеет значения, ввел ли клиент их в строку местоположения или через диалоговое окно ввода). В общем (хотя это зависит от реализации), браузеры не хранят его в строке расположения или, по крайней мере, удаляют пароль. Похоже, что Firefox сохраняет userinfo в истории браузера, а Chrome-нет (и IE на самом деле не поддержите их без обходного пути)

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

просто myusername:myPassword@ явно предназначен для передачи информации, которая потенциально чувствительна, и браузеры, как правило, предназначены для обработки этого должным образом, в то время как браузеры не могут угадать, какая часть запросов чувствительна, а какая нет: ожидайте утечки информации.

информация реферера также обычно не будет просачиваться третьим лицам, так как 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 основанные формы для представления конфиденциальных данных, поскольку это приведет к кодированию этих данных в URI запроса. Многие существующие серверы, прокси и агенты пользователей будут регистрировать URI запроса в том месте, где он может быть виден третьим лицам. Серверы могут использовать POST-based form submission вместо

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