From: InfoSec News (alertsinfosecnews.org)
Date: Mon Jan 21 2008 - 00:24:52 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]