Атаки на регулярное выражение и кодирование - Как работает внутреннее кодирование в PHP?

Question

Я использую регулярное выражение UTF-8 для получения частей строки заголовка Content-Type:, так как я имею привычку настраивать свои серверы для последовательного использования UTF-8.

// example type, actually this will be negotiated from request `Accept:` header line.
$content_type = 'TeXt/HtMl';
preg_match('~^([\w-]+\*?)/([\w-]+\*?)$~ui', $content_type, $matches);

Я рассматриваю возможность загрузки классов из пути файловой системы, построенного на основе совпадений подшаблона.

Есть ли какой-нибудь мыслимый способ внедрить некоторые '/../' путем кодирования атак? Как работает внутренняя кодировка в целом? Нужно ли заботиться о том, какая кодировка запроса закодирована при обработке данных в коде PHP, или преобразование работает автоматически и надежно? Что еще нужно помнить о безопасности кодирования? Как можно обеспечить кодирование в развернутом коде, работающем на неизвестных системах?

EDIT: Как указано в комментариях, некоторый дополнительный код может выглядеть, например, например ::1010*

m1 = strtolower($matches[1]);
m2 = strtolower($matches[2]);
include_once "/path/to/project/content_handlers/{$m1}_{$m2}";

Замечания: Мой вопрос должен был быть более общим. Давайте подумаем о некотором сценарии: PHP-скрипт кодируется в UTF-8. Файловая система сервера кодируется в наборе символов A. Клиент обрабатывает запрос, который будет отправлен в кодировке B. Существует ли потенциальный риск того, что принятый заголовок написан таким образом, что функции preg_ * не распознают какой-то '/../' (родительский каталог ) но файловая система? Вопрос не ограничен конкретным регулярным выражением в примере. Может ли злоумышленник включить произвольные файлы, присутствующие в файловой системе, если не предпринять дальнейшие меры предосторожности?

Замечания 2: В представленном примере я не могу положиться на http_negotiate_content_type, так как не уверен, установлен ли pecl_http на целевом сервере. Также есть скриптовый полифилл. Опять же: это , а не вопрос для конкретного случая. Я хочу узнать, как обрабатывать (даже манипулировать) клиентские кодировки в целом.

Замечания 3: Здесь обсуждается некоторая похожая проблема (с атаками кодирования SQL): Достаточно ли подготовленных операторов PDO для предотвращения внедрения SQL? Однако мой вопрос касается кодировки файловой системы. Может ли случиться нечто подобное?

Answer 1

Я буду смелым и скажу, что ваш код будет эффективно предотвращать вредоносные подстроки.Если кто-то пытается украсть последовательность символов, он будет сбит preg_match().Использование якорей и классов персонажей не дает места для маневра.Шаблон хорош и строг.

Всего пара замечаний:

1. \w уже не чувствителен к регистру, поэтому модификатор шаблона i не требуется.
2. Ваши группы захвата хранятся в $matches[1] и $matches[2].Совпадение полной строки: $matches[0].

Код:

$content_type = 'TeXt/HtMl';
if (!preg_match('~^([\w-]+\*?)/([\w-]+\*?)$~u', $content_type, $matches)) {
    echo "invalid content type";
} else {
    var_export($matches);
}

Вывод:

array (
  0 => 'TeXt/HtMl',
  1 => 'TeXt',
  2 => 'HtMl',
)