Альтернатива использованию c: out для предотвращения XSS - PullRequest
Новая
       79

Альтернатива использованию c: out для предотвращения XSS

9 голосов
/ 17 декабря 2010

Я работаю над предотвращением межсайтового скриптинга (XSS) в веб-приложении на базе Java, Spring.Я уже реализовал фильтр сервлетов, подобный этому примеру http://greatwebguy.com/programming/java/simple-cross-site-scripting-xss-servlet-filter/, который очищает все входные данные в приложение.В качестве дополнительной меры безопасности я хотел бы также очистить все выходные данные приложения во всех JSP.Я провел некоторое исследование, чтобы понять, как это можно сделать, и нашел два дополнительных варианта.

Одним из них является использование атрибута Spring * defaultHtmlEscape.Это было очень легко реализовать (несколько строк в web.xml), и оно прекрасно работает, когда ваш вывод проходит через один из тегов Spring (то есть: теги message или form).Другой вариант, который я нашел, заключается в том, чтобы напрямую не использовать выражения EL, такие как ${...}, а вместо этого использовать <c:out value="${...}" />

. Этот второй подход работает отлично, однако из-за размера приложения, над которым я работаю+ Файлы JSP).Это очень громоздкая задача - заменить все несоответствующие выражения EL тегом c:out.Кроме того, в будущем стало бы обременительной задачей убедиться, что все разработчики придерживаются этого соглашения об использовании тега c:out (не говоря уже о том, насколько более нечитабельным будет код).

Есть ли альтернативаспособ избежать вывода выражений EL, которые потребовали бы меньше модификаций кода?

Ответы [ 3 ]

11 голосов
/ 17 декабря 2010

Начиная с Servlet 2.5 / JSP 2.1, вы можете создать пользовательский ELResolver, который это делает.Вы можете зарегистрировать его в ServletContextListener#contextInitialized(). 

@Override
public void contextInitialized(ServletContextEvent event) {
    JspFactory.getDefaultFactory()
        .getJspApplicationContext(event.getServletContext())
        .addELResolver(new YourCustomELResolver());
}

В ELResolver#getValue() вы могли бы выполнить побег.

Ваш единственныйпроблема в том, что вы не сможете отображать HTML там, где это разрешено (то есть уже очищены от вредоносных тегов / атрибутов с помощью своего белого списка, так что в итоге вы получите невинные теги, такие как Jsoup может сделать).

Тем не менее я не согласен с необходимостью избегать XSS во время ввода на Filter, как вы упомянули в 1-м абзаце вопроса.Вы рискуете двойным побегом.Вам нужно избегать его только в той точке, где он может нанести вред, т. Е. Прямо в той части представления, где он будет встроен в HTML, output .Я рекомендую избавиться от этого так называемого XSS-фильтра и сконцентрировать ваше внимание на его исправлении на стороне обзора, используя JSTL <c:out> или fn:escapeXml() (или собственный распознаватель EL, но это определенно не нормальный подход).Будущие сопровождающие кода будут очень благодарны.

1 голос
/ 24 апреля 2011

Я согласен, вам не нужно использовать c: out для каждой переменной.Я написал блог, описывающий, почему на http://tech.finn.no/2011/04/08/xss-protection-whos-responsibility/

Это затрагивает многое из того, что здесь сказано.

1 голос
/ 06 января 2011

В этом блоге описывается пользовательский ELResolver, который экранирует значения выражений EL типа String.Регистрация этого пользовательского ELResolver вызовет выход из всех выражений EL.В исключительных случаях, когда JSP должен программно выводить HTML, вам необходим механизм, который не включает выражение EL, такой как пользовательский тег или скриптлет: 

<%= "Java expression hopefully returning safe HTML" %>
...