Forwarded from: security curmudgeon <jericho (at) attrition.org> : http://www.informationweek.com/news/showArticle.jhtml?articleID=205900444 : : By Thomas Claburn : InformationWeek : January 17, 2008 : : More than 60 Web sites certified to be "Hacker Safe" by McAfee's : ScanAlert service have been vulnerable to cross-site scripting (XSS) : attacks over the past year, including the ScanAlert Web site itself. : While the XSS hole in the ScanAlert site and others have been : addressed, some apparently have not been, leaving visitors potentially : vulnerable to client-side attacks. : : Joseph Pierini, director of enterprise services for the ScanAlert : "Hacker Safe" program, maintains that XSS vulnerabilities can't be : used to hack a server. To put this quote in better context: http://www.darkreading.com/document.asp?doc_id=110495&f_src=darkreading_section_296 "Cross-site scripting is a problem in the Web browser and the site, but all code is executed on the client side," says Joseph Pierini, director of enterprise services for ScanAlert. "It requires some social engineering...to entice users to follow a link or click on a link sent via an email." Why do I get the feeling htat Mr. Pierini doesn't know the difference between reflective, stored and DOM based cross-site scripting? Sure, XSS isn't a magic ./pwn style remote exploit against a web server, but that doesn't matter these days. Users do many stupid things including leaving themselves logged in at public terminals and clicking links in e-mails from strangers. If a user clicks such a link and ends up passing their credentials to an application to a third party, those credentials may lead to the application (or web server) being compromised. Trying to say otherwise is naive and suggests that the director of enterprise services for ScanAlert (CISSP too!) doesn't fully understand the implications or attack vectors of XSS. : Pierini maintains that XSS vulnerabilities aren't material to a site's : certification. "Cross-site scripting can't be used to hack a server," : he said. "You may be able to do other things with it. You may be able : to do things that affect the end-user or the client. But the customer : data protected with the server, in the database, isn't going to be : compromised by a cross-site scripting attack, not directly." Is the customer's user ID and password "protected with the server" or "in the database"? If XSS can be used to trick/force a user into disclosing that information to a third party, isn't that a more serious risk than you suggest? Your wording also implies that the application or web site is not responsible for such vulnerabilities. Will you go on record and agree or disagree with that? : Pierini dismisses the suggestion that certifying a site as "Hacker : Safe" when it remains vulnerable to XSS attacks could be confusing to : consumers. He insists that the meaning of the certification is clear : and notes that his company's scanning service reports the XSS flaws it : finds to its clients. So the service scans for XSS flaws, and doesn't find it in 62 documented cases? Or you just can't convince at least 62 of your customers that it is important or worth fixing? : "We definitely identify this [XSS] and we definitely bring this to our : customers' attention," he said." And we provide our customers with the : information. Our customers are allowed to make the decision where to : put their resources. I personally want them to put their resources : where they're needed most, in things that can affect the : confidentiality, the It sounds like you deliver a report something like this: Cross-site Scripting [Very Low Risk] Difficulty to Exploit: Insanely impossible XSS is a silly attack that requires a dumb user to click on an obvious link and then they might disclose some information to a bad guy, but this vulnerability is not in your application, can not be used to hack a web server and can not be used to get to any data protected by your database. So yes, your customers probably trust your report as you downplay the severity and they don't fix it. : Cross-site scripting can be used to do a variety of things, but it's : all on the client side. And that's an area that we don't have control : over." Welcome to application testing and functionality 101 Mr. Pierini. There are a LOT of things the application can control on the client side. Forcing them to use SSL for sending sensitive information, forcing them to re-authenticate on sensitive transactions, forcing them not to cache sensitive information in the browser, forcing them to load the application page w/o it being in the frame of another site, forcing them to pick stronger passwords, forcing... : In an e-mail, McRee countered that while that may be true, "this issue : still indicates a shortcoming in the 'Hacker Safe' service." Pointing : to ScanAlert's online explanation of its scanning procedure, which : specifically identifies cross-site scripting among the flaws the : service attempts to detect, he dismissed the company's "Hacker Safe" : labeling as "a grandiose and inaccurate marketing claim." Exactly. All of this XSS discussion aside, if ScanAlert finds an XSS vulnerability in a website and the client doesn't fix it, then the site should not be certified as 'hacker safe'. Simple. ___________________________________________________ Subscribe to InfoSec News http://www.infosecnews.org/mailman/listinfo/isn
This archive was generated by hypermail 2.1.3 : Sun Jan 20 2008 - 22:36:52 PST