GF wrote:
It could be a solution, but:
<a href="javascript:alert("bye")">Greet</a>
simply works.
Unfortunately simply HTML Escaping the href attribute isn't
satisfactory. It would corrupt valid javascript.
eg.
<a href="javascript:alert('1&2>3='+(1&2>3));">Link A</a>
HTML escaped is not equivalent:
<a href="javascript:alert('1&2>3='+(1&2>3));">Link B</a>
As Martin suggested, you could write code that parses the attribute to
ensure it's not prematurely terminated by a quote. The complication is
that it can't replace double quotes/single quotes with an html
equivalent as it will need to be aware of quote nesting and escaping,
and the tag implementation doesn't know whether the template uses a
single quote or double quote to open the attribute. This problem has
been solved plenty of times before though.
Despite all that, the developer of the tag library did decide to html
escape all the scripting-event attributes already (onclick etc) so maybe
I'm making a pointless point.
More importantly, the developer needs to ensure user-entered data is
escaped, which brings us back to s:url's encode attribute and the use of
variables generally.
Perhaps it would be more useful if could easily escape variables before
inserting them into the HTML:
eg. as per freemarker notation:
<s:a href="%{url?html}"></s:a>
I've used this reliably before
<s:a href="%{encode(url)}">link</s:a>
or
<a href="%{encode(url)}">link</a>
Where encode is a function in the context.
Similarly this will work:
<a href="[EMAIL PROTECTED]@encode(url)}">link</a>
The developer knows best whether a variable can be trusted in the
current context and there are sufficient tools at his disposal to
protect against this particular XSS vulnerability. I agree it may be
useful if s:url encoded the entire query string through.
cheers,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
