ggr*_*ner 9 security xss spring jsp jstl
我正在努力防止基于Java,基于Spring的Web应用程序中的跨站点脚本(XSS).我已经实现了一个类似于这个例子的servlet过滤器http://greatwebguy.com/programming/java/simple-cross-site-scripting-xss-servlet-filter/,它清理了应用程序的所有输入.作为额外的安全措施,我还想清理所有JSP中应用程序的所有输出.我做了一些研究,看看如何做到这一点,并找到了两个补充选项.
其中之一是使用Spring的defaultHtmlEscape属性.这很容易实现(web.xml中的几行),当你的输出通过spring的标签之一(即:消息或表单标签)时,它非常有用.我发现的另一个选择是不直接使用EL表达式${...},而是使用<c:out value="${...}" />
第二种方法非常有效,但是由于我正在处理的应用程序的大小(200多个JSP文件).用c:out标签替换EL表达式的所有不当使用是一项非常麻烦的任务.此外,确保所有开发人员都遵守使用c:out标签的惯例(更不用说,代码将更难以理解)将来将成为一项繁琐的任务.
有没有其他方法可以逃避需要更少代码修改的EL表达式的输出?
Bal*_*usC 11
从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 .我建议摆脱所谓的XSS过滤器,并通过使用JSTL <c:out>或fn:escapeXml()(或自定义EL解析器,但这绝对不是正常的方法)集中你在视图侧修复它.未来的代码维护者将非常感激.