PHP Type Juggling: как нестрогое сравнение превращается в обход аутентификации

PHP, будучи языком с динамической типизацией, позволяет удобно сравнивать данные различных типов. Однако эта особенность, известная как автоматическое приведение типов (Type Juggling), может стать источником критических уязвимостей, таких как обход аутентификации, особенно в контексте проверок безопасности.

Для разработчика это выглядит как полезная функция, позволяющая сравнить строку с числом без явных преобразований. Для специалиста по безопасности — как потенциальная возможность обойти проверки паролей, HMAC-подписей, токенов или логики авторизации. Понимание принципов Type Juggling критически важно для анализа безопасности PHP-приложений.

Суть Type Juggling

В PHP переменные не имеют жестко закрепленного типа, и интерпретатор часто пытается привести данные к наиболее подходящему виду при выполнении операций.

Например:

$a = '10';
$b = 10;
var_dump($a == $b);   // true

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

Операторы сравнения: `==` против `===`

В PHP есть два основных оператора сравнения:

Нестрогий: `==`
Строгий: `===`

Разница между ними имеет огромное значение для безопасности. Оператор `===` выполняет строгое сравнение, проверяя как значение, так и тип операндов.

'10' === 10; // false (строка и целое число - разные типы)

Оператор `==`, напротив, пытается привести оба значения к одному типу перед сравнением:

'10' == 10;  // true (строка '10' приводится к числу 10)

Эта особенность становится опасной, когда разработчик использует `==` при проверке:

Паролей
Токенов
HMAC-подписей
Идентификаторов
Результатов криптографических функций

Большинство атак, связанных с Type Juggling, используют именно нестрогое сравнение.

Наиболее опасные преобразования

Для понимания уязвимостей важно знать несколько правил приведения типов:

Если PHP видит строку, похожую на число, он попытается превратить её в число. Пример: `'15' == 15` вернет `true`.
Если строка начинается с цифры, интерпретатор использует только числовую часть. Пример: `'123admin' == 123` вернет `true`.
В старых версиях PHP (до PHP 8) строки, начинающиеся с нуля (`'0admin' == 0`) или не содержащие цифр вообще (`'admin' == 0`), также могли приводиться к нулю, возвращая `true`. Начиная с PHP 8, часть таких сравнений была изменена, но старые приложения всё ещё подвержены этим уязвимостям.

Научная нотация (Scientific notation) — ключевой трюк

Одной из самых известных особенностей Type Juggling является интерпретация научной нотации.

PHP воспринимает строку `'1e3'` как число `1000`. Соответственно, сравнение `'1e3' == 1000` вернет `true`.

Гораздо более интересным является случай, когда строка вроде `'0e12345'` интерпретируется как `0 × 10^12345`, то есть как обычный ноль.

Следовательно, `'0e12345' == 0` будет истинным. На этом принципе построена одна из самых известных атак — "магический хеш".

Что такое Magic Hash

Представим, что приложение проверяет пароль следующим образом:

if (md5($password) == $stored_hash) {
    // пользователь авторизован
}

Разработчик считает, что сравниваются две строки. Однако оператор `==` работает иначе. Если обе строки, являющиеся результатом хеширования (например, MD5), начинаются с `0e` и содержат только цифры, PHP преобразует их в число 0.

Например:

'0e462097431906509019562988736854'

'0e830400451993494058024219903391'

после преобразования становятся нулем. Поэтому сравнение этих двух разных строк через `==` вернет `true`.

Такие значения называются "магическими хешами". Если приложение использует нестрогое сравнение, подбор второго такого хеша позволяет обойти проверку. Это часто встречается в старых CTF-задачах, где конструкция `if (md5($input) == $hash)` является прямым указанием на поиск магического хеша.

Проблема массива вместо строки

Magic Hash — не единственный способ эксплуатации Type Juggling. Часто проблемы возникают из-за того, что PHP позволяет передать массив там, где ожидается строка.

