Логин и пароль в адресной строке http: Синтаксис URL-адреса не содержит имя пользователя и пароль — Browsers

Заголовки запросов Authorization и Proxy-Authorization (en-US) содержат учётные данные для аутентификации агента пользователя (User Agent) на (прокси) сервере. Здесь снова требуется <type> за которым следуют учётные данные, которые могут быть закодированы или зашифрованы в зависимости от того, какая схема аутентификации используется.

Authorization: <type> <credentials>
Proxy-Authorization: <type> <credentials>

Схемы Аутентификации

Общая структура HTTP аутентификации является основной для ряда схем аутентификации. Schemes can differ in security strength and in their availability in client or server software.

IANA поддерживат список схем аутентификации, однако существуют и другие схемы предлагаемые хост-сервисами, например, Amazon AWS.

Некоторые распространенные схемы аутентификации включают:

• Basic (смотреть RFC 7617, зашифрованные с помощью base64 учётные данные. Больше информации смотреть снизу.),
• Bearer (смотреть RFC 6750, bearer токены для доступа OAuth 2.0-защищённых ресурсов),
• Digest (смотреть RFC 7616, Firefox 93 и более поздние версии поддерживают шифрование SHA-256. Предыдущие версии поддерживают только хэширование MD5 (не рекомендуется). ),
• HOBA (смотреть RFC 7486, Секция 3, HTTP Origin-Bound Authentication, digital-signature-based),
• Mutual (смотреть draft-ietf-httpauth-mutual),
• AWS4-HMAC-SHA256 (смотреть AWS документацию).

Схемы могут различаться по степени безопасности и по их доступности в клиентском или серверном программном обеспечении.

«Базовая» (Basic) схема аутентификации обеспечивает очень низкую безопасность, но широко поддерживается и проста в настройке. Более подробно она представлена ниже.

«Базовая» схема HTTP-аутентификации определена в RFC 7617, которая передаёт учётные данные в виде пар пользователь ID/пароль (user ID/password), закодированных с использованием base64.

Безопасность базовой аутентификации

Поскольку идентификатор (ID) пользователя и пароль передаются по сети в виде открытого текста (он кодируется в base64, однако base64 — это обратимое кодирование), схема базовой аутентификации не является безопасной. При базовой аутентификации следует использовать HTTPS/TLS. Без этих дополнительных улучшений безопасности, базовая аутентификация не должна использоваться для защиты конфиденциальной или ценной информации.

Ограничение доступа с помощью Apache и базовой аутентификации

Чтобы защитить паролем каталог на сервере Apache, вам понадобятся файлы . htaccess и .htpasswd.

Файл .htaccess обычно выглядит так:

AuthType Basic
AuthName "Access to the staging site"
AuthUserFile /path/to/.htpasswd
Require valid-user

Файл .htaccess ссылается на файл .htpasswd, в котором каждая строка состоит из имени пользователя и пароля, разделенных двоеточием («:»). Вы не можете видеть фактические пароли, поскольку они хешируются (в данном случае с помощью md5). Учтите, что вы можете назвать свой файл .htpasswd по-другому, если хотите, но помните, что этот файл не должен быть доступен никому. (Apache обычно настроен на предотвращение доступа к файлам .ht*).

aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/

Ограничение доступа с помощью nginx и базовой аутентификации

Для nginx, вам потребуется указать местоположение, которое вы собираетесь защитить и директиву auth_basic, которая задаёт имя защищённой паролем области. Директива auth_basic_user_file затем указывает на файл .htpasswd, содержащий зашифрованные учётные данные пользователя, как и в примере Apache выше.

location /status {
    auth_basic           "Access to the staging site";
    auth_basic_user_file /etc/apache2/.htpasswd;
}

Доступ используя учётные данные в URL-адресе

Многие клиенты также позволяют избежать запроса на вход в систему, используя закодированный URL, содержащий имя пользователя и пароль, как показано ниже:

https://username:[email protected]/

