At a recent Dagstuhl seminar on web application security, I spoke with Jasvir Nagra (one of the people at Google working on Caja) about the best way to run a public security contest. The goal of the contest would be to encourage people to find as many bugs as possible, with additional rewards for more severe security vulnerabilities. As a starting point, we discussed the ongoing Google Native Client (NaCl) security contest. For this contest, the top five bug-finders over a ten-week period receive recognition and cash prizes of $8192, $4096, $2048, $1024, and $1024. While this model has a few strong points, it also is problematic in the way that it incentivizes security research. This article discusses how to more effectively design a security contest.

(more…)

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.

This article covers a topic that is somewhat unrelated to computer security. However, Internet advertising does share some similarities with one security issue: phishing. Both cost-per-click (CPC) ads and phishing attacks use social engineering to elicit participation from the user. The main difference between phishing and advertising is that the former aims to deceive and defraud the user, while the latter tries to sell an actual product. This article discusses an approach for effective ad placement on social networks (Facebook, in particular). Some of the same principles could also be applied to deliver better context-aware phishing attacks or spam, which are described in a recent paper from our research group available here.

(more…)

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…)

The results of a recent study on security design flaws in banking websites will be presented tomorrow at the Symposium on Usability and Privacy. The research was conducted by Dr. Atul Prakash, Laura Falk, and myself (Kevin Borders). It found that flaws, such as presenting login information on an insecure page, were widespread. What does this mean for the security of the internet at large? Will hackers routinely exploit these vulnerabilities to conduct widespread fraud in the future? And, the most important question: how do we fix it?

(more…)

I was first exposed to SQL injection when David Litchfield (see his blog) came and gave a talk on the subject while I was working at the NSA in the summer of 2002. SQL injection is a type of security vulnerability that occurs when some code includes untrusted input, such as a website form field, in a SQL database query without first escaping or removing special characters that may affect SQL syntax (‘, ”, \, etc.). This may subsequently allow an attacker to terminate the original query and inject another query to do something malicious, such as the following: “”; DROP TABLE users;”. After hearing about SQL injection, my friends and I proceeded to go home and type “‘”; select * from users;” into form fields on numerous websites. Though we didn’t see any database table dumps, a surprisingly large number of sites gave us responses with SQL syntax errors, indicating potential vulnerabilities.

Things have changed a lot since the advent of SQL injection attacks. Many security researchers have investigated the topic and written papers on how to correct the problem. As the title of this blog post suggests, however, the SQL injection problem has been solved. Sometimes it makes sense for people to continue researching a problem when existing solutions have serious usability constraints or add significant development overhead. That is not the case for SQL injection. The rest of this article briefly touches on some SQL injection research and then shows you how to avoid vulnerabilities on your website using a common PHP library as an example.

(more…)

Have you ever wanted to purchase a domain name for a website? The chances are that you had to spend hours testing out ______.com domain names before one was available that you liked. I have been in this situation many times and it is extremely frustrating. If each of the domain names were taken by other legitimate sites, it would be one thing. However, almost all domain names are registered by squatters whose sole purpose is to extort us, the rest of the people in the world who want good domains for their websites. Webmasters are not the only ones who have to bear this burden – everyone who uses the internet suffers by having to type in and remember longer and less-relevant domain names even though better ones are available.

Just like spammers, everybody hates what domain squatters do to the internet. Unlike junk e-mail, however, domain registration is controlled by central authorities who should be able to stop widespread domain squatting. You may wonder how domain squatting relates to security and why an article about it appears on this blog. Once you start considering actual policies that ICANN would put in place to combat domain squatting, they almost all seriously hinder legitimate registrants or suffer from loopholes that would allow domain squatters to continue their operations unimpeded. This article explores policies that ICANN may be able to enforce to make headway against the internet plague that is domain squatting.

(more…)

Are you concerned about protecting confidential data on computers in your organization? Sometimes it can be difficult, even for security experts, to know exactly what they are up against. This article not only enumerates threats to confidentiality, but also compares the ability of different security products to combat these threats. The resulting threat matrix paints a clear picture of exposure. This matrix also highlights the role of my own security software, Web Tap, which is partially responsible for the recent reduction in blog post frequency.

(more…)

Mengjun Xie et al. presented a paper today on detecting and suppressing IM-based malware using a honeypot approach. The idea is to create decoy IM accounts and add them to random users’ buddy lists in an enterprise environment. Then, when these accounts are hit with file transfer requests or links to malicious software, HoneyIM sounds an alarm and detects the infection. Unfortunately, their approach only works on so-called “hit-all” worms that go after every user in your buddy list, which the authors admit in the paper. HoneyIM would not work against a worm that interjected links in the middle of conversations, for example. It would also fail against targeted attacks with a human behind the keyboard. This article suggests a better, alternative approach to the problem of IM malware that would detect even one instant message containing a malicious link. (more…)