Security Testing Handbook for Banking Applications

By Arvind Doraiswamy, Sangita Pakala, Nilesh Kapoor and 4 more

The book is a manual for compliance with current and future regulatory compliance requirements; it may also be seen simply as a practical and comprehensive guide to best practice application security to support every person involved in this field.

• Language: English
• Publisher: itgovernance
• Release date: Feb 19, 2009
• ISBN: 9781849281089

Arvind Doraiswamy

Arvind Doraiswamy leads Paladion’s R&D team for Application Security. Arvind has tested 100+ banking applications and continuously refines the techniques used by Paladion to improve the quality of testing. They also contributes to the security testing database at www.vulnerabilityassessment.co.uk.

Book preview

978-1-849281-08-9

FOREWORD

In the last 20 years, the Internet has become the core infrastructure for the vast majority of individual and financial transactions and, as organisations migrate to what is increasingly known as ‘cloud computing’, so organisational dependence on secure Internet transacting will increase.

Of course, as the global economy goes digital, the global underworld follows suit. If money is stored on or moved around the Internet, the averagely intelligent criminal will migrate from physical (and often violent) crime to the more sophisticated, less dangerous and less violent options available online. The widespread growth in identify theft, supported by epidemics of phishing and pharming attacks, is just the most visible sign of this criminal migration from the physical world to the digital one.

Commercial self-interest should drive financial organisations to ensure that the applications that support their online activity, and those of their customers, are robust and secure. Oddly, it doesn’t seem to be an adequate driver for increased online security.

As usual, regulators are stepping into the breach. All EU countries, and many of their OECD trading partners now have well-established data protection legislation, and this is increasingly supported by fines and other non-financial sanctions. Very substantial quantities of personal data are collected and held electronically and, therefore, every data controlling organisation has to ensure that its applications are secure. Every US State now has some form of data breach legislation, mandating specific actions required of organisations if and when the security around personal data they hold is breached, and these actions can have significant costs and non-financial impacts.¹ The EU is discussing exactly such a directive to be extended across all its member states.

The Payment Card Industry Data Security Standard (PCI DSS) mandates specific security controls for all merchants that accept payment cards, whether online or offline. PCI DSS contains specific requirements around application security and application security testing. Of course, this is particularly important for online shopping carts and payment card applications. Compliance with PCI DSS is beginning to be mandated by US State legislatures.

In the US, any company that regularly extends or merely arranges for the extension of credit to individuals has to comply with what are known as the ‘Red Flag Rules’ with effect from 1 November 2008. These rules require companies to take the possibility of identity theft seriously, and to identify and ‘red flag’ specific forms of activity that indicate the possible existence of identity theft. The Red Flag Rules apply to a wide range of accounts, including credit card accounts, mortgage loans, vehicle loans, margin accounts, mobile phone accounts, utility accounts, and cheque and savings accounts. Companies are required, under this legislation, to take reasonable measures to ensure the safety of sensitive consumer information. The Rules are intended to ensure that organisations detect, prevent and mitigate the risk of identity theft. None of this can be done today without effective application security, and effective

¹ See the IT Governance Report: Data Breaches: Trends, Costs and Best Practices available from www.itgovernance.co.uk/products/1615

application security is directly dependent on the effectiveness with which it has been tested. This book could therefore be seen as a manual for compliance with current and future regulatory compliance requirements; it could also be seen simply as a practical and comprehensive guide to best practice application security that should guide and support every person involved in this field.

Alan Calder, Ely, February 2009

ABOUT THE AUTHORS

Arvind Doraiswamy leads Paladion’s R&D team for Application Security. Arvind has tested 100+ banking applications and continuously refines the techniques used by Paladion to improve the quality of testing. They also contributes to the security testing database at www.vulnerabilityassessment.co.uk.

Sangita Pakala is the Project Director for the Application Security practice at Paladion. Sangita is the lead author of the OWASP Application Security FAQ, and co-author of Application Security in the ISO 27001 Environment from ITGP. She has been invited to present at the RSA Conference 2006 and ISACA Europe 2005.

Nilesh Kapoor is a Project Leader in Paladion’s Application Security Testing team. Nilesh has tested 30+ applications including core banking applications, RTGS and ATM systems.

