Frank W. Zammetti wrote:
Yeah, wouldn't help you filter on output, but I pointer that out before :)
True enough :)
Note that it does allow you to specify your own regex, so in reality you
can filter for whatever you want. I did this specifically so when
someone spots something I didn't think of it's easy to make it catch
those too.
The trouble is, I doubt it would be possible to construct a single regex
that did a robust job -- including handling of character references (as in
my example), differing syntax rules in embedded CSS, browser's recombining
keywords like 'javascript' that are split over multiple lines, etc. etc...
FYI, while I find it ironic to reference a Microsoft resource on a
security exploit, they actually do have a decent little page about XSS...
http://support.microsoft.com/default.aspx?scid=kb;en-us;252985
The solutions it discusses, though, really don't help much when the
requirement is to render untrusted HTML. There's a lot more detail on
what's involved in some of the CERT advisories, for example:
http://www.cert.org/advisories/CA-2000-02.html
http://www.cert.org/tech_tips/malicious_code_mitigation.html
L.
Frank
Laurie Harper wrote:
Frank W. Zammetti wrote:
Not a problem...
http://javawebparts.sourceforge.net/javadocs/index.html
In the javawebparts.filter package, you should see the
CrossSiteScriptingFilter.
This will filter any incoming parameters, and optionally attributes
(good
for if your forwarding somewhere) for a list of characters (you can
alter
what it looks for via regex).
Ah, I initially skipped that package, thinking a servlet filter wasn't
really what I was after. Browsing through the code, it seems I was right.
For one thing, I want to filter text on output, not filter request
parameters on input. But more important, your filter only checks for
(and rejects) anything with a few particular characters -- all of
which are valid in most cases from an XSS-prevention standpoint.
For what it's worth, injecting XSS attacks through that filter is
pretty easy. For example, the following wouldn't be caught:
<script type="text/javascript">HOSTILE CODE
HERE</script>
I'm hoping I can find something that addresses all the nefarious XSS
strategies out there. It's not easy to implement something that's
complete, especially when you try to deal with embedded CSS in the
HTML you're trying to sanitize...!
Thanks for the link though :-)
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
