Учетные данные HTTP Basic Authentication передаются в URL и шифровании


250

У меня есть вопрос об учетных данных HTTPS и HTTP-аутентификации.

Предположим, я защищаю URL с помощью аутентификации HTTP:

<Directory /var/www/webcallback>
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /var/www/passwd/passwords
Require user gooduser
</Directory>

Затем я получаю доступ к этому URL из удаленной системы через HTTPS, передавая учетные данные в URL:

https://gooduser:secretpassword@www.example.com/webcallback?foo=bar

Будут ли имя пользователя и пароль автоматически шифроваться SSL? То же самое верно для GET и POST? Мне трудно найти надежный источник с этой информацией.



Очень старый вопрос, но тем не менее: ietf.org/rfc/rfc3986.txt осуждает этот подход : «Использование формата« user: password »в поле userinfo устарело».
— Madbreaks

Ответы:


237

Будут ли имя пользователя и пароль автоматически шифроваться SSL? То же самое верно для GET и POST

Да да да

Вся связь (за исключением поиска DNS, если IP-адрес для имени хоста еще не кешируется) шифруется при использовании SSL.


25
+1. GET и POST, включая URL, зашифрованы. Я только добавлю - инструменты типа данных firebug и Tamper могут показывать незашифрованные результаты только потому, что они являются частью браузера и, следовательно, способны перехватить запрос до того, как он будет зашифрован. После отправки по проводам все шифруется.
— Срипати Кришнан

21
Чтобы было понятно, все, кроме домена, зашифровано. Если кто-то наткнется на это и захочет получить более подробный ответ, см. Answer.google.com/answers/threadview/id/758002.html
— rcourtna

7
Для полноты картины « Internet Explorer не поддерживает имена пользователей и пароли в адресах веб-сайтов (URL-адреса HTTP или HTTPS) ». Похоже, что только версии Internet Explorer 3.0–6.0 поддерживают следующий синтаксис для URL-адресов HTTP или HTTPS: http (s): //username:password@server/resource.ext Примечание. Это изменение поведения по умолчанию не влияет на другие протоколы. Например, вы все равно можете включить информацию о пользователе в URL-адрес FTP после установки обновления безопасности 832894.
— Люк

этот ответ не содержит ни заслуживающего доверия источника, ни дополнительных объяснений.
— Jens Piegsa

26

Да, это будет зашифровано.

Вы поймете это, если просто посмотрите, что происходит за кулисами.

  1. Браузер или приложение сначала разбивают URL-адрес и пытаются получить IP-адрес хоста с помощью DNS-запроса. То есть: будет сделан DNS-запрос для определения IP-адреса домена (www.example.com). Обратите внимание, что никакая другая информация не будет отправлена ​​через этот запрос.
  2. Браузер или приложение установят соединение SSL с IP-адресом, полученным из запроса DNS. Сертификаты будут обменены, и это происходит на транспортном уровне. На этом этапе никакая информация уровня приложения не будет передана. Помните, что базовая аутентификация является частью HTTP, а HTTP является протоколом прикладного уровня.Не задача транспортного уровня.
  3. После установления SSL-соединения теперь необходимые данные будут переданы на сервер. То есть: путь или URL, параметры и имя пользователя и пароль базовой аутентификации.

-5

Не обязательно правда. Он будет зашифрован на проводе, однако он все равно попадает в журналы в виде простого текста


17
Какой веб-сервер регистрирует логин и пароли от запросов? Это был бы адский небезопасный веб-сервер.
— Эндрю Барбер

1
Да, это просто неправда. Возможно, можно поручить apache регистрировать эту информацию, но по умолчанию это не так.
— DougW

27
@Brandon, вероятно, думал «в URL», что подразумевается в строке запроса (например,? User = bob & pw = 123hackmeplz). Это может закончиться в журналах сервера.
— Майк Граф

5
Связано: «Когда вы вызываете этот URL на клиенте с помощью, например, curl, имя пользователя и пароль будут четко видны в списке процессов и могут появиться в файле истории bash». - stackoverflow.com/a/4981309
— Ястребиный глаз Паркер

1
@ zb226 спрашивающий конкретно упомянул о вводе учетных данных в URL.
— Ламбарт
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.