CSC-682 Advanced Computer Security Analyzing Websites for User-Visible Security Design Flaws Pompi Rotaru Based on an article by : Laura Falk, Atul Prakash, Kevin Borders

Banking trends Internet has become part of our life Large number of people have given up conventional banking in favour of online banking People conduct both their personal and job-related business using these sites 42% of all internet users bank online Forbes.com conducted a survey on +900 people and divided users in: used online banking applications and paid bills online through their bank’s website used online banking applications but not online bill payments used no online banking activities whatsoever

How banks deal with online security Due to the sensitive nature of these sites, security is a top priority Hire security experts to conduct vulnerability assessments Deploy encryption protocols such as SSL Use firewalls and routers Monitoring accounts for suspicious activities User Identification (User ID + Passwords) Overall the online security has improved compare with a few years ago

This study – general considerations Conducted during Nov - Dec 2006 Analyses 214 U.S. financial institutions for user-visible security design flaws It is not focused on poor or confusing client-side interfaces, but on flaws that originate in poor design at the server that prevent users to make correct choices from the perspective of securing their transactions Design flaws are a result of decisions made during the website design phase and they promote insecure user behaviour These design features made it very difficult for someone to use the site securely

This study Use a tool for automatically detecting flaws They used “wget” to recursively download the financial institution websites and scripts to traverse and analyze the HTML pages They looked for :  break in the chain of trust  presenting secure login options on insecure pages  contact information/security advice on insecure pages  inadequate policies for user ids and passwords  ing security sensitive information insecurely

What they found 30% of the sites broke the chain of trust 47% presented a login page on an insecure page 55% presented contact and other sensitive information on insecure pages 31% allowed addresses as user names only 24% of the sites were completely free of these design flaws

1 Break in the chain of trust 30% (17 % gave no notification) of the banks tested were affected Violates: inadequate security context for informed decisions Customer is redirected to a site that has a different domain name than the financial institution’s site that was originally visited The switch is usually done without warning customers about such redirection Now it is up to the user to determine if the new site is really affiliated with the financial institution Solution (proposed by article): provide adequate notifications before taking the user to third-party sites and to always make such transitions from secure pages

2 Presenting secure login options on insecure pages 47% of the banks tested were affected Violates: embedding sensitive forms on insecure web pages Login pages and options displayed on insecure pages leave users vulnerable to man-in-the-middle attacks Some web sites use embedded JavaScript code for the login window and submit the information via SSL, but user has no way of knowing Some show a picture of a lock and the phrase “Secured with SSL” technology but this provides a false sense of security Other examples of this style include password-reset or new accounts forms that are embedded in insecure pages

3 Contact information/security advice on insecure pages 55% of the banks tested were affected Violates: not securing security-relevant context Provide bank's contact information or security advice in an insecure page Allows modification of the page by replacing the customer service phone numbers with bogus numbers Then crooks answer the phone and ask for SSN, birth date, or other confidential information

4 Inadequate policies for user ids and passwords 31% of the banks affected allow addresses as user names Violates: hard-to-guess credentials One study concluded that a strong username could be more important then a strong password Users should not use the social security numbers and addresses for user ids (easy to guess or collect) No policy on allowed passwords creates weak passwords making them vulnerable to dictionary attacks

5 ing security sensitive information insecurely Violates: confidentiality s could be used to sent sensitive information to customers If passwords are ed through an insecure mail server, an attacker could intercept unencrypted traffic on the network and obtain the sensitive information

 Are these security design flaws ? Displaying “Welcome back first_name” in insecure page before user logs on Not providing a “log off” button after user has finished making a payment and wants to leave the site.

Results With automated tools (such as this one) false positives are possible They tried to manually eliminate them wherever was possible Especially the “break-in-chain-of-trust” test has a significant number false positives (30 % reported but in fact there were only 17%) Most sites made an effort to provide good policies for user ids and passwords 68% had 2 or more design flaws 10% of the sites had all five design flaws

Sources of errors Some pages could not be completely retrieved due to wget's inability inability to handle JavaScript Possibility of human error in the manual inspection process to eliminate false positives Due to the way the test was conducted it is possible that not all the problem pages were discovered

Conclusions 76% of sites have at least one design flaw 24% of sites were completely free of design flaws Most financial websites today are taking traditional steps for securing their websites, such as the use of strong credentials A small fraction were found to not provide adequate enforcing of password policy or rely on easy-to-harvest user ids Shows that the current set of web security analysis and design techniques still leave significant security gaps They recommend that web developers employ these techniques when performing web security evaluations In the future the authors plan on evaluating additional design flaws

Questions ? ???