Класс HTTPPasswordMgr в модуле urllib.request вместе со своими подклассами HTTPPasswordMgrWithDefaultRealm и HTTPPasswordMgrWithPriorAuth не учитывал схему URL-адресов при сопоставлении сохраненных учетных данных с запрошенным URL-адресом. Учетные данные, добавленные для URL-адреса https://, также использовались для запросов к тому же хосту через http://, поэтому злоумышленник, способный перенаправить или понизить версию клиента до обычного HTTP (например, через перенаправление HTTPS-to-HTTP или положение на пути), мог получить учетные данные в открытом виде. Учетные данные, добавленные для URL-адресов http://, также можно отправлять через https://.
Сопоставление учетных данных теперь ограничивается схемой URL-адресов. Учетные данные, зарегистрированные по URL-адресу, включающему схему, используются только для запросов с той же схемой. Учетные данные, зарегистрированные с использованием простых полномочий (например, example.com или example.com:8080), продолжают соответствовать любой схеме, сохраняя совместимость с существующим кодом, включая аутентификацию прокси.
Пользователи, которые не могут выполнить обновление немедленно, могут смягчить ситуацию, гарантируя, что приложения никогда не отправляют простые запросы http:// к хостам, для которых зарегистрированы учетные данные, например, не следуя перенаправлениям на URL-адреса http://.
Показать оригинальное описание (EN)
The HTTPPasswordMgr class in the urllib.request module, along with its subclasses HTTPPasswordMgrWithDefaultRealm and HTTPPasswordMgrWithPriorAuth, did not take the URL scheme into account when matching stored credentials against a requested URL. Credentials added for an https:// URL were also used for requests to the same host over http://, so an attacker able to redirect or downgrade a client to plain HTTP (for example, via an HTTPS-to-HTTP redirect or an on-path position) could capture credentials in cleartext. Credentials added for http:// URLs could likewise be sent over https://. Credential matching is now scoped by URL scheme. Credentials registered with a URL that includes a scheme are only used for requests with the same scheme. Credentials registered with a bare authority (such as example.com or example.com:8080) continue to match any scheme, preserving compatibility with existing code, including proxy authentication. Users who cannot upgrade immediately can mitigate by ensuring that applications never make plain http:// requests to hosts for which credentials are registered, for example by not following redirects to http:// URLs.
Характеристики атаки
Последствия
Строка CVSS v4.0