Профилактика XSS в веб-приложении JSP / Servlet

XSS можно предотвратить в JSP с помощью функции JSTL или fn:escapeXml() EL, когда (re) отображает управляемый пользователем вход . Сюда входят параметры запроса, заголовки, cookies, URL, тело и т. Д. Все, что вы извлекаете из объекта запроса. Также во время повторного отображения пользовательский вход из предыдущих запросов, который хранится в базе данных, должен быть экранирован.

Например:

Это позволит избежать символов, которые могут исказить отображаемый HTML, такой как < , > , " , ' и & в HTML / XML-сущности, такие как < > , " &

Обратите внимание, что вам не нужно избегать их в коде Java (Servlet), поскольку они безвредны там. Некоторые могут отказаться от них во время обработки запроса (как в Servlet или Filter) вместо обработки ответа (как и в JSP), но таким образом вы можете рискнуть, что данные без необходимости получают двойное экранирование (например, & вместо этого & и, в конечном счете, конечный пользователь увидит & будет представлен) или что данные, хранящиеся в базе данных, становятся не переносимыми (например, при экспорте данных в JSON, CSV, XLS, PDF и т. д., которые не требуют HTML-экранирования вообще). Вы также потеряете социальный контроль, потому что вы больше не знаете, что пользователь действительно заполнил. Вы, как администратор сайта, действительно хотели бы знать, какие пользователи / IP-адреса пытаются выполнить XSS, чтобы вы могли легко отслеживать их и принять соответствующие меры. Эвакуация во время обработки запроса должна использоваться и использоваться только в качестве последнего курорта, когда вам действительно нужно как можно скорее исправить крушение поезда плохо разработанного старого веб-приложения в кратчайшие сроки. Тем не менее, вы должны в конечном итоге переписать свои JSP-файлы, чтобы они стали безопасными для XSS.

Если вы хотите повторно отобразить управляемый пользователем ввод как HTML, в котором вы хотите разрешить только определенный поднабор HTML-тегов, например , , и т. Д., Тогда вам необходимо дезинформировать ввод Белый список. Для этого можно использовать парсер HTML, например Jsoup . Но гораздо лучше ввести дружественный человеку язык разметки, такой как Markdown (также используемый здесь в Stack Overflow). Затем для этого можно использовать анализатор Markdown, например CommonMark . Он также встроил средства для очистки HTML. См. Также Я ищу Java-кодировщик Java .

Единственной проблемой на стороне сервера в отношении баз данных является предотrotation внедрения SQL . Вы должны убедиться, что вы никогда не связываете строки с пользовательским контролем прямо в запросе SQL или JPQL и что вы используете параметризованные запросы полностью. В терминах JDBC это означает, что вы должны использовать PreparedStatement вместо Statement . В терминах JPA используйте Query .

Альтернативой могло бы быть переход от JSP / Servlet к Java EE MVC framework JSF . Он имеет встроенную поддержку XSS (и CSRF!) По всему месту. См. Также предотrotation атак CSRF, XSS и SQL Injection в JSF .

Несколько раз попробовато как-предупредить-xss. В StackOverflow вы найдете много информации. Кроме того, на веб-сайте OWASP имеется обходной лист защиты, который вы должны пройти.

В библиотеках для использования библиотека ESAPI OWASP имеет java-вкус. Вы должны попробовать это. Кроме того, каждая используемая вами инфраструктура имеет некоторую защиту от XSS. Опять же, веб-сайт OWASP содержит информацию о большинстве популярных фреймворков, поэтому я бы рекомендовал пройти через их сайт.

