Re: Cross site scripting issue
Oops, bad example. I guess this is generally more of a problem in a case such as . Script injection through CSS is an IE-specific vulnerability; it supports a non-standard style property (called behaviour? can't recall off hand) which can execute, at least, Javascript. L. Adam Ruggles wrote: /Nope. What about ? Or Javascript injection through CSS in IE? What about any new Javascript injection mechanism that some browser adds down the line... ;-) / Which browser did you get this injection to work on? Other than fixing the misspelling of alert, I couldn't get the javascript to execute in the div align tag in any of the browsers I tried (IE 6, Firefox 2, Safari 2). Laurie Harper wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe, Joseph McGranaghan wrote: So, tags I'm originally NOT allowing are:
Re: Cross site scripting issue
I read somewhere about making sure the charset was what you want, like
iso-8859-1,
so that your filter doesn't get circumvented by a different charset and
subsequently, malicious code getting rendered.
Do you know what I mean by this?
If so, do you know how to enforce this?
-Joe
Laurie Harper wrote:
Joseph McGranaghan wrote:
Better safe than sorry ;-) As someone else posted, though, you also
have to be wary of things like "java\nscript:alert('scripty')" in
attribute values and other 'interesting' variations. Same for CSS
style rules. As mentioned above, IE supports invoking behaviour from
CSS.
Ya I mentioned this. I a regex like so: "java\\s*script"
Needs to be case-insensative.
That's not sufficient though. As I pointed out in my last post, there
are lots of ways of 'fooling' that check. For example,
'java&#xx;cript' (where 'xx' is the Unicode code point for the letter
's').
Also, if you have more than one application attached to the same
database, and any one of them has a faulty input filter, SQL
injection bug or whatever, it will result in all your apps being
exposed / affected.
Nice, I'll keep that in mind.
Right now my db is on the same server though, so I don't believe this
is a problem.
Am I wrong?
It doesn't matter what server the database is on, it matters how many
sources of HTML input there are. If you only have one app connecting
to that database, the point is moot.
L.
-
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: Cross site scripting issue
/Nope. What about ? Or Javascript injection through CSS in IE? What about any new Javascript injection mechanism that some browser adds down the line... ;-) / Which browser did you get this injection to work on? Other than fixing the misspelling of alert, I couldn't get the javascript to execute in the div align tag in any of the browsers I tried (IE 6, Firefox 2, Safari 2). Laurie Harper wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe, Joseph McGranaghan wrote: So, tags I'm originally NOT allowing are:
Re: Cross site scripting issue
Joseph McGranaghan wrote:
Better safe than sorry ;-) As someone else posted, though, you also
have to be wary of things like "java\nscript:alert('scripty')" in
attribute values and other 'interesting' variations. Same for CSS
style rules. As mentioned above, IE supports invoking behaviour from CSS.
Ya I mentioned this. I a regex like so: "java\\s*script"
Needs to be case-insensative.
That's not sufficient though. As I pointed out in my last post, there
are lots of ways of 'fooling' that check. For example, 'java&#xx;cript'
(where 'xx' is the Unicode code point for the letter 's').
Also, if you have more than one application attached to the same
database, and any one of them has a faulty input filter, SQL injection
bug or whatever, it will result in all your apps being exposed /
affected.
Nice, I'll keep that in mind.
Right now my db is on the same server though, so I don't believe this is
a problem.
Am I wrong?
It doesn't matter what server the database is on, it matters how many
sources of HTML input there are. If you only have one app connecting to
that database, the point is moot.
L.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross site scripting issue
Down below... Laurie Harper wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe, Joseph McGranaghan wrote: So, tags I'm originally NOT allowing are:
Re: Cross site scripting issue
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe, Joseph McGranaghan wrote: So, tags I'm originally NOT allowing are:
Re: Cross site scripting issue
Thanks for the feedback Chris. Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe, Joseph McGranaghan wrote: So, tags I'm originally NOT allowing are:
Re: Cross site scripting issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe, Joseph McGranaghan wrote: > So, tags I'm originally NOT allowing are: > >
Re: Cross site scripting issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe, Joseph McGranaghan wrote: > Ok, this is my argument for filtering input: (Note that I'm sure we can argue all day over whether input vs. output filtering is better; I'd prefer to state my opinion and get on with it). > 1) I don't want bad code (javascript or other) making into my db in the > first place, ever. You can't prevent this unless you are sure your cleansing algorithm is correct. If you are confident in your cleansing algorithm and you feel better about input filtering, go ahead and do it. I'm certainly not going to stop you. > 5) My XSS stuff is in one class, easy to maintain. This should be a given. > I guess I just don't see an argument for filtering it on the way out. > What if you miss something? What if you miss something on the way out? If you miss something on tht way out, you could easily have missed it on the way in. This is not a valid question. I assert that it's easier (in real practice) to modify an output cleanser than an input cleanser, since you have to go back and re-clean all your old data. That's pretty much it. App servers scale horizontally; if you can't afford the CPU cycles to clean on output with your current deployment, then buy more app servers. DB servers are trickier, and when you need to re-clean a great deal of data in your database, the CPU cycle cost is much more. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+rMH9CaO5/Lv0PARAhWLAJ9aDghyvFWKVr5p4mcbQbOd/PuEUwCgsSQ3 jmPC/HuMcViG7RITSB3oP8g= =hQF0 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross site scripting issue
--- Leon Rosenberg wrote: > Hmm, the OP said: >> I am trying to find a best solution to prevent >> Cross site scripting attacks. Oops. Yep, I guess I latched on to the discussion after the "but I need to allow markup" bit; sorry. > Allowing the user to inject HTML markup in your > pages is the road to hell anyway. Yeah, it sucks, but sometimes it's a reality. I've never (I think) needed to support more than the obvious formatting tags; I just stripped out any attributes and left only the tags. Lately I had to support tags but I only allowed a single name or id attribute (and it's not public-access anyway) and I may just switch over to using something like Textile/etc. and not worry about it at all. > But hey, feel free to email me the urls of the sites > which allow markup, we will find some "other" usage > for them. :p d. TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross site scripting issue
Ok, I'm going to pay attention to the problem, the XSS filter: I am using a 'blacklist', because my users need to enter as much X\HTML as I can possibly allow them. So, tags I'm originally NOT allowing are:
Re: Cross site scripting issue
--- Joseph McGranaghan <[EMAIL PROTECTED]> wrote: > I guess I just don't see an argument for filtering > it on the way out. What if you miss something? Couldn't you miss it on the way in, too? d. We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross site scripting issue
Ok, this is my argument for filtering input:
1) I don't want bad code (javascript or other) making into my db in the
first place, ever.
2) You have to validate as input comes in anyways and THIS is where your
validation logic is housed:
- if field is Date, check it; 'username' then ^[a-zA-Z0-9]{5,20}$ ,
if allow HTML, filter for XSS
3) HTML code is a lot of characters and a DB can only hold so much, so I
want to filter/condense here anyways.
4) Of course for any nonHTML output fields, I can use tag to
output and encode anyways.
5) My XSS stuff is in one class, easy to maintain.
I guess I just don't see an argument for filtering it on the way out.
What if you miss something?
-Joe
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joseph,
Joseph McGranaghan wrote:
I [hear that worrying about XSS is not worth it] all the time, am I
missing something?
What if you want the user to be able to input all kinds of
markup to be redisplayed:
http://somewhere.com";>somewhere
At some point this makes it back into the page so the browser can render
it.
If this discussion is useless, I am severely misguided and probably
wasting time.
You have a special case when you /want/ to allow users to use HTML
markup. Leon was pointing out that spending a lot of time running all
input through an XSS-sanitizer is not worth it.
If you /are/ capturing text you will be using that /can/ contain HTML
markup, then cleaning it as it comes in is still a mistake. Let's say
you have a bug in your cleansing code. In that case, bad stuff gets into
your database where it's hard to root out and fix.
If you always run "normal" output through a '<' and '>' filter, and then
always run your "HTML" output through your XSS cleanser, then you're
always okay as long as your XSS cleaner is up-to-date. That is, if you
have to make a change to the XSS-cleaner, then all output benefits,
instead of having /some/ clean input and some not-so-clean input that
you will blindly output at a later time.
I agree with Leon: cleaning input is not usually a good idea. Cleaning
output is where the real money is -- from a security and maintainability
standpoint.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF+c979CaO5/Lv0PARAo/+AKCMJIAe42ulV4Wg1dSWwVBLgeAk2wCeNRKF
zaXOtvr4eW+dbpR3Va/5ktA=
=A+z6
-END PGP SIGNATURE-
-
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: Cross site scripting issue
Hi Dave, On 3/16/07, Dave Newton <[EMAIL PROTECTED]> wrote: --- Leon Rosenberg wrote: > And even with an rdbms, have you ever tried to > update like 1.000.000 rows of an in production db > under traffic? Stuff like that happens all the time, although I tend to do such things at low-traffic times or on a replicated DB (yeah, moving it back takes time too, but that's data for ya'). but its much more expensive and complicated as code change, which, at least in a jsp, can usually be performed without any implications. Changing a data in the db usually requires some downtime or you have to run a java programm which changes the data via public interfaces (so the caches and pojos/ejbs whatever components remain in consistent state), which are usually not designed for such mass data access. If the traffic is that high then running it through that huge regexp on each output will be expensive too. > First of all the user data remain untouched. This > could have some legal issues. If that's a huge problem, then duplicate the data; one raw, one filtered. > Than, encoding is cheaper as regexp. Much cheaper. > And you have to encode anyway, since you want to > deliver valid html, wan't you? Encoding? Not if you want the HTML to contain markup, which was what the OP said. Hmm, the OP said: I am trying to find a best solution to prevent Cross site scripting attacks. Nothing about markup. Allowing the user to inject HTML markup in your pages is the road to hell anyway. But hey, feel free to email me the urls of the sites which allow markup, we will find some "other" usage for them. > 2. Avoiding DOS exposition since filtering, > especially with regexp, is very expensive. If you need to remove only specific (X)HTML element *attributes* it's going to be expensive anyway. It's cheaper to do it once Markup aside, normally (which is default) eliminates 99% of XSS vulnerability (at least all of it I found here: http://ha.ckers.org/xss.html) and is pretty cheap. regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross site scripting issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dale, Dale Newfield wrote: > Christopher Schultz wrote: >> If you /are/ capturing text you will be using that /can/ contain HTML >> markup, then cleaning it as it comes in is still a mistake. Let's say >> you have a bug in your cleansing code. In that case, bad stuff gets into >> your database where it's hard to root out and fix. > > If that data is hard to find than you haven't cleanly defined your DB > schema. Not at all. Even if all of your input has to go into a single field in a single table, re-running input cleaning scripts on millions of records is not a great strategy. > WHEN to do the cleaning is not a question of security and > maintainability, but a question of amortizing clock cycles to try to get > responses out to browsers as quickly as possible. There is no reason to > clean the same piece of text with the same algorithm more than once, so > why not do it on the input side? I believe I made that clear in my first post. > If you find a bug in your cleansing > code, then once you change it, re-run it ONCE on all the potentially > dangerous text blocks. That could be problematic if you have a lot of data. >> I agree with Leon: cleaning input is not usually a good idea. Cleaning >> output is where the real money is -- from a security and maintainability >> standpoint. > > I'd be happy to change my mind if you can you suggest any other reason > to re-do that work more frequently than changes to the filtering module > / data that backs the filtering module? What happens when you want to print it out in an unescaped form? I'm not sure I can come up with a great use case for that right now, but that's the reason nobody HTML escapes all the data they put in their databases: it's not always destined for a web page display. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+pCW9CaO5/Lv0PARAkTsAJ9uQnDUAQTaVzUdoJLQ6WAhWd1uOQCgqgj1 x6DP+fcnSOo6KlAI6L5TUy4= =qrK2 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross site scripting issue
--- Leon Rosenberg wrote: > And even with an rdbms, have you ever tried to > update like 1.000.000 rows of an in production db > under traffic? Stuff like that happens all the time, although I tend to do such things at low-traffic times or on a replicated DB (yeah, moving it back takes time too, but that's data for ya'). If the traffic is that high then running it through that huge regexp on each output will be expensive too. > First of all the user data remain untouched. This > could have some legal issues. If that's a huge problem, then duplicate the data; one raw, one filtered. > Than, encoding is cheaper as regexp. Much cheaper. > And you have to encode anyway, since you want to > deliver valid html, wan't you? Encoding? Not if you want the HTML to contain markup, which was what the OP said. > 2. Avoiding DOS exposition since filtering, > especially with regexp, is very expensive. If you need to remove only specific (X)HTML element *attributes* it's going to be expensive anyway. It's cheaper to do it once. You might, btw, need to watch out for content and/or functionality generated via CSS/styling; I don't think this is an issue with IE yet, but w/ Moz-based browsers it *might* be. d. Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross site scripting issue
On 3/16/07, Dale Newfield <[EMAIL PROTECTED]> wrote: There are two discussions here that are getting convoluted: WHEN to "clean" and HOW to clean. I still have yet to find a good comprehensive way to do the latter (more below), but right here I'm responding to the former. Christopher Schultz wrote: > If you /are/ capturing text you will be using that /can/ contain HTML > markup, then cleaning it as it comes in is still a mistake. Let's say > you have a bug in your cleansing code. In that case, bad stuff gets into > your database where it's hard to root out and fix. If that data is hard to find than you haven't cleanly defined your DB schema. There are more persistent storages between hell and heaven than a rdbms. And even with an rdbms, have you ever tried to update like 1.000.000 rows of an in production db under traffic? WHEN to do the cleaning is not a question of security and maintainability, but a question of amortizing clock cycles to try to get responses out to browsers as quickly as possible. There is no reason to clean the same piece of text with the same algorithm more than once, so why not do it on the input side? If you find a bug in your cleansing code, then once you change it, re-run it ONCE on all the potentially dangerous text blocks. Those should map directly to columns in your DB. If you can't look at your DB schema and tell me which columns are displayed without escaping their contents, then something is wrong. If you CAN look at the DB at say what are displayed where, than there is something wrong with you application design. Or you are a decoding genius if you can recalculate in mind what exactly N levels of abstraction do with each data chunk. But its probably too theoretical. As for There is no reason to clean the same piece of text with the same algorithm more than once, so why not do it on the input side? There are many. First of all the user data remain untouched. This could have some legal issues. Especially in case your filtering does a bit too much. Than, encoding is cheaper as regexp. Much cheaper. And you have to encode anyway, since you want to deliver valid html, wan't you? > I agree with Leon: cleaning input is not usually a good idea. Cleaning > output is where the real money is -- from a security and maintainability > standpoint. I'd be happy to change my mind if you can you suggest any other reason to re-do that work more frequently than changes to the filtering module / data that backs the filtering module? 1. Avoiding content destruction through bugs in your filtering module. 2. Avoiding DOS exposition since filtering, especially with regexp, is very expensive. 3. You have to encode the output html anyway, so why doing something twice? 4. Updates in the filtering/encoding logic can be applied on the fly since you dont have to change any data. And i assume there are some more :-) regards Leon -Dale Newfield [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross site scripting issue
There are two discussions here that are getting convoluted: WHEN to "clean" and HOW to clean. I still have yet to find a good comprehensive way to do the latter (more below), but right here I'm responding to the former. Christopher Schultz wrote: If you /are/ capturing text you will be using that /can/ contain HTML markup, then cleaning it as it comes in is still a mistake. Let's say you have a bug in your cleansing code. In that case, bad stuff gets into your database where it's hard to root out and fix. If that data is hard to find than you haven't cleanly defined your DB schema. WHEN to do the cleaning is not a question of security and maintainability, but a question of amortizing clock cycles to try to get responses out to browsers as quickly as possible. There is no reason to clean the same piece of text with the same algorithm more than once, so why not do it on the input side? If you find a bug in your cleansing code, then once you change it, re-run it ONCE on all the potentially dangerous text blocks. Those should map directly to columns in your DB. If you can't look at your DB schema and tell me which columns are displayed without escaping their contents, then something is wrong. I agree with Leon: cleaning input is not usually a good idea. Cleaning output is where the real money is -- from a security and maintainability standpoint. I'd be happy to change my mind if you can you suggest any other reason to re-do that work more frequently than changes to the filtering module / data that backs the filtering module? The acknowledgment that said algorithm also needs backing data leads us right back to the question of HOW. I believe all filtering efforts will eventually come down to "What tags/attributes are OK?" (among other critical questions, like "What values for attributes are OK?".) (If you're stuck in the "what tags/attributes are NOT OK" world then we have need of a different discussion: white lists vs black lists.) So, does anyone have a good list of "safe" tags/attributes that should be allowed through (assuming the attribute values also pass muster)? For example, here are my (woefully incomplete) lists (plus a crossover table (allowed_xhtml_tag_attribute_map) not shown linking allowable combinations of the two): allowed_xhtml_tag: a b blockquote br cite del div em font h1 h2 h3 h4 h5 h6 i img ins li ol p pre span strong sub sup table td th tr u ul allowed_xhtml_attribute: alt border cite class color href name src style title For example, I already know I need to add caption and tbody to the first table, but I've been delaying more by-hand tweaks in hopes of finding a more systematic way to fill the tables. I've yet to find it. Any suggestions? -Dale Newfield [EMAIL PROTECTED] P.S.: the "tagsoup parse" suggestion is also good because it guarantees that anything you do reflect back to users is valid XHTML (and so won't screw up other parts of your page with illegally nested/unbalanced tags). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross site scripting issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joseph, Joseph McGranaghan wrote: > I [hear that worrying about XSS is not worth it] all the time, am I > missing something? > > What if you want the user to be able to input all kinds of > markup to be redisplayed: > > >http://somewhere.com";>somewhere > > > At some point this makes it back into the page so the browser can render > it. > > If this discussion is useless, I am severely misguided and probably > wasting time. You have a special case when you /want/ to allow users to use HTML markup. Leon was pointing out that spending a lot of time running all input through an XSS-sanitizer is not worth it. If you /are/ capturing text you will be using that /can/ contain HTML markup, then cleaning it as it comes in is still a mistake. Let's say you have a bug in your cleansing code. In that case, bad stuff gets into your database where it's hard to root out and fix. If you always run "normal" output through a '<' and '>' filter, and then always run your "HTML" output through your XSS cleanser, then you're always okay as long as your XSS cleaner is up-to-date. That is, if you have to make a change to the XSS-cleaner, then all output benefits, instead of having /some/ clean input and some not-so-clean input that you will blindly output at a later time. I agree with Leon: cleaning input is not usually a good idea. Cleaning output is where the real money is -- from a security and maintainability standpoint. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+c979CaO5/Lv0PARAo/+AKCMJIAe42ulV4Wg1dSWwVBLgeAk2wCeNRKF zaXOtvr4eW+dbpR3Va/5ktA= =A+z6 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross site scripting issue
--- Joseph McGranaghan wrote: > [... huge-ass regexp, including...] > |c(?:hange|lick)| IANAREW, but... what's with all the weird "let's refactor out the first (and/or) last characters of the regexp?" This seems like a really slow, really... weird way to deal with XSS. d. Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross site scripting issue
I here this all the time, am I missing something? What if you want the user to be able to input all kinds of markup to be redisplayed: http://somewhere.com";>somewhere At some point this makes it back into the page so the browser can render it. If this discussion is useless, I am severely misguided and probably wasting time. -Joe At Leon Rosenberg wrote: On 3/15/07, Levan Dvalishvili <[EMAIL PROTECTED]> wrote: That looks interesting, can I add that to my toolking? One question thought, it is regexp pattern right? So I assume it's evaluated for every request that comes into the system, is not it kind of performance load on the system? But I guess that is the only way to fight XSS. Not really. The best to fight XSS is to care for the output, not for the input. As long as you write out the user input properly you don't have anything to worry about. Basically the whole discussion is useless, its sufficent to encode < and > properly :-) Leon. -Original Message- From: Joseph McGranaghan [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 4:46 PM To: Struts Users Mailing List Subject: Re: Cross site scripting issue Sorry, just noticed a problem in that events filter. (;|>) in the end should be just > in case multiple statements. It's a work in progress :) -Joe Joseph McGranaghan wrote: > I'm currently working on this problem for a website I'm building. > > I found this: > > > on(?:(?:mo(?:use(?:o(?:ver|ut)|down|move|up)|ve)|key(?:press|dow" + > > "n|up)|c(?:hange|lick)|s(?:elec|ubmi)t|(?:un)?load|dragdrop|resize|focus|" > + > > "blur)\b\W*?=|abort\b)|(?:l(?:owsrc\b\W*?\b(?:(?:java|vb)script|shell)|iv" > + > > "escript)|(?:href|url)\b\W*?\b(?:(?:java|vb)script|shell)|mocha):|type\b\" > + >"W*?\b(?:text\b(?:\W*?\b(?:j(?:ava)?|ecma)script\b|" + > > "[vbscript])|application\b\W*?\bx-(?:java|vb)script\b)|s(?:(?:tyle\b\W*=." > + > > "*\bexpression\b\W*|ettimeout\b\W*?)\(|rc\b\W*?\b(?:(?:java|vb)script|she" > + > > "ll|http):)|(?:c(?:opyparentfolder|reatetextrange)|get(?:special|parent)f" > + > > "older|background-image:)\b|a(?:ctivexobject\b|lert\b\W*?\())|<(?:(?:body" > + > > "\b.*?\b(?:backgroun|onloa)d|input\b.*?\\btype\b\W*?\bimage)\b|!\[CDATA\[" > + > > "|script|meta)|(?:.(?:(?:execscrip|addimpor)t|(?:fromcharcod|cooki)e|inne" > + >"rhtml)|[EMAIL PROTECTED])\b) > > from a mod_security list archive and am using it as a starting point. > > I did a couple of searches on myspace security and got a bunch of good > leads. > I figure they have the most current experience with this. > > Especially helpful in identifying harmful javascript patterns was the > explanation of the myspace samy worm. > Good insight. > > I figure I'll keep modifying regular expressions that are kept in one > central class until I can't slip anything through. > > I know other people are working on this stuff too, they'd have to be. > > Be nice to share some discoveries guys :) > > Here is an events filter I did this mornin: > > > > /* > * events: whitspace eventname = "' javascript '" > > * > * If no ' or ", then goto last ) before > > */ >private final static String XSS_EVENTS_FILTER = > "\\s*(on(abort|activate|afterprint|afterupdate))|"+ > > "(onbefore(activate|copy|cut|deactivate|editfocus|paste|update|print|unload) )|"+ > > > "(on(blur|cellchange|change|click|contextmenu|controlselect|copy|cut|))|"+ > > > "(ondata(available|setchanged|setcomplete))|"+ > > "(on(dblclick|deactivate))|"+ > > "(ondrag|(ondrag(end|enter|leave|over|start)))|"+ > > "(on(drop|error|errorupdate|filterchange))|"+ > > "(onfocus|(onfocus(in|out)))|"+ > > "(on(help|deactivate))|"+ > > "(onkey(down|press|up))|"+ > > "(on(layoutcomplete|load|losecapture))|"+ > > "(on(layoutcomplete|load|losecapture))|"+ > > "(onmouse(down|enter|leave|move|out|over|up|wheel|move))|"+ > > "(onmove|(onmove(end|start)))|"+ > > "(on(page|paste|propertychange|readystatechange|reset|resize))|"+ > > "(onresize(end|start))|"+ > > "(onrow(enter|exit|delete|sdelete|inserted|sinserted))|"+ > > "(on(scroll|select|selectionchange|selectstart|submit|unload))"+ > > "\\s*=\\s*((\'.*\')|(\".*\")|(.*\\(.*(;|>)))"; > > > I the
Re: Cross site scripting issue
On 3/15/07, Levan Dvalishvili <[EMAIL PROTECTED]> wrote: That looks interesting, can I add that to my toolking? One question thought, it is regexp pattern right? So I assume it's evaluated for every request that comes into the system, is not it kind of performance load on the system? But I guess that is the only way to fight XSS. Not really. The best to fight XSS is to care for the output, not for the input. As long as you write out the user input properly you don't have anything to worry about. Basically the whole discussion is useless, its sufficent to encode < and > properly :-) Leon. -Original Message- From: Joseph McGranaghan [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 4:46 PM To: Struts Users Mailing List Subject: Re: Cross site scripting issue Sorry, just noticed a problem in that events filter. (;|>) in the end should be just > in case multiple statements. It's a work in progress :) -Joe Joseph McGranaghan wrote: > I'm currently working on this problem for a website I'm building. > > I found this: > > > on(?:(?:mo(?:use(?:o(?:ver|ut)|down|move|up)|ve)|key(?:press|dow" + > > "n|up)|c(?:hange|lick)|s(?:elec|ubmi)t|(?:un)?load|dragdrop|resize|focus|" > + > > "blur)\b\W*?=|abort\b)|(?:l(?:owsrc\b\W*?\b(?:(?:java|vb)script|shell)|iv" > + > > "escript)|(?:href|url)\b\W*?\b(?:(?:java|vb)script|shell)|mocha):|type\b\" > + >"W*?\b(?:text\b(?:\W*?\b(?:j(?:ava)?|ecma)script\b|" + > > "[vbscript])|application\b\W*?\bx-(?:java|vb)script\b)|s(?:(?:tyle\b\W*=." > + > > "*\bexpression\b\W*|ettimeout\b\W*?)\(|rc\b\W*?\b(?:(?:java|vb)script|she" > + > > "ll|http):)|(?:c(?:opyparentfolder|reatetextrange)|get(?:special|parent)f" > + > > "older|background-image:)\b|a(?:ctivexobject\b|lert\b\W*?\())|<(?:(?:body" > + > > "\b.*?\b(?:backgroun|onloa)d|input\b.*?\\btype\b\W*?\bimage)\b|!\[CDATA\[" > + > > "|script|meta)|(?:.(?:(?:execscrip|addimpor)t|(?:fromcharcod|cooki)e|inne" > + >"rhtml)|[EMAIL PROTECTED])\b) > > from a mod_security list archive and am using it as a starting point. > > I did a couple of searches on myspace security and got a bunch of good > leads. > I figure they have the most current experience with this. > > Especially helpful in identifying harmful javascript patterns was the > explanation of the myspace samy worm. > Good insight. > > I figure I'll keep modifying regular expressions that are kept in one > central class until I can't slip anything through. > > I know other people are working on this stuff too, they'd have to be. > > Be nice to share some discoveries guys :) > > Here is an events filter I did this mornin: > > > > /* > * events: whitspace eventname = "' javascript '" > > * > * If no ' or ", then goto last ) before > > */ >private final static String XSS_EVENTS_FILTER = > "\\s*(on(abort|activate|afterprint|afterupdate))|"+ > > "(onbefore(activate|copy|cut|deactivate|editfocus|paste|update|print|unload) )|"+ > > > "(on(blur|cellchange|change|click|contextmenu|controlselect|copy|cut|))|"+ > > > "(ondata(available|setchanged|setcomplete))|"+ > > "(on(dblclick|deactivate))|"+ > > "(ondrag|(ondrag(end|enter|leave|over|start)))|"+ > > "(on(drop|error|errorupdate|filterchange))|"+ > > "(onfocus|(onfocus(in|out)))|"+ > > "(on(help|deactivate))|"+ > > "(onkey(down|press|up))|"+ > > "(on(layoutcomplete|load|losecapture))|"+ > > "(on(layoutcomplete|load|losecapture))|"+ > > "(onmouse(down|enter|leave|move|out|over|up|wheel|move))|"+ > > "(onmove|(onmove(end|start)))|"+ > > "(on(page|paste|propertychange|readystatechange|reset|resize))|"+ > > "(onresize(end|start))|"+ > > "(onrow(enter|exit|delete|sdelete|inserted|sinserted))|"+ > > "(on(scroll|select|selectionchange|selectstart|submit|unload))"+ > > "\\s*=\\s*((\'.*\')|(\".*\")|(.*\\(.*(;|>)))"; > > > I the user is trying to slip js in using whitespace instead of quotes, > it defaults to stripping everything including the end of tag > > > Better me than them! > > > > -Joe > > > > > Dale Newfield wrote: >> rapsy wrote: >>> I am trying to find a best solution to prevent Cross site scripting >>> attacks. >> >> Aren't we all. >> >> The best sugge
RE: Cross site scripting issue
That looks interesting, can I add that to my toolking? One question thought, it is regexp pattern right? So I assume it's evaluated for every request that comes into the system, is not it kind of performance load on the system? But I guess that is the only way to fight XSS. -Original Message- From: Joseph McGranaghan [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 4:46 PM To: Struts Users Mailing List Subject: Re: Cross site scripting issue Sorry, just noticed a problem in that events filter. (;|>) in the end should be just > in case multiple statements. It's a work in progress :) -Joe Joseph McGranaghan wrote: > I'm currently working on this problem for a website I'm building. > > I found this: > > > on(?:(?:mo(?:use(?:o(?:ver|ut)|down|move|up)|ve)|key(?:press|dow" + > > "n|up)|c(?:hange|lick)|s(?:elec|ubmi)t|(?:un)?load|dragdrop|resize|focus|" > + > > "blur)\b\W*?=|abort\b)|(?:l(?:owsrc\b\W*?\b(?:(?:java|vb)script|shell)|iv" > + > > "escript)|(?:href|url)\b\W*?\b(?:(?:java|vb)script|shell)|mocha):|type\b\" > + >"W*?\b(?:text\b(?:\W*?\b(?:j(?:ava)?|ecma)script\b|" + > > "[vbscript])|application\b\W*?\bx-(?:java|vb)script\b)|s(?:(?:tyle\b\W*=." > + > > "*\bexpression\b\W*|ettimeout\b\W*?)\(|rc\b\W*?\b(?:(?:java|vb)script|she" > + > > "ll|http):)|(?:c(?:opyparentfolder|reatetextrange)|get(?:special|parent)f" > + > > "older|background-image:)\b|a(?:ctivexobject\b|lert\b\W*?\())|<(?:(?:body" > + > > "\b.*?\b(?:backgroun|onloa)d|input\b.*?\\btype\b\W*?\bimage)\b|!\[CDATA\[" > + > > "|script|meta)|(?:.(?:(?:execscrip|addimpor)t|(?:fromcharcod|cooki)e|inne" > + >"rhtml)|[EMAIL PROTECTED])\b) > > from a mod_security list archive and am using it as a starting point. > > I did a couple of searches on myspace security and got a bunch of good > leads. > I figure they have the most current experience with this. > > Especially helpful in identifying harmful javascript patterns was the > explanation of the myspace samy worm. > Good insight. > > I figure I'll keep modifying regular expressions that are kept in one > central class until I can't slip anything through. > > I know other people are working on this stuff too, they'd have to be. > > Be nice to share some discoveries guys :) > > Here is an events filter I did this mornin: > > > > /* > * events: whitspace eventname = "' javascript '" > > * > * If no ' or ", then goto last ) before > > */ >private final static String XSS_EVENTS_FILTER = > "\\s*(on(abort|activate|afterprint|afterupdate))|"+ > > "(onbefore(activate|copy|cut|deactivate|editfocus|paste|update|print|unload) )|"+ > > > "(on(blur|cellchange|change|click|contextmenu|controlselect|copy|cut|))|"+ > > > "(ondata(available|setchanged|setcomplete))|"+ > > "(on(dblclick|deactivate))|"+ > > "(ondrag|(ondrag(end|enter|leave|over|start)))|"+ > > "(on(drop|error|errorupdate|filterchange))|"+ > > "(onfocus|(onfocus(in|out)))|"+ > > "(on(help|deactivate))|"+ > > "(onkey(down|press|up))|"+ > > "(on(layoutcomplete|load|losecapture))|"+ > > "(on(layoutcomplete|load|losecapture))|"+ > > "(onmouse(down|enter|leave|move|out|over|up|wheel|move))|"+ > > "(onmove|(onmove(end|start)))|"+ > > "(on(page|paste|propertychange|readystatechange|reset|resize))|"+ > > "(onresize(end|start))|"+ > > "(onrow(enter|exit|delete|sdelete|inserted|sinserted))|"+ >
Re: Cross site scripting issue
Sorry, just noticed a problem in that events filter. (;|>) in the end should be just > in case multiple statements. It's a work in progress :) -Joe Joseph McGranaghan wrote: I'm currently working on this problem for a website I'm building. I found this: on(?:(?:mo(?:use(?:o(?:ver|ut)|down|move|up)|ve)|key(?:press|dow" + "n|up)|c(?:hange|lick)|s(?:elec|ubmi)t|(?:un)?load|dragdrop|resize|focus|" + "blur)\b\W*?=|abort\b)|(?:l(?:owsrc\b\W*?\b(?:(?:java|vb)script|shell)|iv" + "escript)|(?:href|url)\b\W*?\b(?:(?:java|vb)script|shell)|mocha):|type\b\" + "W*?\b(?:text\b(?:\W*?\b(?:j(?:ava)?|ecma)script\b|" + "[vbscript])|application\b\W*?\bx-(?:java|vb)script\b)|s(?:(?:tyle\b\W*=." + "*\bexpression\b\W*|ettimeout\b\W*?)\(|rc\b\W*?\b(?:(?:java|vb)script|she" + "ll|http):)|(?:c(?:opyparentfolder|reatetextrange)|get(?:special|parent)f" + "older|background-image:)\b|a(?:ctivexobject\b|lert\b\W*?\())|<(?:(?:body" + "\b.*?\b(?:backgroun|onloa)d|input\b.*?\\btype\b\W*?\bimage)\b|!\[CDATA\[" + "|script|meta)|(?:.(?:(?:execscrip|addimpor)t|(?:fromcharcod|cooki)e|inne" + "rhtml)|[EMAIL PROTECTED])\b) from a mod_security list archive and am using it as a starting point. I did a couple of searches on myspace security and got a bunch of good leads. I figure they have the most current experience with this. Especially helpful in identifying harmful javascript patterns was the explanation of the myspace samy worm. Good insight. I figure I'll keep modifying regular expressions that are kept in one central class until I can't slip anything through. I know other people are working on this stuff too, they'd have to be. Be nice to share some discoveries guys :) Here is an events filter I did this mornin: /* * events: whitspace eventname = "' javascript '" > * * If no ' or ", then goto last ) before > */ private final static String XSS_EVENTS_FILTER = "\\s*(on(abort|activate|afterprint|afterupdate))|"+ "(onbefore(activate|copy|cut|deactivate|editfocus|paste|update|print|unload))|"+ "(on(blur|cellchange|change|click|contextmenu|controlselect|copy|cut|))|"+ "(ondata(available|setchanged|setcomplete))|"+ "(on(dblclick|deactivate))|"+ "(ondrag|(ondrag(end|enter|leave|over|start)))|"+ "(on(drop|error|errorupdate|filterchange))|"+ "(onfocus|(onfocus(in|out)))|"+ "(on(help|deactivate))|"+ "(onkey(down|press|up))|"+ "(on(layoutcomplete|load|losecapture))|"+ "(on(layoutcomplete|load|losecapture))|"+ "(onmouse(down|enter|leave|move|out|over|up|wheel|move))|"+ "(onmove|(onmove(end|start)))|"+ "(on(page|paste|propertychange|readystatechange|reset|resize))|"+ "(onresize(end|start))|"+ "(onrow(enter|exit|delete|sdelete|inserted|sinserted))|"+ "(on(scroll|select|selectionchange|selectstart|submit|unload))"+ "\\s*=\\s*((\'.*\')|(\".*\")|(.*\\(.*(;|>)))"; I the user is trying to slip js in using whitespace instead of quotes, it defaults to stripping everything including the end of tag > Better me than them! -Joe Dale Newfield wrote: rapsy wrote: I am trying to find a best solution to prevent Cross site scripting attacks. Aren't we all. The best suggestion I've found is in the first comment on http://weblogs.java.net/blog/gmurray71/archive/2006/09/preventing_cros.html Basically the suggestion is to Tagsoup parse into XHTML in order to filter and allow through only "safe" content. White lists are much safer than black lists. That is basically what I've implemented, but it's still not enough, as I mention in the last comment there. Any suggestions on that "next step"? Doing this "correctly" means ensuring that my whitelists are accurate and safe. For example, it seems nice to allow style attributes, but is that safe? In order to allow css, maybe class attributes should be allowed, but are id attributes necessary? Don't I then have to worry about using any of those "ajax without javascript" .js libra
Re: Cross site scripting issue
I'm currently working on this problem for a website I'm building. I found this: on(?:(?:mo(?:use(?:o(?:ver|ut)|down|move|up)|ve)|key(?:press|dow" + "n|up)|c(?:hange|lick)|s(?:elec|ubmi)t|(?:un)?load|dragdrop|resize|focus|" + "blur)\b\W*?=|abort\b)|(?:l(?:owsrc\b\W*?\b(?:(?:java|vb)script|shell)|iv" + "escript)|(?:href|url)\b\W*?\b(?:(?:java|vb)script|shell)|mocha):|type\b\" + "W*?\b(?:text\b(?:\W*?\b(?:j(?:ava)?|ecma)script\b|" + "[vbscript])|application\b\W*?\bx-(?:java|vb)script\b)|s(?:(?:tyle\b\W*=." + "*\bexpression\b\W*|ettimeout\b\W*?)\(|rc\b\W*?\b(?:(?:java|vb)script|she" + "ll|http):)|(?:c(?:opyparentfolder|reatetextrange)|get(?:special|parent)f" + "older|background-image:)\b|a(?:ctivexobject\b|lert\b\W*?\())|<(?:(?:body" + "\b.*?\b(?:backgroun|onloa)d|input\b.*?\\btype\b\W*?\bimage)\b|!\[CDATA\[" + "|script|meta)|(?:.(?:(?:execscrip|addimpor)t|(?:fromcharcod|cooki)e|inne" + "rhtml)|[EMAIL PROTECTED])\b) from a mod_security list archive and am using it as a starting point. I did a couple of searches on myspace security and got a bunch of good leads. I figure they have the most current experience with this. Especially helpful in identifying harmful javascript patterns was the explanation of the myspace samy worm. Good insight. I figure I'll keep modifying regular expressions that are kept in one central class until I can't slip anything through. I know other people are working on this stuff too, they'd have to be. Be nice to share some discoveries guys :) Here is an events filter I did this mornin: /* * events: whitspace eventname = "' javascript '" > * * If no ' or ", then goto last ) before > */ private final static String XSS_EVENTS_FILTER = "\\s*(on(abort|activate|afterprint|afterupdate))|"+ "(onbefore(activate|copy|cut|deactivate|editfocus|paste|update|print|unload))|"+ "(on(blur|cellchange|change|click|contextmenu|controlselect|copy|cut|))|"+ "(ondata(available|setchanged|setcomplete))|"+ "(on(dblclick|deactivate))|"+ "(ondrag|(ondrag(end|enter|leave|over|start)))|"+ "(on(drop|error|errorupdate|filterchange))|"+ "(onfocus|(onfocus(in|out)))|"+ "(on(help|deactivate))|"+ "(onkey(down|press|up))|"+ "(on(layoutcomplete|load|losecapture))|"+ "(on(layoutcomplete|load|losecapture))|"+ "(onmouse(down|enter|leave|move|out|over|up|wheel|move))|"+ "(onmove|(onmove(end|start)))|"+ "(on(page|paste|propertychange|readystatechange|reset|resize))|"+ "(onresize(end|start))|"+ "(onrow(enter|exit|delete|sdelete|inserted|sinserted))|"+ "(on(scroll|select|selectionchange|selectstart|submit|unload))"+ "\\s*=\\s*((\'.*\')|(\".*\")|(.*\\(.*(;|>)))"; I the user is trying to slip js in using whitespace instead of quotes, it defaults to stripping everything including the end of tag > Better me than them! -Joe Dale Newfield wrote: rapsy wrote: I am trying to find a best solution to prevent Cross site scripting attacks. Aren't we all. The best suggestion I've found is in the first comment on http://weblogs.java.net/blog/gmurray71/archive/2006/09/preventing_cros.html Basically the suggestion is to Tagsoup parse into XHTML in order to filter and allow through only "safe" content. White lists are much safer than black lists. That is basically what I've implemented, but it's still not enough, as I mention in the last comment there. Any suggestions on that "next step"? Doing this "correctly" means ensuring that my whitelists are accurate and safe. For example, it seems nice to allow style attributes, but is that safe? In order to allow css, maybe class attributes should be allowed, but are id attributes necessary? Don't I then have to worry about using any of those "ajax without javascript" .js libraries? Because of those are there specific class attribute values I should disallow? It is clear that this filter is insufficient. For example, I want to allow links, so href must be allowed in
Re: Cross site scripting issue
rapsy wrote: I am trying to find a best solution to prevent Cross site scripting attacks. Aren't we all. The best suggestion I've found is in the first comment on http://weblogs.java.net/blog/gmurray71/archive/2006/09/preventing_cros.html Basically the suggestion is to Tagsoup parse into XHTML in order to filter and allow through only "safe" content. White lists are much safer than black lists. That is basically what I've implemented, but it's still not enough, as I mention in the last comment there. Any suggestions on that "next step"? Doing this "correctly" means ensuring that my whitelists are accurate and safe. For example, it seems nice to allow style attributes, but is that safe? In order to allow css, maybe class attributes should be allowed, but are id attributes necessary? Don't I then have to worry about using any of those "ajax without javascript" .js libraries? Because of those are there specific class attribute values I should disallow? It is clear that this filter is insufficient. For example, I want to allow links, so href must be allowed in tags, but clearly I don't want to allow that to be used as a way to trigger javascript so I must explicitly check the content of this attribute. That brings us right back to an ad-hoc collection of unescapeHtml/indexOf searches (for script, eval, etc.). This seems sloppy and unless carefully maintained likely to lead to XSS vulnerabilities for my users... Is there an obvious next step that I'm missing? Does anyone have available a table of "safe" tag/attribute combinations? This seems like someplace where I'd rather trust someone with more knowledge/experience than myself. Have only black-hats focused on this problem? Seems ripe ground for a good open-source (white-hat) tool... -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross site scripting issue
You should check out this site:
http://iamcal.com/publish/articles/php/processing_html/
It's in PHP and Perl, but it only took me a couple of hours to translate
it to Java.
Sami Dalouche wrote:
Hi,
If you want to escape HTML, you can use Jakarta Commons-Lang
StringEscapeUtils class :
http://jakarta.apache.org/commons/lang/apidocs/org/apache/commons/lang/StringEscapeUtils.html#escapeHtml(java.lang.String)
Personally, I am using the Radeox Wiki engine
(http://www.radeox.org/space/start) to render all of my free-form text
areas.
Regards,
Sami
Le jeudi 15 mars 2007 à 01:15 -0400, Joseph McGranaghan a écrit :
Are you allowing the user to redisplay any entered HTML ala myspace?
I'm working on a solution for this right now. For this situation, I'm
filtering it in action before it is saved to DB.
Here are some REs and a simple function:
private final static String XSS_BIG_OBJECTS_FILTER =
"(((<\\s*[Aa][Pp][Pp][Ll][Ee][Tt].*>.*<\\s*/.*[Aa][Pp][Pp][Ll][Ee][Tt]\\s*>)|(<\\s*[Aa][Pp][Pp][Ll][Ee][Tt].*/\\s*>))|"+
"((<\\s*[Oo][Bb][Jj][Ee][Cc][Tt].*>.*<\\s*/.*[Oo][Bb][Jj][Ee][Cc][Tt]\\s*>)|(<\\s*[Oo][Bb][Jj][Ee][Cc][Tt].*/\\s*>))|"+
"((<\\s*[Ss][Cc][Rr][Ii][Pp][Tt].*>.*<\\s*/.*[Ss][Cc][Rr][Ii][Pp][Tt]\\s*>)|(<\\s*[Ss][Cc][Rr][Ii][Pp][Tt].*/\\s*>))|"+
"((<\\s*[Ee][Mm][Bb][Ee][Dd].*>.*<\\s*/.*[Ee][Mm][Bb][Ee][Dd]\\s*>)|(<\\s*[Ee][Mm][Bb][Ee][Dd].*/\\s*>))|"+
"(=\\s*[\"\']*\\s*[Jj][Aa][Vv][Aa][Ss][Cc][Rr][Ii][Pp][Tt]\\s*:.*[\"\']))";
private final static String XSS_BIG_TAGS_FILTER =
"(((<\\s*[Ss][Ee][Rr][Vv][Ee][Rr].*>.*<\\s*/.*[Ss][Ee][Rr][Vv][Ee][Rr]\\s*>)|(<\\s*[Ss][Ee][Rr][Vv][Ee][Rr].*/\\s*>))|"+
"((<\\s*[Ff][Rr][Aa][Mm][Ee].*>.*<\\s*/.*[Ff][Rr][Aa][Mm][Ee]\\s*>)|(<\\s*[Ff][Rr][Aa][Mm][Ee].*/\\s*>))|"+
"((<\\s*[Ii][Ff][Rr][Aa][Mm][Ee].*>.*<\\s*/.*[Ii][Ff][Rr][Aa][Mm][Ee]\\s*>)|(<\\s*[Ii][Ff][Rr][Aa][Mm][Ee].*/\\s*>))|"+
"((<\\s*[Ff][Rr][Aa][Mm][Ee][Ss][Ee][Tt].*>.*<\\s*/.*[Ff][Rr][Aa][Mm][Ee][Ss][Ee][Tt]\\s*>)|(<\\s*[Ff][Rr][Aa][Mm][Ee][Ss][Ee][Tt].*/\\s*>)))";
/*
* No relative URLs
* No cross-domain URLs
*
* Tags ( a,img,form,ilayer )
*/
private final static String XSS_NOT_HTTP_RE =
"([^Hh]|[Hh][^Tt]|[Hh][Tt][^Tt]|[Hh][Tt][Tt][^Pp])*";
private final static String
XSS_NOT_RELATIVE_NOR_XDOMAIN_LINKS_FILTER =
"((<\\s*[Aa].*[Hh][Rr][Ee][Ff]\\s*=.*"+XSS_NOT_HTTP_RE+".*>.*>)|"+
"(<\\s*[Aa].*[Hh][Rr][Ee][Ff]\\s*=.*[Ee]-[Cc][Oo][Aa][Ll][Ee][Ss][Cc][Ee].*>.*>))";
/*
* handle img|ilayer src attributes
*/
private final static String XSS_NOT_RELATIVE_NOR_XDOMAIN_SRC_FILTER
=
"((<\\s*[Ii]([Mm][Gg]|[Ll][Aa][Yy][Ee][Rr]).*[Ss][Rr][Cc]\\s*=.*"+XSS_NOT_HTTP_RE+".*>.*>)|"+
"(<\\s*[Ii]([Mm][Gg]|[Ll][Aa][Yy][Ee][Rr]).*[Ss][Rr][Cc]\\s*=.*[Ee]-[Cc][Oo][Aa][Ll][Ee][Ss][Cc][Ee].*>.*>))";
/*
* form tags allowed, but action cannot be relative or xdomain
*/
private final static String XSS_FORMS_FILTER =
"((<\\s*[Ff][Oo][Rr][Mm].*[Aa][Cc][Tt][Ii][Oo][Nn]\\s*=.*"+XSS_NOT_HTTP_RE+".*>.*<\\s*/\\s*[Ff][Oo][Rr][Mm]\\s*>)|"+
"(<\\s*[Ff][Oo][Rr][Mm].*[Aa][Cc][Tt][Ii][Oo][Nn]\\s*=.*[Ee]-[Cc][Oo][Aa][Ll][Ee][Ss][Cc][Ee].*>.*<\\s*/\\s*[Ff][Oo][Rr][Mm]\\s*>))";
/*
* target attributes need to be replaced with target='_blank'
*/
private final static String XSS_TARGET_ATTRIBUTES_FILTER =
"\\s*[Tt][Aa][Rr][Gg][Ee][Tt]\\s*=\\s*((\'.*\')|(\".*\")|(_.*\\s*))";
private final static String BLANK_TARGET = " target=_blank ";
private String filterForHTMLRedisplay(String html){
String filtered = null;
try{
RE reObjects = new RE(FormUtils.XSS_BIG_OBJECTS_FILTER);
filtered = reObjects.subst(html," ");
RE reTags = new RE(FormUtils.XSS_BIG_TAGS_FILTER);
filtered = reTags.subst(filtered," ");
RE reLinks = new
RE(FormUtils.XSS_NOT_RELATIVE_NOR_XDOMAIN_LINKS_FILTER);
filtered = reLinks.subst(filtered," ");
RE reSrc = new
RE(FormUtils.XSS_NOT_RELATIVE_NOR_XDOMAIN_SRC_FILTER);
filtered = reSrc.subst(filtered," ");
RE reForms = new RE(FormUtils.XSS_FORMS_FILTER);
filtered = reForms.subst(fi
Re: Cross site scripting issue
Hi,
If you want to escape HTML, you can use Jakarta Commons-Lang
StringEscapeUtils class :
http://jakarta.apache.org/commons/lang/apidocs/org/apache/commons/lang/StringEscapeUtils.html#escapeHtml(java.lang.String)
Personally, I am using the Radeox Wiki engine
(http://www.radeox.org/space/start) to render all of my free-form text
areas.
Regards,
Sami
Le jeudi 15 mars 2007 à 01:15 -0400, Joseph McGranaghan a écrit :
> Are you allowing the user to redisplay any entered HTML ala myspace?
>
> I'm working on a solution for this right now. For this situation, I'm
> filtering it in action before it is saved to DB.
>
> Here are some REs and a simple function:
>
>
> private final static String XSS_BIG_OBJECTS_FILTER =
> "(((<\\s*[Aa][Pp][Pp][Ll][Ee][Tt].*>.*<\\s*/.*[Aa][Pp][Pp][Ll][Ee][Tt]\\s*>)|(<\\s*[Aa][Pp][Pp][Ll][Ee][Tt].*/\\s*>))|"+
>
>
> "((<\\s*[Oo][Bb][Jj][Ee][Cc][Tt].*>.*<\\s*/.*[Oo][Bb][Jj][Ee][Cc][Tt]\\s*>)|(<\\s*[Oo][Bb][Jj][Ee][Cc][Tt].*/\\s*>))|"+
>
>
> "((<\\s*[Ss][Cc][Rr][Ii][Pp][Tt].*>.*<\\s*/.*[Ss][Cc][Rr][Ii][Pp][Tt]\\s*>)|(<\\s*[Ss][Cc][Rr][Ii][Pp][Tt].*/\\s*>))|"+
>
>
> "((<\\s*[Ee][Mm][Bb][Ee][Dd].*>.*<\\s*/.*[Ee][Mm][Bb][Ee][Dd]\\s*>)|(<\\s*[Ee][Mm][Bb][Ee][Dd].*/\\s*>))|"+
>
>
> "(=\\s*[\"\']*\\s*[Jj][Aa][Vv][Aa][Ss][Cc][Rr][Ii][Pp][Tt]\\s*:.*[\"\']))";
>
>
> private final static String XSS_BIG_TAGS_FILTER =
> "(((<\\s*[Ss][Ee][Rr][Vv][Ee][Rr].*>.*<\\s*/.*[Ss][Ee][Rr][Vv][Ee][Rr]\\s*>)|(<\\s*[Ss][Ee][Rr][Vv][Ee][Rr].*/\\s*>))|"+
>
>
> "((<\\s*[Ff][Rr][Aa][Mm][Ee].*>.*<\\s*/.*[Ff][Rr][Aa][Mm][Ee]\\s*>)|(<\\s*[Ff][Rr][Aa][Mm][Ee].*/\\s*>))|"+
>
>
> "((<\\s*[Ii][Ff][Rr][Aa][Mm][Ee].*>.*<\\s*/.*[Ii][Ff][Rr][Aa][Mm][Ee]\\s*>)|(<\\s*[Ii][Ff][Rr][Aa][Mm][Ee].*/\\s*>))|"+
>
>
> "((<\\s*[Ff][Rr][Aa][Mm][Ee][Ss][Ee][Tt].*>.*<\\s*/.*[Ff][Rr][Aa][Mm][Ee][Ss][Ee][Tt]\\s*>)|(<\\s*[Ff][Rr][Aa][Mm][Ee][Ss][Ee][Tt].*/\\s*>)))";
>
>
>
> /*
> * No relative URLs
> * No cross-domain URLs
> *
> * Tags ( a,img,form,ilayer )
> */
> private final static String XSS_NOT_HTTP_RE =
> "([^Hh]|[Hh][^Tt]|[Hh][Tt][^Tt]|[Hh][Tt][Tt][^Pp])*";
>
> private final static String
> XSS_NOT_RELATIVE_NOR_XDOMAIN_LINKS_FILTER =
> "((<\\s*[Aa].*[Hh][Rr][Ee][Ff]\\s*=.*"+XSS_NOT_HTTP_RE+".*>.*>)|"+
>
> "(<\\s*[Aa].*[Hh][Rr][Ee][Ff]\\s*=.*[Ee]-[Cc][Oo][Aa][Ll][Ee][Ss][Cc][Ee].*>.*>))";
>
>
>
> /*
> * handle img|ilayer src attributes
> */
> private final static String XSS_NOT_RELATIVE_NOR_XDOMAIN_SRC_FILTER
> =
> "((<\\s*[Ii]([Mm][Gg]|[Ll][Aa][Yy][Ee][Rr]).*[Ss][Rr][Cc]\\s*=.*"+XSS_NOT_HTTP_RE+".*>.*>)|"+
>
> "(<\\s*[Ii]([Mm][Gg]|[Ll][Aa][Yy][Ee][Rr]).*[Ss][Rr][Cc]\\s*=.*[Ee]-[Cc][Oo][Aa][Ll][Ee][Ss][Cc][Ee].*>.*>))";
>
>
>
>
> /*
> * form tags allowed, but action cannot be relative or xdomain
> */
> private final static String XSS_FORMS_FILTER =
> "((<\\s*[Ff][Oo][Rr][Mm].*[Aa][Cc][Tt][Ii][Oo][Nn]\\s*=.*"+XSS_NOT_HTTP_RE+".*>.*<\\s*/\\s*[Ff][Oo][Rr][Mm]\\s*>)|"+
>
> "(<\\s*[Ff][Oo][Rr][Mm].*[Aa][Cc][Tt][Ii][Oo][Nn]\\s*=.*[Ee]-[Cc][Oo][Aa][Ll][Ee][Ss][Cc][Ee].*>.*<\\s*/\\s*[Ff][Oo][Rr][Mm]\\s*>))";
>
>
>
>
> /*
> * target attributes need to be replaced with target='_blank'
> */
> private final static String XSS_TARGET_ATTRIBUTES_FILTER =
> "\\s*[Tt][Aa][Rr][Gg][Ee][Tt]\\s*=\\s*((\'.*\')|(\".*\")|(_.*\\s*))";
>
> private final static String BLANK_TARGET = " target=_blank ";
>
>
> private String filterForHTMLRedisplay(String html){
>
> String filtered = null;
>
> try{
>
> RE reObjects = new RE(FormUtils.XSS_BIG_OBJECTS_FILTER);
> filtered = reObjects.subst(html," ");
>
> RE reTags = new RE(FormUtils.XSS_BIG_TAGS_FILTER);
> filtered = reTags.subst(filtered," ");
>
> RE reLinks = new
> RE(FormUtils.XSS_NOT_RELATIVE_NOR_XDOMAIN_LINKS_FILTER);
> filtered = reLinks.subst(filtered," ");
>
> RE reSrc = new
> RE(FormUtils.XSS_NOT_RELATIVE_NOR_XDOMAIN_SRC_FILTER);
> filtered = reSrc.subst(filtered," ");
>
> RE reForms = new RE(FormUtils.XSS_FORMS_FILTER);
> filtered = reForms.su
Re: Cross site scripting issue
Are you allowing the user to redisplay any entered HTML ala myspace?
I'm working on a solution for this right now. For this situation, I'm
filtering it in action before it is saved to DB.
Here are some REs and a simple function:
private final static String XSS_BIG_OBJECTS_FILTER =
"(((<\\s*[Aa][Pp][Pp][Ll][Ee][Tt].*>.*<\\s*/.*[Aa][Pp][Pp][Ll][Ee][Tt]\\s*>)|(<\\s*[Aa][Pp][Pp][Ll][Ee][Tt].*/\\s*>))|"+
"((<\\s*[Oo][Bb][Jj][Ee][Cc][Tt].*>.*<\\s*/.*[Oo][Bb][Jj][Ee][Cc][Tt]\\s*>)|(<\\s*[Oo][Bb][Jj][Ee][Cc][Tt].*/\\s*>))|"+
"((<\\s*[Ss][Cc][Rr][Ii][Pp][Tt].*>.*<\\s*/.*[Ss][Cc][Rr][Ii][Pp][Tt]\\s*>)|(<\\s*[Ss][Cc][Rr][Ii][Pp][Tt].*/\\s*>))|"+
"((<\\s*[Ee][Mm][Bb][Ee][Dd].*>.*<\\s*/.*[Ee][Mm][Bb][Ee][Dd]\\s*>)|(<\\s*[Ee][Mm][Bb][Ee][Dd].*/\\s*>))|"+
"(=\\s*[\"\']*\\s*[Jj][Aa][Vv][Aa][Ss][Cc][Rr][Ii][Pp][Tt]\\s*:.*[\"\']))";
private final static String XSS_BIG_TAGS_FILTER =
"(((<\\s*[Ss][Ee][Rr][Vv][Ee][Rr].*>.*<\\s*/.*[Ss][Ee][Rr][Vv][Ee][Rr]\\s*>)|(<\\s*[Ss][Ee][Rr][Vv][Ee][Rr].*/\\s*>))|"+
"((<\\s*[Ff][Rr][Aa][Mm][Ee].*>.*<\\s*/.*[Ff][Rr][Aa][Mm][Ee]\\s*>)|(<\\s*[Ff][Rr][Aa][Mm][Ee].*/\\s*>))|"+
"((<\\s*[Ii][Ff][Rr][Aa][Mm][Ee].*>.*<\\s*/.*[Ii][Ff][Rr][Aa][Mm][Ee]\\s*>)|(<\\s*[Ii][Ff][Rr][Aa][Mm][Ee].*/\\s*>))|"+
"((<\\s*[Ff][Rr][Aa][Mm][Ee][Ss][Ee][Tt].*>.*<\\s*/.*[Ff][Rr][Aa][Mm][Ee][Ss][Ee][Tt]\\s*>)|(<\\s*[Ff][Rr][Aa][Mm][Ee][Ss][Ee][Tt].*/\\s*>)))";
/*
* No relative URLs
* No cross-domain URLs
*
* Tags ( a,img,form,ilayer )
*/
private final static String XSS_NOT_HTTP_RE =
"([^Hh]|[Hh][^Tt]|[Hh][Tt][^Tt]|[Hh][Tt][Tt][^Pp])*";
private final static String
XSS_NOT_RELATIVE_NOR_XDOMAIN_LINKS_FILTER =
"((<\\s*[Aa].*[Hh][Rr][Ee][Ff]\\s*=.*"+XSS_NOT_HTTP_RE+".*>.*>)|"+
"(<\\s*[Aa].*[Hh][Rr][Ee][Ff]\\s*=.*[Ee]-[Cc][Oo][Aa][Ll][Ee][Ss][Cc][Ee].*>.*>))";
/*
* handle img|ilayer src attributes
*/
private final static String XSS_NOT_RELATIVE_NOR_XDOMAIN_SRC_FILTER
=
"((<\\s*[Ii]([Mm][Gg]|[Ll][Aa][Yy][Ee][Rr]).*[Ss][Rr][Cc]\\s*=.*"+XSS_NOT_HTTP_RE+".*>.*>)|"+
"(<\\s*[Ii]([Mm][Gg]|[Ll][Aa][Yy][Ee][Rr]).*[Ss][Rr][Cc]\\s*=.*[Ee]-[Cc][Oo][Aa][Ll][Ee][Ss][Cc][Ee].*>.*>))";
/*
* form tags allowed, but action cannot be relative or xdomain
*/
private final static String XSS_FORMS_FILTER =
"((<\\s*[Ff][Oo][Rr][Mm].*[Aa][Cc][Tt][Ii][Oo][Nn]\\s*=.*"+XSS_NOT_HTTP_RE+".*>.*<\\s*/\\s*[Ff][Oo][Rr][Mm]\\s*>)|"+
"(<\\s*[Ff][Oo][Rr][Mm].*[Aa][Cc][Tt][Ii][Oo][Nn]\\s*=.*[Ee]-[Cc][Oo][Aa][Ll][Ee][Ss][Cc][Ee].*>.*<\\s*/\\s*[Ff][Oo][Rr][Mm]\\s*>))";
/*
* target attributes need to be replaced with target='_blank'
*/
private final static String XSS_TARGET_ATTRIBUTES_FILTER =
"\\s*[Tt][Aa][Rr][Gg][Ee][Tt]\\s*=\\s*((\'.*\')|(\".*\")|(_.*\\s*))";
private final static String BLANK_TARGET = " target=_blank ";
private String filterForHTMLRedisplay(String html){
String filtered = null;
try{
RE reObjects = new RE(FormUtils.XSS_BIG_OBJECTS_FILTER);
filtered = reObjects.subst(html," ");
RE reTags = new RE(FormUtils.XSS_BIG_TAGS_FILTER);
filtered = reTags.subst(filtered," ");
RE reLinks = new
RE(FormUtils.XSS_NOT_RELATIVE_NOR_XDOMAIN_LINKS_FILTER);
filtered = reLinks.subst(filtered," ");
RE reSrc = new
RE(FormUtils.XSS_NOT_RELATIVE_NOR_XDOMAIN_SRC_FILTER);
filtered = reSrc.subst(filtered," ");
RE reForms = new RE(FormUtils.XSS_FORMS_FILTER);
filtered = reForms.subst(filtered," ");
RE reTarget = new RE(FormUtils.XSS_TARGET_ATTRIBUTES_FILTER);
filtered = reTarget.subst(filtered,FormUtils.BLANK_TARGET);
}catch(Exception e){
if(DEBUG){
System.out.println("\nFormUtils.filterForHTMLRedisplay:
"+e.getMessage()+"\n");
}
}
if(filtered==null){
return ("");
}else{
return ("\n\n\n"+filtered);
}
}
Again, I did most of this tonight so I haven't even ran it yet.
But I'd love some feedback if I'm fundamentally wrong.
Oh, the thing is so my AJAX execScript function knows not to
eval() any of this, just
Re: Cross site scripting issue
Jason Britain (author of Tomcat, the definitive guide) has a ready-to-run filter/valve solution for that. You could talk to him on the #tomcat channel on irc. Besides, best XSS prevention is imo not filtering the input, but the output. if you write everything out with you'll be fine. regards Leon On 3/14/07, rapsy <[EMAIL PROTECTED]> wrote: Hi All, I am trying to find a best solution to prevent Cross site scripting attacks. I wrote a method to filter out all the bad characters. But my questions is where should I call this method? AT the form level, in setters method r action level or use a filter. I think filter is a good option but I am not sure how to implement that. Any help is appreciated! Thanks -- View this message in context: http://www.nabble.com/Cross-site-scripting-issue-tf3404408.html#a9482026 Sent from the Struts - User mailing list archive at Nabble.com. - 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: Cross site scripting issue
Check for a predefined pattern of characters in a filter,as you have suggested, (probably read from xml) and forward to an error page if you find any. -Original Message- From: rapsy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 14, 2007 3:50 PM To: user@struts.apache.org Subject: Cross site scripting issue Hi All, I am trying to find a best solution to prevent Cross site scripting attacks. I wrote a method to filter out all the bad characters. But my questions is where should I call this method? AT the form level, in setters method r action level or use a filter. I think filter is a good option but I am not sure how to implement that. Any help is appreciated! Thanks -- View this message in context: http://www.nabble.com/Cross-site-scripting-issue-tf3404408.html#a9482026 Sent from the Struts - User mailing list archive at Nabble.com. - 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]
