[owasp-intrinsic-security] Fwd: Defending XSS Attachs-by Browsers
robert at sectheory.com
Tue Sep 2 10:28:51 EDT 2008
Ø 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.
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...
More information about the owasp-intrinsic-security