java - 使用 OWASP ESAPI 时是否需要启用规范化？

Question

我们正在将 ESAPI 2.x(owasp java 安全库)添加到应用程序中。

虽然相当重复，但更改很容易。我们正在向所有输入参数添加验证，以便确保组成它们的所有字符都在白名单内。

就是这样:

Validator instance = ESAPI.validator();
Assert.assertTrue(instance.isValidInput("test", "xxx@gmail.com", "Email", 100, false));

然后在validation.properties文件中设置电子邮件模式，如下所示:

Validator.Email=^[A-Za-z0-9._%'-]+@[A-Za-z0-9.-]+\\.[a-zA-Z]{2,4}$

简单!

鉴于输入验证后，数据变得可信，我们不会对输出进行编码。

我可以在 ESAPI 中看到它有一个标志来规范化输入字符串。我知道规范化是“反编码”，因此任何编码的字符串都会转换为纯文本。

问题是。为什么我们需要规范化？

任何人都可以展示使用规范化可以防止的攻击示例吗？ (在java中)

谢谢!

Answer 1

这是一个(数千个可能的示例):

采用这个简单的 XSS 输入:

<script>alert('XSS');</script>
//Now we URI encode it:
%3Cscript%3Ealert(%27XSS%27)%3B%3C%2Fscript%3E

//Now we URI encode it again:

%253Cscript%253Ealert(%2527XSS%2527)%253B%253C%252Fscript%253E

对已编码一次的输入进行规范化将得到原始输入，但在 ESAPI 的情况下，第三个输入将抛出 IntrusionException，因为永远不存在用户输入的有效用例。 URI 编码不止一次。在这个特定的示例中，规范化意味着“所有 URI 数据都将被简化为其实际的字符表示形式”。顺便说一句，ESAPI 实际上不仅仅是 URI 解码。如果您希望使用正则表达式(大多数应用程序中正则表达式的主要用途)执行安全和/或业务验证，这一点很重要。

至少，规范化可以为您提供良好的保证，确保将恶意输入偷偷进入应用程序并不容易:目标是限制已知的良好值(白名单)并拒绝其他所有内容。

关于您在这里的不明智评论:

We are not encoding output given that after the input validation, data becomes trusted.

这是一个肮脏的事实:Javascript、XML、JSON 和 HTML 都不是“常规语言”。它们是不确定的。实际上，这意味着编写正则表达式来拒绝所有将 HTML 或 Javascript 插入应用程序的尝试在数学上是不可能的。看看我上面发布的 XSS 过滤器规避备忘单。

您的应用程序使用 jquery 吗？以下输入是恶意的:

$=''|'',_=$+!"",__=_+_,___=__+_,($)[_$=($$=(_$=""+{})[__+__+_])+_$[_]+(""+_$[-__])[_]+(""+!_)[___]+($_=(_$=""+!$)[$])+_$[_]+_$[__]+$$+$_+(""+{})[_]+_$[_]][_$]((_$=""+!_)[_]+_$[__]+_$[__+__]+(_$=""+!$)[_]+_$[$]+"("+_+")")()

因此，在输出给用户时，您必须对所有数据进行编码，以获得正确的上下文，这意味着如果该数据将首先输入到javascript 函数，然后显示为 HTML，您先编码为 Javascript，然后编码为 HTML。如果其输出到 HTML 数据字段(例如默认输入框)，您可以将其编码为 HTML 属性。

在防止 XSS 方面，进行输出编码实际上比进行输入过滤更重要。 (如果我不得不只选择一个......)

您希望在 Web 开发中遵循的模式是，来自外界的任何输入始终被视为恶意。您可以在任何时候将其交给动态解释器进行编码。