Research has shown that most people are unable to tell whether they are at an authentic website that is using SSL encryption (see The Emperor’s New Security Indicators). This is part of the reason people are so susceptible to phishing. Web browsers provide enough information to tell if SSL is on, but it is presented in a poor manner (as a small lock icon). Other bad security practices, like the website embedding its own lock icon and saying “secure login”, make matters even worse.

The problem is that people tend to notice glaring differences, but do not take explicit steps to check for security. They shouldn’t have to. Firefox 3 tries to improve SSL indicators for “Extended Verification” certificates by displaying the company name in green to the left of the URL along with the fav-icon. It looks like this:

Unfortunately, this indicator is still just text, plus an insecure/unsigned fav-icon. One must deliberately read it to verify the site’s identity, so it is likely to go unnoticed if the user is at a different site, just like like previous security indicators. If a hacker can compromise any site that has an EV certificate using cross-site scripting (a common problem on many sites), then he can create a believable phishing page. Sure, the company name will be different, but the fav-icon could presumably be spoofed and the address bar will still have the green indicator.

 Firefox 3 SSL indicators for EV certificates are a much better than previous indicators, but there is still room for improvement. The problem is that there isn’t a striking visual difference between the security indicators for different sites with EV certificates. Confusion is possible, especially if one can spoof the fav-icon. What I propose is that each site with an EV certificate also sign a logo for display in place of the hostname. The logo should also be a registered trademark, which, by law, must be clearly different from other trademarks. In fact, the test for trademark violation is “confusion,” so using registered trademarks for EV certificates guarantees (legally) that there will be no visual confusion. Here is an example of what, in my mind, SSL indicators should look like:

This way, any deviation from PayPal.com would immediately stand out to the user and serve as a much better indicator not only of SSL, but also the identity of the current site.

At the recent USENIX Security Symposium, Niels Provos, head of the security team at Google, gave a compelling presentation about the state of client-side web security (you can find research project details here). His research project involves idenfitying drive-by downloads and filtering them from Google search results. One conclusion of the analysis was that any type of site can be malicious. It is usually not the owner, but rather a hacker who places exploit code on websites. This seems to suggest that the only way to keep malware off of computers is to either stop browsing the web, or lock down the web browser.

As security experts, we know how to use a browsing sandbox like Sandboxie or a VMWare appliance. Try, however, to explain this to an average user. It is not a straightforward process. Most people do not even understand the necessity for such precautions. People need a secure browser that is easy to install and manage. An example of such a browser was GreenBorder, which Google bought and promptly took out of commission. During the Q&A session following Niels’ talk, I asked him (in more friendly terms) why Google bought the one browser that promised to improve web security and stopped selling it. At the time he was unable to comment on Google’s strategy, but now the answer is clear: Google Chrome.

(more…)

Recent discussions about research on bank website design flaws (see Analyzing Websites for User-Visible Security Design Flaws) have brought up a few important points about web security. The research conducted by Dr. Prakash, Laura Falk, and myself addresses problems that preclude secure usage of bank websites by expert users. It does not consider how to design websites in such a way that they are secure for non-expert users. In the recent study, we looked at bank websites that have login boxes on insecure pages. However, if a hacker has access to the network link, he or she could just direct customers to a page that doesn’t use SSL at all. How many people will notice the difference? This article looks at the severity of usability problems in secure web transactions, and what could be done in web browsers to fix them.

(more…)

I was working on a project recently that involved creating a Java applet to select and upload files to a web server. After some investigation, I found that embedding such an applet in web browser required paying a certification authority $150 for a signing certificate. This fee does not include any sort of attestation that the applet is not malicious; it simply associates it with a known publisher (who is willing to pay $150) and prevents man-in-the-middle modifications. My next thought was: why don’t I just create a stand-alone executable? An executable is easier and cheaper to deploy, and it is more access to the system. From a security perspective this seems completely backwards. Not only should it be easier to safely deploy a simple program, such as one that uploads selected files, but there should also be more checks on anonymous executable downloads. The current web download trust model is broken, and this article shows how to fix it with user-generated feedback following the wiki model. (more…)

This weekend, SC Magazine published an an article about a vulnerability that allows remote code execution if you are running Firefox, but also have Internet Explorer 7 installed on your computer. I happen to run Firefox and have IE 7 installed on my computer, so I decided to investigate further by testing a shockingly simple sample exploit:

mailto:test%../../../../windows/system32/calc.exe”.cmd

And it worked. The interesting thing about this particular vulnerability is that it requires the combined effort of two applications to allow remote code execution on your computer. This naturally opened the door for people at both Firefox and Microsoft to deny responsibility. For this vulnerability, however, Microsoft is at fault. No URI that has “mailto:” should ever execute a file, and it is not Firefox’s job to shield insecure Windows interfaces from unchecked data. Vulnerabilities like this make you wonder, how many other insecure interfaces exist in the operating system that are safe only because third-party applications have yet to expose them to the internet?