You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Laurie Harper <la...@holoweb.net> on 2005/07/18 20:28:47 UTC
[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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Cross-site scripting filters
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 <la...@holoweb.net> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Cross-site scripting filters
Posted by Laurie Harper <la...@holoweb.net>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Cross-site scripting filters
Posted by Craig McClanahan <cr...@gmail.com>.
On 7/18/05, Laurie Harper <la...@holoweb.net> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Cross-site scripting filters
Posted by Laurie Harper <la...@holoweb.net>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Cross-site scripting filters
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Cross-site scripting filters
Posted by Laurie Harper <la...@holoweb.net>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Cross-site scripting filters
Posted by Craig McClanahan <cr...@gmail.com>.
On 7/18/05, Laurie Harper <la...@holoweb.net> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Cross-site scripting filters
Posted by Laurie Harper <la...@holoweb.net>.
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 <la...@holoweb.net> 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:
>>>>
>>>> <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: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Cross-site scripting filters
Posted by Ed Griebel <ed...@gmail.com>.
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 <la...@holoweb.net> 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:
> >>
> >> <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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Cross-site scripting filters
Posted by Laurie Harper <la...@holoweb.net>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Cross-site scripting filters
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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:
>
> <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 :-)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Cross-site scripting filters
Posted by Laurie Harper <la...@holoweb.net>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Cross-site scripting filters
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: user-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>
>
> --
> Laurie, Open Source advocate, Java geek and novice blogger:
> http://www.holoweb.net/laurie
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Cross-site scripting filters
Posted by Laurie Harper <la...@holoweb.net>.
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: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Cross-site scripting filters
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org