Forum Discussion

Approxee's avatar
Approxee
Icon for Nimbostratus rankNimbostratus
Sep 13, 2017

Decode Querystring before ASM inspection

Hi Fourm,

 

I have a situation on an ASM where the whole parameter GET string is encoded. So the ASM raises an illegal Meta Character in parameter name. The ASM does decode this for the logs, but does not seem to decode it to get the name/value pairs.

 

For example, I have something like this - filename.aspx?parametername%3Dfakedata

 

As there is no decocded equals sign, it seems the whole thing as a parameter name and then does decode it to say 'no equals' in parameter name as the exception.

 

How can I double decode the whole section after the ? but before the ASM inspects it to see the name / value pairs ?

 

Graham

 

  • I still have not managed to resolve this, one - tryed loads of things nothing worked

     

    The request URL is filename.aspx?parametername%3Dfakedata - the ASM see's all of this as one paramter name so thinks the parameter name is 'parametername=fakedata' rather than the parameter name being 'parametername' and the value being 'fakedata'. I am assumming this is because it is encoded

     

    The ASM see it like this filename.aspx?parametername=fakedata

     

    I tryed adding 'parametername=' as the parameter name, it excepts it as a parameter but does not match the with the above querystring URL

     

    any idea would be great Graham

     

  • As per rfc2396, the "=" character is reserved and should not be encoded when used as a delimiter between a parameter and it's value.

     

    From RFC 2396 sec 2.4.2:

     

    A URI is always in an "escaped" form, since escaping or unescaping acompleted URI might change its semantics. Normally, the only timeescape encodings can safely be made is when the URI is being createdfrom its component parts; each component may have its own set ofcharacters that are reserved, so only the mechanism responsible forgenerating or interpreting that component can determine whether or not escaping a character will change its semantics. Likewise, a URImust be separated into its components before the escaped characterswithin those components can be safely decoded.

     

    So basically what this means is that when a user agent or http server sees a URL, the very first thing it needs to do is split the URL in to its parts. After all of the parts are separated out, then the URL decoding/encoding can take place. So when we're breaking up the URL in to its components, we're looking for the '?', '&' and '=' characters as delimiters of the query string, query parameter and query value, respectively. Once the delimiters are gone then only the parameter names and values remain which are subject to URL encoding/decoding. If we are encoding then there could possibly be some left over '=' characters, which will likely be thrown in as part of a parameter value named closest to the left of the extra '=' character. If we are decoding then any %3d becomes part of a parameter name or value. For example:

     

    /foo/?bar&baz=bl=eh path: /foo/ query string: bar&baz=bl=eh parameters: bar, baz parameter values: bar: (none) baz: bl=eh

     

    and if we change to /foo/?bar&baz=bl%3deh we get the same exact results because we can decode after we separate the URL in to its components:

     

    parameter values: bar: (none) baz: bl%39eh => (decode) => bl=eh