Использование таких URL-адресов устарело. В браузере Chrome в URL-адресах часть username:password@ даже вырезана из соображений безопасности. В браузере Firefox, проверяется, действительно ли сайт требует аутентификации и если нет, тогда Firefox предупредит пользователя запросом (prompt) «You are about to log in to the site “www.example.com” with the username “username”, but the website does not require authentication. This may be an attempt to trick you.».

• WWW-Authenticate (en-US)
• Authorization
• Proxy-Authorization (en-US)
• Proxy-Authenticate (en-US)
• 401, 403, 407

Found a content problem with this page?

• Edit the page on GitHub.
• Report the content issue.
• View the source on GitHub.

Want to get more involved?

Learn how to contribute.

This page was last modified on 5 дек. 2022 г. by MDN contributors.

Можно ли передать пользователя/пароль для базовой HTTP-аутентификации в параметрах URL?

спросил 11 лет, 1 месяц назад

Изменено 3 года, 4 месяца назад

Просмотрено 1,3 млн раз

Я считаю, что это невозможно, но кто-то из моих знакомых настаивал на том, что это работает. Я даже не знаю, какие параметры попробовать, и я нигде не нашел этого в документации.

Я попробовал http://myserver.com/~user=username&password=mypassword, но это не работает.

Можете ли вы подтвердить, что на самом деле невозможно передать пользователя/пароль через параметры HTTP (GET или POST)?

• аутентификация
• http
• http-основная аутентификация

5

Действительно невозможно передать имя пользователя и пароль через параметры запроса в стандартной аутентификации HTTP. Вместо этого вы используете специальный формат URL, например: http://username:[email protected]/ — это отправляет учетные данные в стандартном HTTP-заголовке «Авторизация».

Возможно, тот, с кем вы разговаривали, думал о специальном модуле или коде, который просматривал параметры запроса и проверял учетные данные. Это не стандартная HTTP-аутентификация, это особенность конкретного приложения.

21

http://username:[email protected] будет работать для FireFox, Chrome, Safari, НО не для IE.

База знаний Майкрософт

7

Передача параметров базовой аутентификации в URL не рекомендуется

Для этого существует поле заголовка Authorization, проверьте его здесь: http header list

Как им пользоваться написано здесь: Базовая аутентификация доступа

Там вы также можете прочитать, что, хотя она по-прежнему поддерживается некоторыми браузерами, предлагаемое решение добавления основных учетных данных авторизации в URL-адрес не рекомендуется.

Прочтите также главу 4.1 в RFC 2617 — HTTP-аутентификация, чтобы узнать, почему НЕ следует использовать обычную аутентификацию.

Передача параметров проверки подлинности в строке запроса

При использовании OAuth или других служб проверки подлинности вы часто также можете отправить свой токен доступа в строке запроса, а не в заголовке авторизации, например:

 GET https:// www. example.com/api/v1/users/1?access_token=1234567890abcdefghijklmnopqrstuvwxyzABCD
 

7

В вашем примере URL-адрес http://myserver.com/ Будет:

http://username:[email protected]/myserver.com/

По состоянию на 19.12.2019 я протестировал это, и оно работает для Хром Fire Fox Safari

Но не для IE, которые больше не поддерживают базовую аутентификацию. Я реализовал это с помощью SSRS 2017, который скрывает имя пользователя и пароль. Я бы порекомендовал вам проверить это с помощью браузера инкогнито. Протестируйте с паролем и без него в разных браузерах Incognito. Тот, у кого нет пароля, должен попросить вас ввести пароль.

1

(очевидно) можно отправить любую строку в параметрах GET, хотя не рекомендуется отправлять логин и пароль, поскольку они могут сделать их хорошо заметными, особенно если они не в AJAX-запросе.

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

Синтаксис URL не содержит имя пользователя и пароль — Браузеры

Редактировать

Твиттер LinkedIn Фейсбук Электронная почта

• Статья
• 25.01.2022

Предупреждение

Устаревшее, неподдерживаемое настольное приложение Internet Explorer 11 было окончательно отключено с помощью обновления Microsoft Edge в некоторых версиях Windows 10. Дополнительные сведения см. в разделе Часто задаваемые вопросы о прекращении использования настольного приложения Internet Explorer 11.

