[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ISN] Many 'Hacker Safe' Web Sites Found Vulnerable

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:


 "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 

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