Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joe,
Joseph McGranaghan wrote:
So, tags I'm originally NOT allowing are:
<applet> <script> <embed> <object> <server> <frame> <iframe> <frameset>
<html> <body>
Okay.
If you're going to do this:
I'm removing all javascript event attributes ( onclick="alert('xss');" )
....then why do this:
Removing all javascript escaped quotes: \' and \"
??
You don't allow <script> tags (and anything within them, I imagine), and
you are removing javascript events, so there shouldn't be any javascript
left over... right?
Nope. What about <div align="javascript:alart('GOT YA')">? Or Javascript
injection through CSS in IE? What about any new Javascript injection
mechanism that some browser adds down the line... ;-)
In any tag left that has a link in it (src|href|action), I'm making sure
it is NOT relative and NOT to my server: <a> <img> <ilayer> <form>
I guess this would be protecting against a SSS (same-side scripting)
issue? ;)
Any 'target' attributes, I'm changing to target='_blank', although I
still think there is a security flaw in here for a popup window trying
to run code on the originating page.
Note that XHTML forbids the "target" attribute. It's still widely
supported, though.
I will be checking CSS urls.
Perhaps you should simply disallow <link> elements. You aren't allowing
<body>, so I'm guessing that <head> isn't allowed, which means that
<link> also isn't.
Just about all browsers support <link> in the document body, whether the
spec says they should or not... And it's not just URLs pointing to
external style sheets you need to worry about; inline CSS can be
problematic too.
I think you can ignore over-escaping javascript, since you're pretty
much eliminated it in the previous steps.
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.
Not to mention there are all sorts of funky Unicode sequences that
browsers will interpret as javascript: or style= or what-have-you, which
provides lots of opportunities to defeat anything but a very restrictive
white-list filter unless you do a *lot* of extra work :-(
On the input vs. output filtering issue: if you only filter input, you
are vulnerable to Javascript or other XSS attacks mounted through, for
example, SQL injection. In other words, if someone can find a way to
bypass your input filters, you have no protection against the resulting
bad data.
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.
Output filtering may cost extra CPU cycles, but it's also much more
robust. As a rule, I will:
- HTML-escape *all* user-entered data except those fields that really do
have to be output as HTML
- validate HTML-formatted input with white-list filtering, and reject it
if it doesn't pass the validation filter; otherwise, store it unchanged
(or as close to unchanged as I can bear; I may do some normalization
and/or HTML clean-up, but what's stored should be recognizably
equivalent to what the user entered)
- apply the same kind of filtering on output as was done for validation
on input, this time as an output filter that strips any offending
content, thus making a best-faith attempt to render the markup that's
been stored w/out compromising the application's security
The main reason to do any transformation / modification of the input
HTML is to reduce the cost of output filtering. For example, normalizing
Unicode character sequences and escapes, entity references, etc so that
I have a consistent text base to apply filtering against both going in
and going out.
Skipping the output filtering to save CPU cycles is simply an over-eager
optimization IMHO. Don't compromise security for the sake of a
performance gain you don't know you need...
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
