struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Ruggles <a.rugg...@gmail.com>
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:
>> -----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: 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


Mime
View raw message