Craig wrote:
> I don't know of any generic solutions to the getStrippedHtml() or
> removeScriptTag() methods you propose - but are they still necesary if you
> do the getEscapedHtml() processing on everything?

from my experience no would be the answer.

furthermore simply removing script tags only defeats the more obvious
container for scripts. MSIE exposes this potential vulnerability: (try these
yourself you dont have to mess with a server, just paste them into some html
and pretend ;)

For an IMG tag at least, onreadystatechange is highly likely to be called at
least once by the browser with no input from the user.

<img id=fooimg onreadystatechange="alert('Weve just read your cookie!');"
src="http://jakarta.apache.org/images/jakarta-logo.gif"; height="1" width="1"
border=0>

This can be added to MSIE's/javascript's(?) ability to treat methods as
variables so you can set event handlers for any event fired by other objects
in the DOM from an IMG tag eg 2..

<img id=fooimg onreadystatechange="function
foo(){alert('gotcha!');}document.onmouseover = foo;"
src="http://jakarta.apache.org/images/jakarta-logo.gif"; height="1" width="1"
border=0>


The point being that the vulnerablility is much wider that the script tag, I
don't know for sure but suspect the applet and object tags, at least, expose
this too.

However if you block those tags there is still another way I can set
handlers, using a more widely implemented event such as onmouseover in an
otherwise acceptable tag like <p>

the second example above becomes:
<p onmouseover.="function foo(){alert('gotcha!');}document.onmouseover =
foo;">
whatever I might have been expected to submit in this field
</p>

Hence my own conviction that the only safe option is no HTML in submissions.
However I'd rather escape it on the way in than the way out to reduce load.

d.


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to