Antonio Petrelli wrote:
2008/1/13, Jeromy Evans <[EMAIL PROTECTED]>:
I don't think this is a critical problem sheerly because the high
prevalence of such vulnerabilities means some of the responsibility
falls on the developer to not trust user-entered data..
This is not the case: I think it is a bug, since the url in <s:url>
should be *parsed* before, extracting the eventual querystring and its
parameters.
Yes, I agree it's an issue. I just don't think it's a "critical"
vulnerability.
Dave Newton wrote:
Is this an IE-only thing?
When I do this w/ FF or Safari I get an encoded parameter and it doesn't
execute the JavaScript :/
Yes, it's specific to IE in that IE doesn't URLEncode all invalid URLs.
However, it broadly applies to any user agent that allows an illegal URL
to be submitted (which is what someone would use if trying to when
trying out such an exploit).
URL's mergeRequestParameters method calls UrlHelper's parseQueryString, which
in turn calls Java's URLEncoder.encode; while I haven't spent a lot of time
tracking execution I guess I thought this was the path taken for any GET
parameters.
I agree. I haven't dug into the code any further, but I think the
specific issue is that s:url URLEncodes the supplied parameters (as
you'd expected) but the base URL may already contain unencoded characters.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
