Я не фанат термина "входная дезинфекция". Входная дезинфекция - это вводящий в заблуждение термин, который означает, что вы можете махнуть волшебной палочкой c на все данные и сделать их "безопасными данными". Проблема заключается в том, что определение «безопасный» изменяется, когда данные интерпретируются различными частями программного обеспечения, как и требования к кодированию. Точно так же понятие «действительные» данные варьируется в зависимости от контекста - ваши данные могут очень хорошо требовать специальных символов (', ", &, <) - обратите внимание, что SO допускает все это как данные. </p>
Вывод, который может быть безопасным для встраивания в запрос SQL может быть небезопасным для встраивания в HTML. или Swift. или JSON. или команды оболочки. или CSV. И извлечения (или прямого отклонения) значений, чтобы они были безопасными встраивание во все эти контексты (и многие другие) слишком ограничительно.
Так что же нам делать? Убедитесь, что данные никогда не могут причинить вред. Лучший способ добиться этого - избежать интерпретации. данных в первую очередь. Параметризованные SQL запросы являются отличным примером этого: параметры никогда не интерпретируются как SQL, они просто обрабатываются базой данных как данные.
Те же данные может использоваться для других других форматов, таких как HTML. В этом случае данные должны быть закодированы / экранированы для этого конкретного языка в момент их внедрения. S o, чтобы предотвратить XSS, данные должны быть HTML -экранированы (или javascript или URL-адрес экранирован) во время помещения в выходной поток. Не во время ввода. То же самое относится и к другим ситуациям встраивания.
Итак, должны ли мы просто пропустить что-то, через что мы попадаем?
Нет - определенно есть вещи, которые вы можете проверить о пользовательском вводе, но это очень контекстно -зависимая. Давайте назовем это так, как оно есть - проверка. Убедитесь, что это сделано на сервере. Некоторые примеры:
- Обычно вы должны проверять, что любая строка содержит только допустимые символы для ее кодирования (например, нет недопустимых последовательностей UTF-8)
- Если поле должно быть integer, вы, безусловно, можете проверить это поле, чтобы убедиться, что оно содержит целое число (или, возможно, NULL).
- Часто можно проверить, что конкретное значение является одним из набора известных значений (проверка белого списка)
- Вы можете требовать, чтобы большинство полей имели минимальную и максимальную длину.
Почему важно обеспечить действительный UTF-8? Поскольку недопустимые последовательности UTF-8 являются отличным способом обойти проверку (особенно проверку черного списка) или подделать видимый ввод как-то еще. Часто они по-разному интерпретируются разными уровнями технологического стека. См. Есть ли какие-либо ошибки безопасности с UTF-8? для более подробной информации об этом виде атаки.