Отфильтровывать закодированное содержание javascript из запроса

Question

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

Это в основном для защиты от атак XSS, и идеальным механизмом будет проверка ввода и кодирование вывода, но из-за некоторых ограничений я не могу работать с выходным концом.

Все, что я могу сделать в это время, это попытаться очистить входные данные через фильтр. Я использую ESAPI для канонизации входных параметров, а также использую jsoup с наиболее строгой опцией Whitelist.none() для удаления всего HTML.

Это работает до тех пор, пока вредоносный javascript находится в некоторых тегах HTML, но не работает для URL с кодом javascript без какого-либо HTML-кода вокруг него, например:

http://example.com/index.html?a=40&b=10&c='-prompt``-' 

в конечном итоге показывает предупреждение на странице. Это то, что я делаю сейчас:

param = encoder.canonicalize(param, false, false);
param = Jsoup.clean(param, Whitelist.none());

Итак, вопрос:

• Есть ли какой-нибудь способ, с помощью которого я могу убедиться, что мой ввод лишен всего HTML и javascript кода в фильтре?
• Должен ли я добавить некоторые проверки регулярных выражений, но есть ли какие-либо регулярные выражения, которые позаботятся о случаях, которые проходят проверку, которую я имею сейчас?

Answer 1

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ:

Если выходное экранирование не разрешено в вашем интернет-решении, вы находитесь в СЦЕНАРИИ НЕТ-ВЫИГРЫШ. Это как антивирус в Windows: вы сможете обнаруживать определенные и известные атаки, но вы не сможете обнаружить или защитить от неизвестных атак. Если ваш работодатель настаивает на этом, ваша должная осмотрительность заключается в том, чтобы проинформировать руководство об этом и получить письменное согласие с рисками . Каждый раз, когда я сталкивался с этим с управлением, они выбирали правильное решение - выходной выход.

================================================== ==============

Прежде всего... будьте осторожны при использовании JSoup в любой ситуации очистки / фильтрации / проверки ввода.

При получении недействительного HTML, как

<script>alert(1);

Jsoup добавит в пропавший </script> тег.

Это означает, что если вы используете Jsoup для "очистки" HTML, он сначала преобразует INVALID HTML в VALID HTML, прежде чем начнет обработку.

Итак, вопрос: есть ли какой-нибудь способ, с помощью которого я могу убедиться, что мой ввод очищен от всего HTML и кода JavaScript в фильтре? Должен ли я добавить некоторые проверки регулярных выражений, но есть ли какие-либо регулярные выражения, которые позаботятся о случаях, которые проходят проверку, которую я имею сейчас?

Нет. Проверка входных данных ESAPI и ESAPI не подходит для вашего варианта использования, поскольку HTML не является обычным языком, а входные данные ESAPI для его проверки являются регулярными выражениями. Дело в том, что вы не можете делать то, что просите:

Есть ли какой-нибудь способ, с помощью которого я могу убедиться, что мой ввод лишен всего HTML и javascript кода в фильтре?

И все же есть работающее веб-приложение, которое требует пользовательский HTML/JavaScript.

Вы можете немного сложить колоду в свою пользу: я бы выбрал что-то вроде HTML Oitasit OWASP. и протестируйте свою реализацию на входах XSS, перечисленных здесь.

Многие из этих входных данных взяты из шпаргалки XW Filter OWASP и, по крайней мере, будут использовать ваше приложение против известных попыток. Но вы никогда не будете в безопасности без выхода продукции.

=================== ОБНОВЛЕНИЕ ОТ КОММЕНТАРИЙ ==================

ТАК, случай использования должен попытаться заблокировать все html и javascript. Я рекомендую реализовать Caja, поскольку он инкапсулирует HTML, CSS и Javascript.

Javascript, тем не менее, также трудно управлять из-за проверки ввода, потому что, как и HTML, JavaScript является нерегулярным языком. Кроме того, каждый браузер имеет свою собственную реализацию, которая отличается от спецификации ECMAScript. Если вы хотите защитить свой ввод от интерпретации, это означает, что в идеале вам нужно иметь анализатор для каждого семейства браузеров, пытающихся интерпретировать ввод пользователя, чтобы заблокировать его.

Когда все, что вам действительно нужно сделать, это убедиться, что выход экранирован. Извините, что победили мертвую лошадь, но я должен подчеркнуть, что выходной выход в 100 раз важнее, чем отказ от пользовательского ввода. Вы хотите и то и другое, но если принудительно выбрать один или другой, экранирование вывода в целом будет менее трудоемким.