1. What kind of vulnerabilities did the study examine?

We primarily focused on vulnerabilities that should be obvious to a careful visitor to a web site by simply examining the site's contents and its rendering in a browser. Some of the vulnerabilities we examined could make it difficult for a customer to know if they are seeing content provided by the bank or by an attacker.

An example of a common design flaw is providing a login window on an insecure web page. Most banks have code behind the web page that submits the login information securely, but there is no obvious way for a customer to know that by examining the URL or the page's rendering in a browser. We found that we could mirror such a bank's web site fairly easily and, if the user is on insecure network, mount an attack that would capture a user's id and password without the browser or the user being able to distinguish the real site from the mirrored site.


2. Why would user be on an insecure network?

Users can be on insecure networks frequently. If you are connecting to the Internet from an Internet cafe or from a hotel, you have no way of knowing if you are on a secure network.  

It is also well known that vulnerabilities in the DNS (Domain-Name Service) can also cause you to visit a spoofed page without affecting the URL displayed in the browser.

3. What can banks do to eliminate the design flaws?

To start with, all their web pages should be available *only* on secure sessions. As a user, you can tell whether a page is on a secure session by observing if the URL starts with "https://your-bank-web-site/".

Many banks also redirect a user to a third-party site for some services, such as authentication. When that happens, the new site should be be properly introduced (from a secure page owned by the bank) so that the user is made aware that they are visiting a trusted third-party site. Without that, there is a potential for user confusion.

4. Doesn't the presence of the padlock in the Login Box tell me (as a customer) that the information will be submitted securely  to my bank?

No. If a hacker were to mirror the site to create a spoofed site and can make you visit that, the padlock will also get mirrored.  The padlock or any other similar words (Secure Login, etc.) provide no guarantees.  

5. What can users do in view of the study?

First thing is not to panic. The flaws we discuss in the paper are not the type that can be exploited easily by remote attackers or script-kiddies. In general, exploiting the flaws would require you to use an unsafe network, such as a 
wireless network that you do not control.  

(Note: Unfortunately, bugs in Domain Name Service, which translates hostnames 
to IP addresses could theoretically extend the reach of the attackers to allow remote attacks.  On July 11th, CERT issued an advisory for a massive multivendor patch to DNS.  As per the advisory, any unpatched Name Server could 
be potentially compromised)

We do recommend you review your bank's web site carefully in light of the study so that you are aware of its security flaws.  If you find flaws, use the site carefully to minimize the risks. The most basic flaw is your bank serving you content on a non-HTTPS page. You can tell that by examining the URL in your browser. The URL should start with https://your-bank-web-site/...  If you do not see that, then you need to avoid connecting to the bank from networks that you do not control or completely trust.  

As authors, we continue to maintain accounts at some of the banks that may have these flaws because of the conveniences or other benefits  banks provide, but we educated ourselves about safe web site usage and are aware of the risks. To minimize the risks, we recommend against using the sites, unless essential, when on an unknown wireless network, unless the web site follows the guidelines in our study.  We decided to do this study partially because we saw these problems at
the sites we banked at and saw that the problems were not unique to our own banks.


7. What are the limitations of the study?

We analyzed over 200 sites from a source indicated in our study (http://www.quazell.com/bank/bank_usa.html). Most of the sites were banks' web sites. Note that some of the links were found to be to non-working links or just links to historical banks, many of which we attempted to filter out. In most cases, inclusion of such links in our study would have caused us to underestimate the percentage of bank sites with flaws, since non-working links or information links would be classified as being without security-related design flaws. 

We may have failed to completely retrieve all relevant pages and did not examine pages after a user logs in, since
we did not use userids or passwords to authenticate to the sites. (Impact: our automated
analysis would in general under-estimate the percentage of sites with flaws if we didn't retrieve the entire site. 
For example, a site that we were unable to retrieve would be reported as not having any flaws).  

In some cases, bank sites use more complex HTML processing, such as nested frames. In those cases, to a user, the Login Window may appear on their home page (insecure), but our automated analyzer may consider that to be on a different page.
In that case, again, we would underestimate the percentage of sites with flaws.

We only looked at a fraction of financial institutions and that too only U.S.-based institutions.

We used heuristics for automated analysis that could cause us to over-estimate or under-estimate the
errors (primarily related to policies for userids and passwords and email communication).

We may have made errors in evaluating sites that we examined manually 

The bottom line is that it appears that the problems we highlight are quite widespread. We are most concerned about the the lack of use of SSL on *all* pages and unexpected redirections to 3rd-party sites, which are very common. 

Banks can address those concerns by using a single domain name for the entire site and protecting all the pages using SSL (https).  Customers then have a better shot at telling apart spoofed or fake pages from real pages.


8. Can you make the detailed results for individual banks available?

No. We chose to not make individual site results public at this time. It is not clear if that will serve a positive purpose. We already give a few examples of specific sites to simply illustrate the points in the paper. Furthermore, we may have missed flaws that exist (see Limitations above), so listing a site as not having flaws would not necessarily imply that it lacks the flaws. In most cases, customers need to educate themselves and do their own due diligence on their banks or financial institutions to see the extent to which they have problems.  

In the end, our work will  hopefully lead to more consistent and simpler financial web sites: those that stick to a single domain preferably, consistently use SSL for all interactions with customers, and adapt clearly stated policies.  Hopefully, then customers will have a better shot at identifying content that they should not trust when they attempt to visit financial sites.