Мне повезло с OWASP Anti-Samy и советником AspectJ на всех моих controllerах Spring, которые блокируют XSS от входа.

 public class UserInputSanitizer { private static Policy policy; private static AntiSamy antiSamy; private static AntiSamy getAntiSamy() throws PolicyException { if (antiSamy == null) { policy = getPolicy("evocatus-default"); antiSamy = new AntiSamy(); } return antiSamy; } public static String sanitize(String input) { CleanResults cr; try { cr = getAntiSamy().scan(input, policy); } catch (Exception e) { throw new RuntimeException(e); } return cr.getCleanHTML(); } private static Policy getPolicy(String name) throws PolicyException { Policy policy = Policy.getInstance(Policy.class.getResourceAsStream("/META-INF/antisamy/" + name + ".xml")); return policy; } } 

Вы можете получить советника AspectJ из этой записи stackoverflow

Я думаю, что это лучший подход, тогда c: особенно, если вы делаете много javascript.

Для управления XSS требуется несколько проверок, данные с клиентской стороны.

1. Входные проверки (проверка формы) на стороне сервера. Есть несколько способов обойти это. Вы можете попробовать проверку JAR 303 bean validation ( hibernate validator ) или ESAPI Input Validation . Хотя я еще не пробовал это (пока), есть аннотация, которая проверяет безопасный html (@SafeHtml) . Фактически вы можете использовать валидатор Hibernate с Spring MVC для проверки бонусов -> Ref
2. Удаление запросов URL-адреса – для всех ваших HTTP-запросов используйте какой-то фильтр XSS. Я использовал следующее для нашего веб-приложения, и он заботится о очистке HTTP-запроса URL-адреса – http://www.servletsuite.com/servlets/xssflt.htm
3. Выходные данные / html возвращаются клиенту (смотрите выше при объяснении @BalusC).

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

Skipfish – это инструмент с открытым исходным кодом от Google, который я изучал : он находит довольно много вещей и, похоже, стоит использовать.

Нет простого, готового решения для XSS. API OWASP ESAPI поддерживает некоторую поддержку, которая очень полезна, и у них есть библиотеки тегов.

Мой подход состоял в том, чтобы в основном расширить tags stuts 2 следующими способами.

1. Модифицируйте тег свойства s: property, чтобы он мог принимать дополнительные атрибуты, указывающие, какого рода экранирование требуется (escapeHtmlAttribute = “true” и т. Д.). Это предполагает создание новых classов Property и PropertyTag. Класс Property использует OWASP ESAPI api для экранирования.
2. Измените шаблоны freemarker, чтобы использовать новую версию свойства s: и установите экранирование.

Если вы не хотите изменять classы на шаге 1, другим подходом было бы импортировать tags ESAPI в шаблоны freemarker и, при необходимости, бежать. Затем, если вам нужно использовать как: тег свойства в вашем JSP, оберните его и тегом ESAPI.

Я написал здесь более подробное объяснение.

http://www.nutshellsoftware.org/software/securing-struts-2-using-esapi-part-1-securing-outputs/

Я согласен, что выходные данные не идеальны.

Мое личное мнение заключается в том, что вам следует избегать использования JSP / ASP / PHP / etc страниц. Вместо этого выведите в API, похожий на SAX (только для вызова, а не для обработки). Таким образом, существует один слой, который должен создать хорошо сформированный вывод.

Если вы хотите автоматически избежать всех переменных JSP без явного переноса каждой переменной, вы можете использовать EL-резольвер, как подробно описано здесь, с полным источником и примером (JSP 2.0 или новее) и более подробно обсуждаться здесь :

Например, используя вышеупомянутый EL-резольвер, ваш JSP-код останется таким же, но каждая переменная будет автоматически экранирована

 ...  
${item.name}
 
${item.price}
 
${item.description}
  ... 

Если вы хотите принудительно экранировать по умолчанию весной, вы можете также подумать об этом, но он не ускользает от EL-выражений, просто вывод тегов, я думаю:

http://forum.springsource.org/showthread.php?61418-Spring-cross-site-scripting&p=205646#post205646

Примечание. Другой подход к экранированию EL, который использует преобразования XSL для препроцессорных JSP-файлов, можно найти здесь:

http://therning.org/niklas/2007/09/preprocessing-jsp-files-to-automatically-escape-el-expressions/