1

我们正在将 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中）

谢谢你！

4

2 回答 2

3

这是一个（几千个可能的例子）：

使用这个简单的 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 开发中遵循的模式是，任何来自外部世界的输入在任何时候都被视为恶意输入。任何时候你都在向动态解释器进行编码。

于 2014-10-30T15:02:28.567 回答
0

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

于 2014-10-27T08:02:30.947 回答