The banking applications are extremely important and face several types of threats. Software testing engineers face tough challenge in tackling such threats. The most effective approach to ensure the security of such banking applications is to follow a secure development lifecycle and take care of security right from the beginning i.e. design and code level.

The approach of secure development lifecycle works well for the future applications; but the concern remains for thousands of applications already in use. Hence two prime questions come to the mind of software testing personnel, that are:

1) Attacking the application in all possible ways – of course with the permission of the owner of the application.

2) Fixing the weaknesses found.

All this is not an easy task, as it needs a structured approach for testing such applications. We need to pick up a good start point & ensure that all possibilities are covered. We can build a structure if we can get clue of how the attacker will attack the application.

Some attackers attack the application just for the fun sake while some of them do it for their own gains like stealing credit card information or changing the address of another user. Since every attacker is having different goals, our task becomes more difficult & we need to cover all the possible options and enlist all possible threats.

When an attacker is at work, he has a definite motive like siphoning out funds from a user’s bank account. He will try out different attack techniques to realize this motive. But we as software testing person have to defend against all the different motives that different attackers may have. That is what a threat is – the goal of an attacker.

Now we will consider the second & third steps i.e. creation of threat profile & the test plan in more detail.

The exhaustiveness of the threat profile is a big challenge. We can use the following four-step approach to create a near-complete sample threat profile.

2) What does the application do? An Internet banking application offers several features say for example:

# The application allows users to check their account statements
# The application allows users to transfer funds.
# And many more such features are possible

2) Sensitive actions could be
# Check account summary.
# Transfer funds.

# View transaction details of other users
# Modify transaction details of other users
# Delete transaction details of other users
# Add transaction details of other users.

# View balance funds in another user’s account statement
# Modify balance funds in another user’s account statement
# Delete balance funds in another user’s account statement
# Add balance funds in another user’s account statement.

The last three statements do not make sense, because the balance is calculated from transactions and cannot be directly changed; hence we can drop them. This leaves us with five threats to the application.

We can generate a few more threats by trying to violate sensitive actions. For example in this case, that would be:

# Check account statement of other users
# Transfer funds from another user’s account.

# View transaction details of other users
# Modify transaction details of other users
# Delete transaction details of other users
# Add transaction details of other users
# View balance funds in another user’s account statement
# Check account statement of other users
# Transfer funds from another user’s account.

We can use more expressive words to state these threats more clearly. For example, consider the fourth threat above "add transaction details of other users". That can be better stated as, say "add fake transactions on behalf of other users".

# View transaction details of other users
# Modify transaction details of other users
# Delete transaction details of other users
# Add fake transactions on behalf of other users
# View balance funds in another user’s account statement
# Check account statement of other users
# Transfer funds from another user’s account.

Let us consider the first threat ‘View transaction details of other users’. Its possible attack vectors can be:

1) Tamper with the SQL query formed by the application to check the transaction details so that the details of other users can be viewed via SQL injection.

2) Change the account number in the view transaction details request so details of another user can be viewed.

3) Access the transaction details page without logging into the application.

4) Access the transaction details from the browser cache of the user’s machine.

The tests that we will be carrying out will be:

1) Tamper with the SQL query formed by the application that updates the database.

2) Change the source and destination account numbers in the fund transfer request.

3) Trick a user to perform a fund transfer via a CSRF (Cross-site request forgery) attack.

Similarly, we list down the test cases for each threat to create a complete test plan, which will look like:

# Check if the SQL query formed by the application to retrieve the transaction details can be tampered with via SQL injection.

# Check if the account number in the view transaction details request can be tampered with so details of another user can be viewed.

# Check if the transaction details page can be accessed without logging into the application.

# Check if the transaction details can be viewed in the browser cache of the user’s machine.

# Check if the SQL query to modify the transaction details can be tampered with via SQL injection.

# Check if the account number in the modify transaction details request can be tampered with.

# Check if the SQL query to delete the transaction details can be tampered with via SQL injection.

# Check if the account number in the delete transaction details request can be tampered with.

# Check if the user can be tricked to delete transaction details via CSRF (Cross-site request forgery) attacks.

# Check if the SQL query to add a transaction can be tampered with via SQL injection.

# Check if the account number in the add transaction request can be tampered with.

# Check if the user can be tricked to add a transaction via CSRF attacks.

# Check if the SQL query formed by the application to retrieve the balance funds can be tampered with via SQL injection.

# Check if the account number in the view balance request can be tampered with so the balance of another user can be viewed.

# Check if the view balance page can be accessed without logging into the application.

# Check if the balance funds can be viewed in the browser cache of the user’s machine.

# Check if the SQL query formed by the application to retrieve the account statement can be tampered with via SQL injection.

# Check if the account number in the view account statement request can be tampered with so account statement of another user can be viewed.

# Check if the view account statement page can be accessed without logging into the application.

# Check if the account statement can be viewed in the browser cache of the user’s machine.

# Check if the SQL query formed by the application to update the database can be tampered with via SQL injection.

# Check if the source and destination account numbers in the funds transfer request can be tampered with.

# Check if a user can be tricked to perform a fund transfer via a CSRF attack.

Tags: Security Testing, Software Testing

Many More Articles on Risk Analysis & Security Testing

If you want to keep track of further articles on Software Testing, I suggest you to subscribe my RSS feed. You can also Subscribe by E-mail and get All New articles delivered directly to your Inbox.