我想用XSS保护我的Sping Boot 应用程序。我用Spring Security实现了Sping Boot Boot应用程序。此外，我有第二个应用程序（前端）工作在不同的端口（不同的起源）-这就是为什么我不能设置内容安全策略为'自我'，以防止XSS攻击。
如何实现基本的XSS防护，过滤掉所有传入请求中的可疑字符串？编辑：
我找到了这篇文章：但是这个项目使用的ESAPI库是相当大的，减慢了应用程序，所以我想找到不同的，更容易的方法。
pxiryf3j1#
通用过滤器可能不可靠。通常最好对输入进行验证，并对输出单独进行编码，因为什么是有效的，需要什么编码取决于值及其上下文。要做的主要事情是在必要的地方应用正确的编码，并小心使用值的地方。请参阅OWASP XSS Prevention页面。Baeldung的文章使用ESAPI.encoder().canonicalize(value)来解码以&、%或\开头的各种序列。如果这些字符在任何输入中都是有效字符，那么解码会破坏输入，不应该这样做。如果它们无效，那么应该拒绝输入。如果输入确实是恶意的，那么无论如何都不应该处理它。所以对ESAPI的调用可能是：
ESAPI.encoder().canonicalize(value)
&
%
\
if(value.matches(".*[\\\\%&].*")) { throw new RuntimeException("Invalid character"); }
字符串
mm5n2pyu2#
优先清理输出而不是输入，以防止XSS攻击。
编码器可能会非常激进，并改变原始输入。因此，如果您的电子邮件ID包含@，它可能会转换为@，从而改变输入的整个含义并破坏功能。
@
@
输入验证对于数据完整性非常重要。例如，在将其保存到数据库之前检查它是否是有效的电子邮件。这种验证本质上可以防止攻击者将脚本数据保存在数据库中 （xss攻击的上半部分）。但是，有些输入字段本质上是非常开放的，例如：评论框或html编辑器。这些输入无法验证。
在数据库中有html脚本并不是xss攻击的主要原因，但在html中渲染时执行它们会导致问题。因此，在XSS的上下文中，始终使用编码器（如ESAPI.encodeForHTML()）对输出进行编码，输入验证是可选的，并且有很多原因。
ESAPI.encodeForHTML()
如果你的UI是一个使用Angular，React等技术的单页应用程序。那么你可能不需要从BE编码你的输出。因为，这些技术将确保将脚本（如果有的话）呈现为纯文本，而不是执行它们。
2条答案
按热度按时间pxiryf3j1#
通用过滤器可能不可靠。通常最好对输入进行验证，并对输出单独进行编码，因为什么是有效的，需要什么编码取决于值及其上下文。
要做的主要事情是在必要的地方应用正确的编码，并小心使用值的地方。请参阅OWASP XSS Prevention页面。
Baeldung的文章使用
ESAPI.encoder().canonicalize(value)来解码以&、%或\开头的各种序列。如果这些字符在任何输入中都是有效字符，那么解码会破坏输入，不应该这样做。
如果它们无效，那么应该拒绝输入。如果输入确实是恶意的，那么无论如何都不应该处理它。所以对ESAPI的调用可能是：
字符串
mm5n2pyu2#
优先清理输出而不是输入，以防止XSS攻击。
输入清理问题：
编码器可能会非常激进，并改变原始输入。因此，如果您的电子邮件ID包含
@，它可能会转换为@，从而改变输入的整个含义并破坏功能。输入验证：
输入验证对于数据完整性非常重要。例如，在将其保存到数据库之前检查它是否是有效的电子邮件。这种验证本质上可以防止攻击者将脚本数据保存在数据库中 （xss攻击的上半部分）。但是，有些输入字段本质上是非常开放的，例如：评论框或html编辑器。这些输入无法验证。
输出清理：
在数据库中有html脚本并不是xss攻击的主要原因，但在html中渲染时执行它们会导致问题。因此，在XSS的上下文中，始终使用编码器（如
ESAPI.encodeForHTML()）对输出进行编码，输入验证是可选的，并且有很多原因。XSS和SPA（Angular/React）
如果你的UI是一个使用Angular，React等技术的单页应用程序。那么你可能不需要从BE编码你的输出。因为，这些技术将确保将脚本（如果有的话）呈现为纯文本，而不是执行它们。