Prashant Verma is a Project Leader in Paladion’s Application Security Testing team. Prashant has tested 30+ applications including Internet banking, fraud monitoring and teller automation applications.

Praveen Singh is a senior security engineer in Paladion’s Application Security Testing team. Praveen has tested 30+ applications including payment systems, debit card management systems, loan management applications and core banking applications.

Raghu Nair is a senior security engineer in Paladion’s Application Security Testing team. Raghu has tested 30+ applications including credit card management systems, derivatives trading applications and core banking applications.

Shalini Gupta is the Project Manager for Banking and Finance at Paladion. She has tested 100+ banking applications for security in the last three years. Her team has tested 400+ banking applications for 30 banks in the last seven years.

CONTENTS

INTRODUCTION

Banks have always attracted wealth and crime alike. There have been numerous bank robberies, cheque frauds, etc. Before computers, banks used to fight the threat by having strong physical security and robust processes. Today the threat to banks is even greater, despite constant progress and innovation by the banks, equally matched by the criminals.

Most banking operations today have been computerised and all data is in electronic format. Banks and their branches are part of a huge network with sensitive data being sent back and forth electronically. A number of the applications used by banks are now online on the Internet. This opens up these applications and the confidential data they contain to even greater threats.

Considering all this, it may seem obvious that these applications should be built securely and should be resilient to attacks. But our experience in testing 1000+ banking applications shows that is not the case. Many applications are not built with security in mind. There are large applications built to accomplish complex tasks and designed for performance and speed. The designers and developers focus on functionality and features; security takes a back seat.

At the same time, cyber criminals are coming up with new attacks regularly.

The threat landscape

Gone are the days when having a complex password was all the security you required – an attack solely based on guessing passwords by brute force is a thing of the past. Now attackers are much more sophisticated and resort to more complex attack techniques. SQL injection, cross-site scripting and variable manipulation are some of the attacks in their armoury today. The attackers’ motives could range from stealing money from a user’s online bank account to bringing down the critical servers of a bank.

The SQL injection technique, for instance, can be used to implement many of these attacks. Most applications use SQL databases to store data. The application takes input from the user and forms an SQL query to retrieve or modify data in the database. The attacker enters a carefully crafted input which changes the underlying SQL query and manipulates the data in the database. Attackers can add, delete or modify important records like user names, banking account numbers, loan applications, etc. with this technique.

Cross-site scripting is another popular attack with criminals today. In a typical cross-site scripting attack, a user is tricked into visiting a malicious page which steals sensitive information like the user’s credentials.

An attack to which many applications in our experience are vulnerable is variable manipulation. A special tool called a web proxy editor is used to intercept the data travelling from the client to the web server. The intercepted data can then be modified before forwarding it. This lets an attacker realise a lot of critical threats – siphoning off funds from a user’s bank account, viewing user’s credit card details and performing illegal transactions in the name of another user are examples.

Today attackers focus on large-scale attacks like phishing and pharming, where they trick a large number of users into giving away their passwords. An attacker sets up a fake page on a server that resembles a bank’s website. An e-mail appearing to come from the bank is sent out to a large number of people. The mail requests the users to visit the fake site and enter their credentials. By convincing the user that their account has been deactivated or that they will get a prize for entering their credentials, some users fall prey to this.

Spyware and key loggers are also favourites among attackers. Spyware tricks users into downloading innocent-looking programs that in the background install other malicious programs like key loggers. The key logger then records all the key strokes of the user and sends them to the attacker; the gathered information usually includes the usernames and passwords for different applications that have been accessed.

Defences employed

To defend against all these threats, banks have started putting security defences in place for their applications. Both technical and process controls that are used.

To protect against passwords being stolen, two-factor authentication is used. Along with the normal password, a second authentication technique is required. Generally, two-factor authentication is described as ‘something you have and something you know’. An example is a bank ATM, where you use your ATM card which is something you have and you punch in a PIN which is something you know. Virtual keyboards are also now being deployed to prevent keystroke loggers.

Strong encryption techniques are used to protect the sensitive data in transmission. Websites like those for Internet banking and stock trading are configured to work on SSL (Secure Sockets Layer) where all data is transmitted in an encrypted format. For more critical applications where the data is highly sensitive and the user group is also smaller, client certificates are used for stronger encryption.

Secure applications take care to examine and validate every input before allowing critical transactions to take place. Not only are they coded