Oops, bad example. I guess this is generally more of a problem in a case
such as <a href="javascript:...">.
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 <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... ;-) /
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:
<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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