Эта статья предназначена для уведомления администраторов веб-сайтов и ИТ-специалистов о поведении Internet Explorer, когда информация о пользователе включается в адрес веб-сайта (URL-адрес HTTP или HTTPS).

Исходная версия продукта:   Internet Explorer
Исходный номер базы знаний:   834489

Сводка

По умолчанию версии Internet Explorer, выпущенные начиная с выпуска обновления для системы безопасности 832894, не поддерживают обработку имен пользователей и паролей. в HTTP и HTTP с URL-адресами Secure Sockets Layer (SSL) или HTTPS. Следующий синтаксис URL-адреса не поддерживается в Internet Explorer или проводнике Windows:

http(s)://username:password@server/resource.ext

Эта статья предназначена для того, чтобы уведомить вас об этом поведении Internet Explorer по умолчанию. Если вы включаете информацию о пользователе в URL-адреса HTTP или HTTPS, мы рекомендуем изучить обходные пути, описанные в этой статье.

Internet Explorer версий 3.0–6.0 поддерживает следующий синтаксис URL-адресов HTTP или HTTPS:

http(s)://имя пользователя:пароль@сервер/ресурс.ext

Этот синтаксис URL-адреса можно использовать для автоматической отправки пользователя информацию на веб-сайт, поддерживающий базовый метод аутентификации.

Злоумышленник может использовать этот синтаксис URL-адреса для создания гиперссылки, которая, как представляется, ведет на законный веб-сайт, но на самом деле открывает мошеннический (поддельный) веб-сайт. Например, следующий URL-адрес выглядит так, будто открывает http://www.wingtiptoys.com , но на самом деле открывает http://example.com :

http://[email protected] .

Примечание

В этом случае Internet Explorer 6 с пакетом обновления 1 (SP1) и Internet Explorer 6 для Microsoft Windows Server 2003 отображают только http://example.com в адресной строке. Однако более ранние версии Internet Explorer отображают http://[email protected] в адресной строке.

Кроме того, злоумышленники могут использовать этот синтаксис URL-адреса вместе с другими методами для создания ссылки на вводящий в заблуждение (поддельный) веб-сайт, который отображает URL-адрес законного веб-сайта в строке состояния , адресной строке и Строка заголовка всех версий Internet Explorer. Для получения дополнительной информации по этой проблеме щелкните номер статьи 833786, чтобы защитить себя от вводящих в заблуждение (поддельных) веб-сайтов и вредоносных гиперссылок.

Объяснение изменения поведения по умолчанию

Чтобы смягчить проблемы, описанные в разделе Фоновая информация , Internet Explorer и Windows Explorer больше не поддерживают обработку URL-адресов HTTP и HTTPS этой формы. Проводник Windows и Internet Explorer не открывают сайты HTTP или HTTPS с помощью URL-адреса, содержащего информацию о пользователе. По умолчанию, если информация о пользователе включена в URL-адрес HTTP или HTTPS, отображается веб-страница со следующим заголовком:

Недопустимая синтаксическая ошибка.

Примечание

Это изменение поведения по умолчанию не влияет на другие протоколы.

Это изменение в поведении по умолчанию также реализуется обновлениями безопасности, пакетами обновлений и версиями Internet Explorer, которые были выпущены, начиная с выпуска обновления безопасности 832894.

Обходные пути для пользователей которые вводят URL-адрес в адресную строку или щелкают ссылку

Если пользователи обычно вводят URL-адреса HTTP или HTTPS, которые содержат информацию о пользователе, в адресной строке или щелкают ссылки, которые содержат информацию о пользователе в URL-адресах HTTP или HTTPS, вы можете обойти эту новую функцию в Internet Explorer двумя способами:

• Не включать информацию о пользователе в URL-адреса HTTP или HTTPS.
• Сообщите пользователям, чтобы они не включали свою информацию о пользователе при вводе URL-адресов HTTP или HTTPS.

