Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

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

0
Rate this Question
Comments on this Question
Comment made 1 month ago by GreeceMonkey 246

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

0

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

1
Comments on this Answer
Comment made 1 month ago by GreeceMonkey 246

Hi Thank you very much form your response. I did find a work around, but it is not perfect. My main aim, was to stop the violations and logging as I knew this kind of a viewstate parameter.

I Created a wildcard parameter of parametername* and then allowed the = in the parameter name. It has had the affect I was looking for but I agree with the above that the = is a special character

Thanks you for your reponse and help

Graham

0