struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Ruggles <>
Subject Re: Cross site scripting issue
Date Fri, 16 Mar 2007 18:42:56 GMT
/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:
>> 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>
>> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message