Re: [OT] Cross-site scripting filters
Craig McClanahan wrote: I would imagine pretty much any blogging software that allows restricted HTML in comments (or pretty much any Wiki software that accepts some HTML for formatting, for that matter) has dealt with this kind of issue. Might be worth spelunking open source versions of those projects for ideas. Yep, for sure, I was just hoping someone could save me the time searching :-) Given this is something that should be implemented / used by so many webapps I was kinda surprised I couldn't find anything right off the bat. Maybe it would be a good candidate for a Jakarta sub-project, maybe in commons or something. L. -- 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]
Re: [OT] Cross-site scripting filters
If you wind up writing one and would be so inclined, feel free to contribute it to JWP :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, July 19, 2005 3:21 pm, Laurie Harper said: Craig McClanahan wrote: I would imagine pretty much any blogging software that allows restricted HTML in comments (or pretty much any Wiki software that accepts some HTML for formatting, for that matter) has dealt with this kind of issue. Might be worth spelunking open source versions of those projects for ideas. Yep, for sure, I was just hoping someone could save me the time searching :-) Given this is something that should be implemented / used by so many webapps I was kinda surprised I couldn't find anything right off the bat. Maybe it would be a good candidate for a Jakarta sub-project, maybe in commons or something. L. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Cross-site scripting filters
Frank W. Zammetti wrote: If you wind up writing one and would be so inclined, feel free to contribute it to JWP :) If I end up writing one, I'll definitely contribute it or make it available somewhere! L. -- 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]
Re: [OT] Cross-site scripting filters
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: #60;script type=text/javascript#62;HOSTILE CODE HERE#60;/script#62; 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]
[OT] Cross-site scripting filters
Does anyone know of a good, complete implementation of a cross-site
scripting filter for pre-processing user entered text that needs to be
rendered as HTML? Obviously c:out/ / ${fn:escapeXml()} / etc. aren't the
right solution ;-) but there's nothing in standard JSTL or Struts (that I
know of) that is.
Any pointers appreciated!
L.
--
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]
Re: [OT] Cross-site scripting filters
Thanks; I had a quick hunt through the Javadocs but couldn't see anything
relevant. Can you give me a push in the right direction? ;-)
L.
Frank W. Zammetti wrote:
I have one as part of Java Web Parts
(http://javawebparts.sourceforge.net). Let me know if it suits your needs
(and if not, let me know the shortcomings so I can expand it!)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Mon, July 18, 2005 2:28 pm, Laurie Harper said:
Does anyone know of a good, complete implementation of a cross-site
scripting filter for pre-processing user entered text that needs to be
rendered as HTML? Obviously c:out/ / ${fn:escapeXml()} / etc. aren't the
right solution ;-) but there's nothing in standard JSTL or Struts (that I
know of) that is.
Any pointers appreciated!
L.
--
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]
--
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]
Re: [OT] Cross-site scripting filters
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).
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Mon, July 18, 2005 3:44 pm, Laurie Harper said:
Thanks; I had a quick hunt through the Javadocs but couldn't see anything
relevant. Can you give me a push in the right direction? ;-)
L.
Frank W. Zammetti wrote:
I have one as part of Java Web Parts
(http://javawebparts.sourceforge.net). Let me know if it suits your
needs
(and if not, let me know the shortcomings so I can expand it!)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Mon, July 18, 2005 2:28 pm, Laurie Harper said:
Does anyone know of a good, complete implementation of a cross-site
scripting filter for pre-processing user entered text that needs to be
rendered as HTML? Obviously c:out/ / ${fn:escapeXml()} / etc. aren't
the
right solution ;-) but there's nothing in standard JSTL or Struts (that
I
know of) that is.
Any pointers appreciated!
L.
--
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]
--
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Cross-site scripting filters
On 7/18/05, Laurie Harper [EMAIL PROTECTED] 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. While the code in question here might not help you, the concept of a Filter still can. You can use Filters to monitor (and potentially modify) the output stream by providing a wrapper around the HttpServletResponse that the container hands you, with custom implementations of getOutputStream() and getWriter() that send their output to a buffer instead of directly back to the client. Then, when the client returns, you can postprocess the buffer and weed out anything you think is dangerous. I think there's a sample filter to do GZIP compression in the Tomcat releases, which you could use as a model of the overall architecture. Crag - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Cross-site scripting filters
Yeah, wouldn't help you filter on output, but I pointer that out before :) 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. 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 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: #60;script type=text/javascript#62;HOSTILE CODE HERE#60;/script#62; 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 :-) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Cross-site scripting filters
And if you can't find that compression filter in Tomcat, JWP has one too :) Does GZip and Deflate actualy :) Frank Craig McClanahan wrote: On 7/18/05, Laurie Harper [EMAIL PROTECTED] 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. While the code in question here might not help you, the concept of a Filter still can. You can use Filters to monitor (and potentially modify) the output stream by providing a wrapper around the HttpServletResponse that the container hands you, with custom implementations of getOutputStream() and getWriter() that send their output to a buffer instead of directly back to the client. Then, when the client returns, you can postprocess the buffer and weed out anything you think is dangerous. I think there's a sample filter to do GZIP compression in the Tomcat releases, which you could use as a model of the overall architecture. Crag - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Cross-site scripting filters
I have one as part of Java Web Parts
(http://javawebparts.sourceforge.net). Let me know if it suits your needs
(and if not, let me know the shortcomings so I can expand it!)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Mon, July 18, 2005 2:28 pm, Laurie Harper said:
Does anyone know of a good, complete implementation of a cross-site
scripting filter for pre-processing user entered text that needs to be
rendered as HTML? Obviously c:out/ / ${fn:escapeXml()} / etc. aren't the
right solution ;-) but there's nothing in standard JSTL or Struts (that I
know of) that is.
Any pointers appreciated!
L.
--
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Cross-site scripting filters
Craig McClanahan wrote: While the code in question here might not help you, the concept of a Filter still can. You can use Filters to monitor (and potentially modify) the output stream by providing a wrapper around the HttpServletResponse that the container hands you, with custom implementations of getOutputStream() and getWriter() that send their output to a buffer instead of directly back to the client. Then, when the client returns, you can postprocess the buffer and weed out anything you think is dangerous. I think there's a sample filter to do GZIP compression in the Tomcat releases, which you could use as a model of the overall architecture. Yeah, I grok servlet filters OK ;-) The issue is that filtering the entire response is generally not too helpful for this: it'd disable all the dynamic functionality in the application that's *meant* to be there...! What I need is to allow users to enter HTML markup through a text field for subsequent display as part of a page (think, for example, of a wiki or CMS solution). Only the untrusted data should be filtered, and the submitted HTML must render correctly after potential XSS insertion has been dealt with. Cheers, L. -- 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]
Re: [OT] Cross-site scripting filters
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: #60;script type=text/javascript#62;HOSTILE CODE HERE#60;/script#62; 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]
Re: [OT] Cross-site scripting filters
So it seems like you want to a) render untrusted HTML, and b) render secure html. Sounds like the basic requirement is at odds? You could do something like slashdot and other BB systems do: restrict the amount of valid markup to make your parsing job easier. Another idea, one single regexp won't do it, but have you thought of making multiple passes through the data as a check? You could xlate unicode, remove line splits, perform xml entity substitution, etc., then if it passes, store the original html page as entered. I'm guessing that your requirement is to store and re-present the original markup as entered :-) Also, have you tried doing some research into what the PHP world does to prevent it? It might give a good point of reference for Java. -ed On 7/18/05, Laurie Harper [EMAIL PROTECTED] wrote: 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: #60;script type=text/javascript#62;HOSTILE CODE HERE#60;/script#62; 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Cross-site scripting filters
Ed Griebel wrote: So it seems like you want to a) render untrusted HTML, and b) render secure html. Sounds like the basic requirement is at odds? You could do something like slashdot and other BB systems do: restrict the amount of valid markup to make your parsing job easier. Ultimately, restricting allowed markup helps but doesn't make the hard cases much easier :-) You're right that (a) and (b) conflict somewhat, though. But think about something like Google Mail: it needs to be able to display as much of a user's mail as possible whilst still remaining secure against XSS attacks. Actually, I'm not sure if gmail *does* support showing HTML formatted email off hand, but you see what I mean. Another idea, one single regexp won't do it, but have you thought of making multiple passes through the data as a check? You could xlate unicode, remove line splits, perform xml entity substitution, etc., then if it passes, store the original html page as entered. I'm I'm not sure I want ever to store a modified copy, but the multi-pass regex approach is valid in any case. It's probably the best way to go if you're not willing to use a complete HTML+CSS parser in your XSS filter. guessing that your requirement is to store and re-present the original markup as entered :-) Pretty much, sans XSS hacks, of course :-) Also, have you tried doing some research into what the PHP world does to prevent it? It might give a good point of reference for Java. I spent a little time hunting around in the PHP world today, though I've yet to find anything particularly useful. Most of the implementations I've looked at so far do a fairly minimal job to defeat just the most common sorts of attack. L. -ed On 7/18/05, Laurie Harper [EMAIL PROTECTED] wrote: 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: #60;script type=text/javascript#62;HOSTILE CODE HERE#60;/script#62; 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] -- 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]
Re: [OT] Cross-site scripting filters
On 7/18/05, Laurie Harper [EMAIL PROTECTED] wrote: Ed Griebel wrote: So it seems like you want to a) render untrusted HTML, and b) render secure html. Sounds like the basic requirement is at odds? You could do something like slashdot and other BB systems do: restrict the amount of valid markup to make your parsing job easier. Ultimately, restricting allowed markup helps but doesn't make the hard cases much easier :-) You're right that (a) and (b) conflict somewhat, though. But think about something like Google Mail: it needs to be able to display as much of a user's mail as possible whilst still remaining secure against XSS attacks. I would imagine pretty much any blogging software that allows restricted HTML in comments (or pretty much any Wiki software that accepts some HTML for formatting, for that matter) has dealt with this kind of issue. Might be worth spelunking open source versions of those projects for ideas. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
