ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ:
Если выходное экранирование не разрешено в вашем решении, ориентированном на Интернет, вы находитесь в ПРОБЛЕМНОМ СЦЕНАРИИ. Это как антивирус в Windows: вы сможете обнаруживать конкретные и известные атаки, но не сможете обнаружить или защититься от неизвестных атаки. Если ваш работодатель настаивает на этом пути, вы должны должным образом уведомить руководство об этом факте и получить от него согласие на риски в письменной форме. Каждый раз, когда я спорил с руководством при этом они выбрали правильное решение - экранирование вывода.
================================================================
Прежде всего... будьте осторожны при использовании JSoup в любой ситуации очистки/фильтрации/проверки ввода.
При получении недопустимого HTML, например
<script>alert(1);
Jsoup добавит недостающий тег </script>.
Это означает, что если вы используете Jsoup для «очистки» HTML, он сначала преобразует НЕДЕЙСТВИТЕЛЬНЫЙ HTML в ДЕЙСТВИТЕЛЬНЫЙ HTML, прежде чем он начнет обработку.
Итак, вопрос: есть ли способ, с помощью которого я могу убедиться, что мой ввод лишен всего кода HTML и javascript в фильтре? Должен ли я добавить некоторые проверки регулярных выражений, но есть ли какое-либо регулярное выражение, которое позаботится о случаях, которые проходят проверку, которая у меня есть прямо сейчас?
Нет. ESAPI и проверка ввода ESAPI не подходят для вашего варианта использования, поскольку HTML не является обычным языком, а ввод ESAPI для его проверки являются регулярными выражениями. Дело в том, что вы не можете делать то, о чем просите:
Есть ли способ, с помощью которого я могу убедиться, что мой ввод лишен всего кода HTML и javascript в фильтре?
И по-прежнему иметь функционирующее веб-приложение, для которого требуется определяемый пользователем HTML/JavaScript.
Вы можете немного сложить колоду в свою пользу: я бы выбрал что-то вроде HTML-санитайзер OWASP. и протестируйте свою реализацию на входных данных XSS, перечисленных здесь.
Многие из этих входных данных взяты из шпаргалки OWASP по уклонению от XSS-фильтра и, по крайней мере, будут проверять ваше приложение против известных попыток. Но вы никогда не будете в безопасности без экранирования вывода.
===================ОБНОВЛЕНИЕ ИЗ КОММЕНТАРИЙ==================
Таким образом, вариант использования — попытаться заблокировать все html и javascript. Я рекомендую реализовать caja, так как он инкапсулирует HTML, CSS и Javascript.
Javascript, однако, также трудно управлять проверкой ввода, потому что, как и HTML, JavaScript не является обычным языком. Кроме того, у каждого браузера есть собственная реализация, которая по-разному отличается от спецификации ECMAScript. Если вы хотите защитить свой ввод от интерпретации, это означает, что в идеале вам нужно иметь синтаксический анализатор для каждого семейства браузеров, пытающихся интерпретировать пользовательский ввод, чтобы заблокировать его.
Когда все, что вам действительно нужно сделать, это убедиться, что вывод экранирован. Извините, что побил дохлую лошадь, но я должен подчеркнуть, что экранирование вывода в 100 раз важнее, чем отклонение пользовательского ввода. Вам нужны оба, но если вас заставят выбрать один или другой, выходное экранирование в целом будет менее трудоемким.
person
avgvstvs
schedule
29.03.2016
