使用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开发中遵循的模式是，任何来自外部世界的输入都会一直被视为恶意输入。只要你把代码交给一个动态解释器，你就可以进行编码。

Answer 2

数据的规范化还涉及到将数据导出为其基本形式。因此，如果我们采取一种不同的方案，其中涉及文件路径(相对/symlink)及其联合目录权限，我们需要首先规范化该路径，然后验证，否则它将允许某人在没有许可的情况下通过传递目标可接受数据来浏览这些文件。