Ловушка перенаправлений длиной в два десятилетия
На протяжении двадцати лет тонкая, но значительная уязвимость в PHP незаметно компрометировала бесчисленное количество приложений. С 2003 года широко используемая функция file_get_contents, предназначенная для получения содержимого URL, автоматически следовала за HTTP-перенаправлениями без каких-либо проверок. Эта, казалось бы, безобидная функция создала серьезную уязвимость, непреднамеренно раскрывая конфиденциальные данные пользователей.
Когда скрипт использовал file_get_contents для доступа к API и включал заголовок Authorization (содержащий bearer-токены или другие учетные данные), PHP слепо пересылал этот заголовок на любой новый домен, указанный в перенаправлении. Система предполагала, что новый пункт назначения заслуживает доверия, продолжая отправлять аутентификационные данные, даже если перенаправление указывало на совершенно другой сервер.
Наиболее опасный сценарий включал понижение уровня безопасности с HTTPS до HTTP. Если первоначальный защищенный запрос перенаправлялся на незашифрованную HTTP-конечную точку, PHP все равно отправлял конфиденциальные токены. Это означало, что учетные данные, изначально защищенные TLS, передавались по сети в полностью незашифрованном виде, что делало их легкодоступными для перехвата злоумышленниками. Этот механизм скрытой пересылки подвергал риску огромное количество приложений.
Исправление выпущено, но оно не идеально
Основная проблема заключалась в скрытой пересылке PHP конфиденциальных данных во время перенаправлений. К счастью, новый патч наконец решает эту проблему, существующую десятилетиями, вводя критическую проверку безопасности. Теперь, если перенаправление меняет схему (например, с HTTP на HTTPS), хост или порт, PHP интеллектуально удаляет заголовки Authorization и Cookie. Это важное вмешательство предотвращает непреднамеренную передачу ваших конфиденциальных учетных данных на непредусмотренный, потенциально вредоносный новый сервер.
Чтобы воспользоваться этим важным обновлением безопасности, разработчикам необходимо оперативно обновить свои установки PHP. Исправление доступно в последних патч-релизах для версий PHP 8.2–8.5. Обновление гарантирует, что ваш сервер использует версию, которая активно защищает от этой специфической утечки учетных данных, закрывая значительную брешь в безопасности, существовавшую годами.
Важно отметить, что этот патч не решает все сценарии утечки учетных данных. Официальное исправление применяется только к стандартным заголовкам Authorization и Cookie, которые широко известны. Любые пользовательские заголовки, которые вы можете использовать, такие как X-API-Key или другие специфические токены, остаются уязвимыми для той же ловушки с перенаправлениями. Эти пользовательские учетные данные по-прежнему будут автоматически пересылаться на новый сервер, что требует тщательной ручной обработки.
Почему Guzzle спас Laravel (и как спасти себя)
Многие разработчики, использующие HTTP-клиент Laravel или лежащую в его основе библиотеку Guzzle, уже были защищены от этой двадцатилетней уязвимости. Guzzle, надежный HTTP-клиент, управляет перенаправлениями с приоритетом безопасности. Он явно избегает слепой пересылки конфиденциальных заголовков, таких как Authorization или Cookie, при перенаправлении на другую схему, хост или порт, предлагая гораздо более безопасный подход, чем встроенная в PHP функция file_get_contents.
Новый патч PHP (доступный в версиях 8.2–8.5) затрагивает заголовки Authorization и Cookie, но не охватывает все остальное. Любые пользовательские заголовки, которые вы отправляете, например X-API-Key, по-прежнему будут пересылаться во время перенаправления, что может привести к утечке конфиденциальных учетных данных. Чтобы по-настоящему обезопасить их, необходимо отключить автоматические перенаправления PHP, установив для параметра контекста follow_location значение false для функции file_get_contents.
Реализация собственной логики безопасного перенаправления требует тщательных шагов. Вручную проверяйте HTTP-ответ на наличие кода состояния 30x. Если происходит перенаправление, извлеките заголовок Location, чтобы получить новый URL. Крайне важно проверить домен этого нового URL по вашему списку доверенных доменов перед инициированием нового запроса. Этот новый запрос должен явно исключать любые конфиденциальные пользовательские заголовки, гарантируя, что ваши учетные данные никогда не попадут к непреднамеренному получателю. Дополнительную информацию о связанных исправлениях см. в CVE-2026-91766: PHP had the redirect credential leak curl fixed in 2018.
Нравится статья? Получайте такие каждое утро на почту.
одно письмо в день · отписка в два клика · без сторонних трекеров
Новая глава безопасности PHP
Двадцатилетнее существование этой ошибки перенаправления в PHP служит суровым уроком сложности поддержки зрелых языков программирования. Основные функциональные возможности, такие как file_get_contents, глубоко встроенные в течение многих лет, могут скрывать тонкие уязвимости, которые остаются незамеченными даже по мере развития языка. Обнаружение и исправление проблем 2003 года сейчас демонстрирует огромную сложность обеспечения безопасности в обширной и долгоживущей кодовой базе.
Несмотря на постоянные разговоры о том, что «PHP мертв», это важное исправление для версий с 8.2 по 8.5 подчеркивает активное и непрерывное развитие языка. Modern PHP, особенно с использованием надежных фреймворков, таких как Laravel, неизменно позволяет создавать высококачественные приложения, доказывая свою неизменную актуальность. Его мощная экосистема с такими библиотеками, как Guzzle, которые по умолчанию безопасно обрабатывают перенаправления, часто предоставляет встроенные средства защиты.
В конечном счете, сообщество PHP продемонстрировало свою непоколебимую приверженность модернизации и обеспечению безопасности языка с помощью этого патча. Устранение устаревшей уязвимости, существовавшей два десятилетия, укрепляет доверие и демонстрирует проактивные улучшения безопасности. Эта преданность делу гарантирует, что PHP остается мощным и актуальным выбором для веб-разработки, постоянно адаптируясь к новым ландшафтам безопасности и создавая более прочную основу для будущего.
Часто задаваемые вопросы
В чем заключалась ошибка утечки заголовка авторизации в PHP?
Более 20 лет функции PHP, такие как file_get_contents, автоматически следовали за HTTP-перенаправлениями и пересылали конфиденциальные заголовки, такие как Authorization, в новый пункт назначения. Это могло произойти, даже если перенаправление было на другой сервер или с защищенного HTTPS на небезопасный HTTP.
В каких версиях PHP есть это исправление?
Патч доступен в последних выпусках PHP версий 8.2, 8.3, 8.4 и 8.5. Чтобы быть защищенным, вы должны обновиться до последней версии патча в рамках этих серий.
Исправляет ли новый патч PHP все утечки заголовков?
Нет. Официальное исправление удаляет только стандартные заголовки Authorization и Cookie во время междоменных перенаправлений. Пользовательские заголовки, такие как X-Api-Key, не удаляются и по-прежнему будут утекать.
Затронул ли этот баг PHP фреймворк Laravel?
Нет. HTTP-клиент по умолчанию в Laravel построен на базе Guzzle, который реализует свою собственную, более безопасную логику обработки перенаправлений. Guzzle не пересылает конфиденциальные заголовки на другие хосты, поэтому приложения на Laravel не были уязвимы для этой конкретной проблемы.