[Esapi-user] canonicalizing troubles
jeff.williams at aspectsecurity.com
Fri Jan 15 15:27:24 UTC 2016
Yep. It is frustrating. But that querystring is a little ambiguous if it ever gets sent to the browser. You have to canonicalize for all potential downstream systems and any parsing quirks they might have -- which is really hard, particularly for the browser. In some cases it limits the syntax of what you are allowed to use. It's an unfortunate syntax collision that stems from having 5+ separate parsers and escaping schemes in the browser. Madness.
On Fri, Jan 15, 2016 at 6:23 AM -0800, "Greene, Geoffrey N" <geoffrey.n.greene at boeing.com<mailto:geoffrey.n.greene at boeing.com>> wrote:
That’s an idea I guess. The real problem was that I wasn’t the one canonicalizing… it was deep inside of SecureResponseWrapper.getQueryString(), and I believe it was throwing a “multiple encoding error”, because I had &NEW=%3F or something like that.
I worked around it for my puposes by writing a getRawQueryString for this one case…but I still think it is incorrect, as there really isn’t a problem with that particular query string.
From: Jeff Williams [mailto:jeff.williams at aspectsecurity.com]
Sent: Thursday, January 14, 2016 6:59 PM
To: Greene, Geoffrey N; esapi-user at lists.owasp.org
Subject: Re: [Esapi-user] canonicalizing troubles
The problem is that some browsers (and I haven't tested in years) allow HTML entities without the semi-colon. What if an attack sneaks through using non-terminated entities? Do you to canonicalize the whole querystring? Maybe you could getParameter and canonicalize individually.
From: Greene, Geoffrey N <geoffrey.n.greene at boeing.com<mailto:geoffrey.n.greene at boeing.com>>
Sent: Thursday, January 14, 2016 5:27 PM
Subject: [Esapi-user] canonicalizing troubles
To: <esapi-user at lists.owasp.org<mailto:esapi-user at lists.owasp.org>>
I have been having some difficulty canonicalizing:
Consider this string:
When ESAPI canonicalizes this string, it incorrectly sees &NE and thinks this is encoded, so it translates this as
a.go?OLD=b≠W=c – that’s the not equals symbol – it doesn’t seem to realize that it should be looking for the additional semicolon, and so it treats &NEW as <not-equals>W
There are be other examples of this, but &NEW seems like a common parameter name to have
Here’s an example of a test:
public void esapiTest()
String input2 = "a.go?OLD=b&NEW=c";
String canon = ESAPI.encoder().canonicalize(input2);
As a result, all my calls to request.getQueryString() fail when my parameter names start with certain characters because it doesn’t canonicalize properly.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Esapi-user