Это происходит благодаря механизму обработки HTTP-параметров. Если отправить запрос вида `?token[]=123`, PHP автоматически сформирует массив: `$_GET['token'] = ['123']`. То же самое работает для POST-параметров и даже Cookie. Многие разработчики не учитывают эту особенность, ожидая получить всегда строку.

Когда функции возвращают NULL вместо ошибки

Ранние версии PHP (до PHP 8) довольно мягко относились к ошибкам типов. Многие встроенные функции, получив параметр неверного типа (например, массив вместо строки), не прекращали выполнение программы. Вместо этого они выдавали предупреждение (Warning) и возвращали `NULL`.

Долгое время одной из таких функций была `hash_hmac()`. Рассмотрим пример проверки подписи:

if (hash_hmac('sha256', $_COOKIE['session'], $key) == $_COOKIE['hmac']) {
    // пользователь авторизован
}

Если вместо строки `$_COOKIE['session']` передать массив (например, `Cookie: session[]=admin`) и пустой `hmac` (`Cookie: hmac=`), в старых версиях PHP произойдет следующее:

`hash_hmac()` получит массив вместо строки.
Функция выдаст Warning.
Вернет `NULL`.
Будет выполнено нестрогое сравнение: `NULL == ''`.

Для оператора `==` сравнение `NULL == ''` является истинным. Таким образом, проверка подписи успешно обходится, даже если корректный HMAC не был предоставлен. Этот сценарий демонстрирует опасность одновременного использования нестрогого сравнения и отсутствия проверки типов входных данных.

Изменения в PHP 8 и остаточные риски

С выходом PHP 8 правила нестрогого сравнения были пересмотрены. Например, конструкция `'admin' == 0` теперь возвращает `false` (в PHP 7 это было `true`). Это устранило многие неочевидные сравнения строк и чисел.

Однако важно понимать, что Type Juggling не исчез полностью. Во-первых, множество корпоративных приложений до сих пор работает на PHP 7.4 и более ранних версиях. Во-вторых, некоторые уязвимости возникают не из-за сравнения строки с числом, а из-за некорректной обработки `NULL`, массивов или результатов криптографических функций. Поэтому при тестировании безопасности всегда нужно учитывать используемую версию PHP.

Что искать пентестеру

При анализе PHP-приложений стоит обращать внимание на следующие признаки потенциальных уязвимостей Type Juggling:

Использование операторов `==` или `!=` вместо `===` и `!==`.
Сравнение результатов функций хеширования (`md5()`, `sha1()`, `hash()`) или HMAC (`hash_hmac()`).
Проверка токенов или цифровых подписей.
Старые проекты на PHP 5.x или PHP 7.x.
Нестандартные механизмы аутентификации.
Проверки, где пользователь может влиять на тип входных данных (например, через HTTP-параметры).

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

Как защититься

Большинство уязвимостей, связанных с Type Juggling, устраняются достаточно простыми правилами:

Всегда использовать `===` и `!==` для сравнений, особенно в логике безопасности.
Проверять тип пользовательских данных перед их использованием в бизнес-логике.
Использовать функцию `hash_equals()` для безопасного сравнения криптографических значений, чтобы предотвратить атаки по времени и Type Juggling.
Не полагаться на автоматическое приведение типов.
Обновлять приложения до современных версий PHP.
Явно отклонять массивы там, где ожидается строка.
Использовать строгий режим анализа кода и статические анализаторы для выявления потенциально опасных сравнений.

Также следует помнить, что функция `in_array()` по умолчанию использует нестрогое сравнение. Чтобы избежать этого, всегда используйте третий параметр: `in_array($value, $array, true)`.

Главное, что нужно запомнить

Type Juggling — наглядный пример того, как удобная особенность языка может стать серьезной проблемой безопасности. Автоматическое приведение типов само по себе не является уязвимостью, но становится ею, когда используется при проверке критически важных для безопасности данных: паролей, HMAC-подписей, токенов или результатов криптографических функций.

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

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