2

我的一个 REST API 有一个名为“partners”的查询参数，它是一个整数列表，因此您可以在 URL 中指定多个值。作为 XSS 攻击的预防措施，我使用 ESAPI 去除输入中的恶意内容。这是问题所在：

我注意到 ESAPI 编码器 cannonicalize 方法（它使用默认编解码器：HTMLEntityCodec、PercentCodec、JavaScriptCodec）会更改查询参数值，因为它认为 &p 或 &pa 是某种编码。请参阅下面的示例

就像是

http://localhost:8080/product?partner=1

按预期工作。

另一方面，像

http://localhost:8080/product/?pidentity=1&pidentity=2

规范化后的输入变为

   `pidentity=1πdentity=2`

框架无法解析，因为它认为这只是一个带有 2 个拆分器的查询参数。

如果请求 url 像

http://localhost:8080/product?partner=1&partner=2

规范化后的输入变为

partner=1∂rtner=2

&pa 更改为 '∂'。

正如您可能猜到的，我尝试更改查询参数的名称并且效果很好（可能是因为没有任何相应的编码）。有没有人见过，或者可以指导我是什么导致了这种行为？这听起来像是我的经验不足，但为了确保防止 XSS 攻击，我不确定是否应该尝试从默认编码器中删除任何编解码器。

4

1 回答 1

4

您当前使用的方法是我们目前所说的“大锤”方法，您尝试对整个 URL 进行编码，而不是对由不受信任的来源（即用户）提供的不受信任或受污染的数据进行编码

最好的方法是单独编码每个参数的值，而不是尝试将整个参数字符串编码为单个数据。输出编码的主要目的是消除用户使用他们提供的数据将“数据”上下文分解为“控制”上下文的可能性。

在您的示例中，字符串 partner=1&partner=2 在解析器中看起来像这样

合作伙伴= 1 &合作伙伴= 2

（粗体是控制，斜体是数据） - 您只想对字符串的数据上下文进行编码，因为不受信任的源不提供控制上下文。

如果用户是您提供的数据1&partner=2您的编码字符串应该看起来像

合作伙伴= 1%26合作伙伴=2 &合作伙伴= 2

这里的另一个重要注意事项是，规范化用于将给定的字符串简化为最基本的格式 - 因此提供的字符串中的所有编码都将被解码，因此无法执行双重和混合编码攻击。

对您的问题的简短回答是单独编码参数的值，而不是编码整个 URL 参数字符串。

参考：

于 2013-07-15T20:51:48.043 回答