Новые уязвимости в PHP грозят веб-приложениям DoS и утечкой данных

Новые уязвимости в PHP грозят веб-приложениям DoS и утечкой данных

Новые уязвимости в PHP грозят веб-приложениям DoS и утечкой данных

В PHP пропатчены пять уязвимостей, повышающих риск атаки на веб-приложения. Последствия эксплойта могут быть различными, от утечки конфиденциальной информации до отказа в обслуживании (DoS).

Все уязвимости связаны с функционированием встроенной обертки HTTP — дополнительного кода, расширяющего возможности работы с потоками.

Уязвимость CVE-2025-1861 возникла из-за сокращения заголовков перенаправления Location. Предельный размер буфера, выделяемого под значения местоположения, был задан как 1024 байт вместо 8000, рекомендованного по RFC 9110.

Из-за этого в URI могла выпасть критически важная информация. Более того, проблема грозила перенаправлением на другой ресурс, а возврат ошибки мог привести к DoS на удаленном сайте.

Причиной CVE-2025-1734 является некорректная обработка недопустимых заголовков. Отсутствие двоеточия либо знак пробела перед ним не маркировались как ошибка; в результате при парсинге массива в приложении возникала возможность request smuggling — вмешательства в обработку HTTP-запросов с целью получения доступа к конфиденциальным данным в обход защиты.

В появлении CVE-2025-1217 повинен парсер, который неправильно обрабатывал свернутые заголовки. Он воспринимал пробел в начале строки как разделитель, а не продолжение заголовка, что грозило ошибками в определении MIME-типа и некорректной интерпретацией ответа на запрос в приложении, в особенности после редиректа.

Из-за наличия проблемы CVE-2025-1219 потоки libxml возвращали неправильное значение в заголовке Content-Type в ответ на запрос ресурса-редиректора. При перенаправлении не происходила очистка списка сохраненных заголовков, и php_libxml_input_buffer_create_filename(), сканируя блок, могла ошибиться с выбором, что влекло некорректный парсинг документа и обход проверки подлинности.

Уязвимость CVE-2025-1736 возникла из-за ошибки в реализации функции check_has_header, которая не проверяла наличие управляющего символа \r в комбинации, сигнализирующей перенос строки (\r\n).

В тех случаях, когда в заголовке используется значение из пользовательского ввода, отсутствие \r могло, к примеру, воспрепятствовать отправке HTTP-заголовка Authorization. Подобная оплошность способна повлиять на результат и повлечь DoS либо другие неожиданные проблемы.

Патчи включены в состав выпусков PHP 8.1.32, 8.2.28, 8.3.19 и 8.4.5. Разработчикам настоятельно рекомендуется произвести обновление: уязвимости в PHP пользуются популярностью у злоумышленников.

Российские банки все чаще блокируют карты за переводы себе

Российские банки всё чаще замораживают карты клиентов из-за переводов самому себе. В ряде случаев речь идёт лишь о блокировке конкретных операций, но нередко банки ограничивают доступ ко всему счёту. Даже после подтверждения транзакций восстановление доступа происходит не сразу. Как отметил начальник аналитического отдела инвесткомпании «Риком-Траст» Олег Абелев, риск получить крупный штраф или даже лишиться лицензии для банков оказывается важнее риска потерять клиента.

Опрошенные «Известиями» юристы и финансовые эксперты связывают такую практику с тем, что кредитные организации всё чаще перестраховываются, опасаясь серьёзных санкций со стороны регуляторов — Росфинмониторинга и Банка России.

При этом, как отметил управляющий партнёр юридической компании «Провъ» Александр Киселев, под блокировки попадают не только крупные суммы, но и совсем небольшие переводы. На профильных форумах пользователи приводят примеры блокировки карт после перевода всего 150 рублей. Количество подобных случаев, по их словам, продолжает расти.

«Жалобы клиентов на блокировки карт после переводов самому себе сегодня уже не редкость. Рынок захлестнула волна мошенничества, и регулятор требует от банков действовать на опережение. Однако на практике под заморозку всё чаще попадают добросовестные клиенты. В ряде случаев такие меры выглядят чрезмерными и плохо соразмерными реальным рискам», — рассказал директор по стратегии ИК «Финам» Ярослав Кабаков.

«Известия» также привели несколько реальных примеров с форума «Банки.ру». Так, клиент одного из крупнейших банков пытался перевести зарплату на карту другого банка и смог сделать это лишь со второй попытки — после подтверждения по телефону. Через несколько дней при попытке перевести отпускные банк ввёл ограничения, снять которые удалось только при личном визите в офис.

Другой клиент того же банка столкнулся с блокировкой карты при выводе средств с закрытого счёта. Карту разблокировали после звонка на горячую линию, однако уже через неделю её снова заблокировали. Полностью восстановить доступ удалось лишь с пятой попытки. В банке такие действия объяснили «стандартными мерами предосторожности».

В ответ на запрос издания в Банке России напомнили, что кредитные организации обязаны проверять операции клиентов на предмет возможного мошенничества. При этом, сославшись на закон «О национальной платёжной системе», регулятор подчеркнул: банки вправе приостанавливать конкретные операции, но не блокировать счета или карты целиком. Если клиент повторно проводит операцию или подтверждает перевод, банк обязан его исполнить.

Однако в ЦБ также напомнили, что с 1 января перечень подозрительных операций будет расширен. В него, в частности, войдут переводы самому себе через Систему быстрых платежей при определённых условиях — например, если перевод осуществляется человеку, с которым не было операций в течение последних шести месяцев, а менее чем за сутки до этого клиент перевёл самому себе сумму от 200 тыс. рублей. Эти меры были анонсированы ещё в ноябре.

Чтобы снизить риск блокировок, Александр Киселев рекомендует придерживаться привычного финансового поведения: указывать назначение платежа в комментариях, использовать только проверенные устройства и по возможности разделять карты для личных операций и бизнеса.

RSS: Новости на портале Anti-Malware.ru