XSS атака - дезинфицирующий ввод против отклонения

Question

В последнее время заинтересовались XSS и его методами профилактики. Большинство методов предотвращения XSS фокусируются на санации ввода для недопустимых символов и их использовании. Это поднимает вопрос:

Когда очевидно, что целью действительно является атака XSS, почему мы пытаемся убрать недопустимые символы и затем продолжаем использовать ввод вместо прямого отклонения ввода как такового и отправки использования на страницу ошибки?

Я уверен, что все подумали бы об этом подходе, но почему-то основное внимание уделяется проверке входных данных, фильтрации и повторному использованию вместо отклонения. Зачем? Что мне здесь не хватает?

Answer 1

Правило, которое я использую, заключается в том, что я использую проверку ввода, чтобы убедиться, что данные действительны в соответствии с доменом.Если я ожидаю число и получаю строку букв, я отклоняю ее.Однако, если у меня есть текстовое поле, которое может содержать что угодно (например, комментарий о переполнении стека), проверка ввода и отклонение практически невозможны.Так что теперь мне нужно санировать / выводить кодирование.

Answer 2

, поскольку в большинстве случаев при неправильном вводе вы уже показываете страницу ошибки

, например

page.php?id=a33

"select * from table where id = ".((Int)$_GET['id']);

значение "num rows" будет равно 0, поскольку вы ищете:

"select * from table where id = 0";

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

и снова не делатьничто не может расстраивать пользователя.лучше, если санировать и показать предупреждение, если некоторые данные были потеряны