Если на веб-сайте используется базовый метод проверки подлинности, Internet Explorer автоматически запрашивает у пользователей имя пользователя и пароль. В некоторых случаях пользователи могут нажать кнопку Запомнить мой пароль в диалоговом окне, чтобы сохранить свои учетные данные для последующих посещений этого веб-сайта.

Обходные пути для разработчиков приложений и веб-сайтов

1. URL-адреса, которые открываются объектами, вызывающими функции WinInet или Urlmon

   Для объектов, которые используют URL-адрес HTTP или HTTPS, который включает информацию о пользователе, когда они вызывают функцию WinInet или Urlmon, такую ​​как InternetOpenURL, перепишите объект, чтобы использовать один из следующих методов для отправки информации о пользователе на веб-сайт:

   • Используйте функцию InternetSetOption и включите следующие флаги параметров:
     • INTERNET_OPTION_USERNAME
     • ИНТЕРНЕТ_ОПЦИЯ_ПАРОЛЬ

   Примечание

   Для этих флагов опция InternetSetOption должна иметь дескриптор, возвращаемый функцией InternetConnect. Поэтому, если приложение использует функцию InternetOpenUrl, измените приложение, чтобы использовать функции InternetConnect, HttpOpenRequest и HttpSendRequest WinInet.

   Для получения дополнительных сведений об использовании этих функций посетите следующие веб-сайты Microsoft:

   • Функция InternetConnectA
   • Функция HttpOpenRequestA
   • Функция HttpSendRequestA

   Для получения дополнительных сведений об использовании интерфейса IAuthenticate посетите следующий веб-узел корпорации Майкрософт:

   • Интерфейс IAuthenticate

   Примечание

   С помощью этого обходного пути можно открывать веб-сайты, на которые перенаправляется метод подмены URL-адресов. Отображается весь URL-адрес, включая место перенаправления.

   Например, появится следующий URL-адрес:

   http://[email protected]

   Пользователь по-прежнему попадает на перенаправленный веб-сайт. В этом примере пользователь попадает на http://www.example.com .

2. URL-адреса, которые открываются сценарием, использующим учетные данные для управления состоянием

   Если вы включаете URL-адреса HTTP или HTTPS, содержащие информацию о пользователе, в код сценария, для управления информацией о состоянии измените код сценария, чтобы использовать файлы cookie вместо информации о пользователе. Дополнительные сведения о том, как использовать файлы cookie для управления информацией о состоянии, см. в разделе Механизм управления состоянием HTTP.

   Пример использования Visual Basic для чтения и записи файлов cookie HTTP в веб-программе ASP.NET см. в разделе Класс HttpCookie.

Как отключить новое поведение или использовать его в других программах

Вы можете установить значения реестра для использования этого нового поведения в других программах, в которых размещен элемент управления веб-браузером, или для отключения этого нового поведения для Windows Explorer и Internet Explorer.

1. Как программы, содержащие элемент управления веб-браузера, могут использовать это новое поведение по умолчанию для обработки информации о пользователе в HTTP или в URL-адресах HTTPS

   По умолчанию это новое поведение по умолчанию для обработки информации о пользователе в URL-адресах HTTP или HTTPS применяется только к Проводнику Windows и Internet Explorer. Чтобы использовать это новое поведение в других программах, в которых размещается элемент управления веб-браузера, создайте значение DWORD с именем SampleApp.exe , где SampleApp.exe — это имя исполняемого файла, который запускает программу. Установите для значения DWORD значение 1 в одном из следующих разделов реестра.

   • Для всех пользователей программы установите значение в следующем ключе реестра:

     HKEY_LOCAL_MACHINE\Software\Microsoft\InternetExplorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE

   • Только для текущего пользователя программы установите значение в следующем разделе реестра:

     HKEY_CURRENT_USER\Software\Microsoft\InternetExplorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE

2. Как отключить новое поведение по умолчанию для обработки информации о пользователе в URL-адресах HTTP или HTTPS

   Чтобы отключить новое поведение по умолчанию в проводнике Windows и Internet Explorer, создайте значения iexplore.