ESAPI编码器规范化更改查询参数 [英] ESAPI encoder canonicalize changing query parameters

问题描述

我的一个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 
  / pre> 
 
 
规范化后的输入变为
  partner = 1 rtner = 2 
  
 And& pa更改为∂。您可能猜到，我尝试更改查询参数的名称，并且正常工作（可能是因为没有任何相应的编码）。有没有人看过之前，还是可以引导我一定是这样的行为呢？这可能听起来像我没有经验，但是为了确保防止XSS攻击，我不知道我是否应该尝试从默认编码器中删除任何编解码器。
解决方案
您正在使用的方法是我们目前所称的Big Hammer方法，您正在尝试对整个网址进行编码，而不是对不可信或受污染的数据进行编码不信任的来源（即用户）
 
 
 
最好的方法是单独编码每个参数的值，而不是尝试将整个参数字符串编码为单个数据片段输出编码的主要目的是消除用户将数据上下文分解为具有所提供数据的控制上下文的可能性。 
 
 
 
在您的示例中，字符串伙伴= 1& partner = 2看起来像一个解析器
 
 
  partner =   1  & partner =   2  
 
 
（其中，粗体是控件和斜体是数据） - 您只想对控件中的字符串的数据上下文进行编码
 
 
 
如果您的用户是您提供的数据 1& partner = 2 ，您的编码字符串应该像
 
 
  partner =   1％26partner = 2   & partner =   2  
 
 
另一个重要的注意事项是规范化用于简化给定的字符串是最基本的格式 - 所以提供的字符串中的所有编码都将被解码，以便无法执行双重和混合编码攻击。
 
 
 
问题是单独编码参数的值，而不是编码整个URL参数字符串。
 
 
 
参考文献：
 
 
 
 
 
  https://www.owasp.org/index.php/ Double_Encoding  
 
 
  https：//www.owasp .org / index.php / Mixed_encoding  
 
 
  https://www.owasp.org/index.php/Category:Encoding  
 
 
 
One of my REST APIs have a query parameter named "partners" which is an List of Integers, so you can specify multiple values in the URL. As a prevention for XSS attacks, I am stripping out malicious content in the input using ESAPI. Here is the problem:

I noticed that the ESAPI encoder cannonicalize method (which uses the default codecs: HTMLEntityCodec,PercentCodec,JavaScriptCodec), changes the query parameter values, because it thinks that &p or &pa is some kind of encoding. See examples below 

Something like
http://localhost:8080/product?partner=1
Works as expected. 

On the other hand something like
http://localhost:8080/product/?pidentity=1&pidentity=2
The input after canonicalizing becomes
   `pidentity=1πdentity=2`
Which the framework has trouble parsing since it thinks this is only one query parameters with 2 splitters.

If the request url is like 
http://localhost:8080/product?partner=1&partner=2
The input after canonicalizing becomes
partner=1∂rtner=2
And &pa is changed to '∂'. 

As you can probably guess, I tried changing the name of the query param and it worked fine (probably because there was not any corresponding encoding). Has anyone seen that before, or can guide me what must be causing such behavior? This may sound like my inexperience, but in order to ensure prevention from XSS attacks, I am not sure if I should try to remove any codecs from the default encoder.
解决方案
The approach you are currently using is what we currently refer to as the "Big Hammer" approach where you are attempting to encode the entire URL as opposed to encoding the untrusted or tainted data being supplied by an untrusted source (ie, a user)

The best approach to this would be to encode the values of each parameter individually rather than attempting to encode the entire parameter string as a single piece of data. The primary purpose of output encoding is to eliminate the possibility of a user breaking out the the "data" context to a "control" context with the data they are providing. 

In your example, the string partner=1&partner=2 looks like this to a parser

  
partner=1&partner=2
(Where bold is control and italic is data) - you only want to encode the data context of the string since the control context is not provided by the untrusted source.

If a user were your provide the data 1&partner=2 your encoded string should look like

  
partner=1%26partner=2&partner=2
Another important note here is that canonicalization is used to simplify a given string to it's most base format - so all encoding in the provided string will be decoded so that double and mixed encoding attacks cannot be performed.

The short answer to your question is to encode the values of the parameters individually as opposed to encoding the entire URL parameter string.

References: 


https://www.owasp.org/index.php/Double_Encoding
https://www.owasp.org/index.php/Mixed_encoding
https://www.owasp.org/index.php/Category:Encoding


                        
这篇关于ESAPI编码器规范化更改查询参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！