[owasp-intrinsic-security] Fwd: Defending XSSAttachs-by Browsers

Jim Manico jim.manico at aspectsecurity.com
Tue Sep 2 15:16:29 EDT 2008

Again, this all makes 100% sense now - and I back it 100%.

- Jim


From: owasp-intrinsic-security-bounces at lists.owasp.org [mailto:owasp-intrinsic-security-bounces at lists.owasp.org] On Behalf Of Robert Hansen
Sent: Tuesday, September 02, 2008 10:29 AM
To: owasp-intrinsic-security at lists.owasp.org
Subject: Re: [owasp-intrinsic-security] Fwd: Defending XSSAttachs-by Browsers



? Yea, but that depends on perfect xHTML. It would be a lot easier to just add input validation and/or do encoding where appropriate then to change dynamic/complex code to be perfectly xHTML compliant. It seems like a complex approach to get you 1/2 or less of the way to a secure site.


SSP should never rely on perfect xHTML or it is already broken since it must work with _any_ user input.  Jails possibly, but not SSP. Although I'd argue that's a bad tenant to start from for jails too, since very few sites are valid XHTML - not even sites that make browsers, like Google.com. http://validator.w3.org/check?uri=www.google.com&charset=(detect+automatically)&doctype=Inline&group=0


? You are mixing very complex ideas here, Robert. If you must accept rich HTML from a user, then I would suggest a programming library like Ant-Samy be used. If you want to accept images from a user for re-display (a very different issue) then concepts of file upload appsec techniques should be applied (virus scanning, upload size limitations.


Yes, I realize they are complex problems - that's why I came up with the concept in the first place.  I was making a joke about the Kanye West image.  eBay already has eBay picture services - very few use it and it's not as easy as you are making it out to be due to the costs associated with running it which has to be offset by fees.  Still though, I agree, that's a far easier problem to solve than the one I'm actually talking about.  I should hope I don't have to iterate through all the things people want do with HTML and JavaScript and Flash and ActiveX and Java and CSS, etc... to this group.  Imagine flying bunnies, follow the mouse clocks, pink scrollbars, full motion video and sound and much much more.  Then add in JavaScript that document.write's <noscript> tags, pages that automatically close themselves, and other totally idiocy and you've barely scratched the surface of what we are up against.  And that's just the benign stuff!


Solving the business problem is my primary concern.  If you can do that the business leaders will fund the technology.  It has almost no chance of working the other way around.  Anti-Samy is great, but it again flies in the face of completely open HTML.  Any inhibitors to people cutting and pasting out of their favorite WYSIWYG is a non-starter from a business perspective.  I know because we've tried it and customers complained immediately.  Inbound customer service costs are undeniable business forces.  These companies go to extreme lengths not to upset their customers.  And I know people are concerned about worms, but really, that is extremely low on the scale of things eBay's worried about.  They're far more concerned about viruses/malware being delivered from the site - something an attacker can do with just an image tag (GDI+), and about redirection to phishing sites, which can take a number of different forms.


? I do not back that. Sure, companies cannot afford to fix ALL problems the correct way. Nor can companies afford to ignore high risk flaws in high risk applications and slap band-aids on top of them.


They can afford it, which is why they are still in business.  They don't want to afford it though, which is why SSP is so nice - no change to their business models.  It doesn't matter whether technologists back it or not.  If they project it's going to cost them ½ a billion dollars in 24 months due to a proactive security change, they aren't going to listen to us.  We have to be rational here.


? Ok, after further thought and review I am starting to get the importance of this concept, Robert, Arshan and Giorgio. I think Site Security Policy should be a key suggestion from this group.


As I said, this is not a suggestion we as a group need to make.  It's already well understood by both FF and IE and has been since I first started talking about it with them 3-4 years ago.  One last benefit of SSP is that it doesn't mess up SEO, unlike iframe based solutions.  And it also helps with certain older browsers for printing.  Long story short, SSP has tons of advantages.  More than I could properly spell out in a short email.


Robert Hansen, CISSP

CEO -- SecTheory LLC

Cell: (530) 521-2542

FAX: (512) 628-6299 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-intrinsic-security/attachments/20080902/cd9d2344/attachment.html 

More information about the owasp-intrinsic-security mailing list