Зачем вызывать mb_convert_encoding для очистки текста? - PullRequest
Новая
       10

Зачем вызывать mb_convert_encoding для очистки текста?

6 голосов
/ 11 сентября 2009

Это относится к этому (превосходному) ответу . Он утверждает, что лучшее решение для избежания ввода в PHP - это вызвать mb_convert_encoding , за которым следует html_entities .

Но почему именно вы бы вызвали mb_convert_encoding с теми же параметрами к (и UTF8)?

Выдержка из оригинального ответа:

Даже если вы используете htmlspecialchars ($ string) вне тегов HTML, вы по-прежнему уязвимы для векторов атак многобайтовой кодировки.

Самое эффективное, что вы можете сделать, это использовать комбинацию mb_convert_encoding и htmlentities следующим образом. 

$str = mb_convert_encoding($str, 'UTF-8', 'UTF-8');
$str = htmlentities($str, ENT_QUOTES, 'UTF-8');

Есть ли какая-то польза, которую я упускаю?

1 Ответ

7 голосов
/ 12 сентября 2009

Не все двоичные данные действительны в формате UTF8. Вызов mb_convert_encoding с одинаковыми кодировками from / to - простой способ убедиться, что он имеет дело с правильно закодированной строкой для данной кодировки.

Способ использования пропуска проверки UTF8 описан в разделе 6 (соображения безопасности) в rfc2279 :

Другим примером может быть парсер, который запрещает последовательность октетов 2F 2E 2E 2F ("/../"), но разрешает недопустимая последовательность октетов 2F C0 AE 2E 2F.

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

110xxxxx 10xxxxxx # header bits used by the encoding
11000000 10101110 # C0 AE
         00101110 #    2E the '.' character

Другими словами: (C0 AE - header-bits) == '.'

Как указывает цитируемый текст, C0 AE не является допустимой последовательностью октетов UTF8, поэтому mb_convert_encoding удалил бы ее из строки (или перевел бы ее на '.', или что-то еще: -).

...