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中看到它有一个标志来规范化输入String。我知道规范化是＆＃34;解码＆＃34;所以任何编码的String都以纯文本转换。

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

任何人都可以通过使用规范化来显示将要阻止的攻击样本吗？（在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 Filter Evasion Cheat表。

您的应用程序是否使用jquery？以下输入是有意义的：

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

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

实际上，输入编码比在保护XSS时进行输入过滤更重要。（如果我 HAD 只选择一个......）

您希望在Web开发中遵循的模式是任何来自外部世界的输入始终被视为恶意的模式。您在转移到动态解释器时进行编码。

Answer 2

数据的规范化也是关于将数据导出到其基本形式。因此，如果我们采用不同的方案，其中涉及文件路径（相对/符号链接）及其相关目录权限，我们需要首先规范化路径然后验证否则它将允许某人在未经许可的情况下通过传递目标可接受地探索这些文件数据

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

2 个答案: