Preparing the test plan – Security Testing Handbook for Banking Applications

1: Approach to Security Testing
22
transfer funds from another user’s account.
We thus have seven threats so far:
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.
Finally, refine the language
See if 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’.
So, finally we have this revised threat profile:
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.
Preparing the test plan
For this sample threat profile, let’s see how a test plan is
prepared. The idea here is to list down all the possible
1: Approach to Security Testing
23
attack vectors for each threat. Let’s take the first threat:
‘view transaction details of other users’.
The possible attack vectors are:
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.
Change the account number in the view transaction
details request so details of another user can be viewed.
Access the transaction details page without logging into
the application.
Access the transaction details from the browser cache of
the user’s machine.
Let’s take a look at another threat. Let’s list out the test
cases for the last threat in our threat profile above: ‘transfer
funds from another user’s account’. (We shall discuss these
tests in greater detail in the next chapter, so never mind if
you don’t follow the exact tests yet.)
The tests that we will be carrying out will be:
Tamper with the SQL query formed by the application
that updates the database.
Change the source and destination account numbers in
the fund transfer request.
Trick a user to perform a fund transfer via a CSRF
attack.
Similarly, we list down the test cases for each threat to
create a complete test plan. The test plan for our sample
threat profile would look like:
View transaction details of other users:
1: Approach to Security Testing
24
o Check if the SQL query formed by the application to
retrieve the transaction details can be tampered with
via SQL injection.
o Check if the account number in the view transaction
details request can be tampered with so details of
another user can be viewed.
o Check if the transaction details page can be accessed
without logging into the application.
o Check if the transaction details can be viewed in the
browser cache of the user’s machine.
Modify transaction details of other user:
o Check if the SQL query to modify the transaction
details can be tampered with via SQL injection.
o Check if the account number in the modify
transaction details request can be tampered with.
Delete transaction details of other users:
o Check if the SQL query to delete the transaction
details can be tampered with via SQL injection.
o Check if the account number in the delete transaction
details request can be tampered with.
o Check if the user can be tricked to delete transaction
details via CSRF attacks.
Add fake transactions on behalf of other users:
o Check if the SQL query to add a transaction can be
tampered with via SQL injection.
o Check if the account number in the add transaction
request can be tampered with.
o Check if the user can be tricked to add a transaction
via CSRF attacks.
View balance funds in another user’s account statement:
1: Approach to Security Testing
25
o Check if the SQL query formed by the application to
retrieve the balance funds can be tampered with via
SQL injection.
o Check if the account number in the view balance
request can be tampered with so the balance of
another user can be viewed.
o Check if the view balance page can be accessed
without logging into the application.
o Check if the balance funds can be viewed in the
browser cache of the user’s machine.
Check account statement of other users:
o Check if the SQL query formed by the application to
retrieve the account statement can be tampered with
via SQL injection.
o Check if the account number in the view account
statement request can be tampered with so account
statement of another user can be viewed.
o Check if the view account statement page can be
accessed without logging into the application.
o Check if the account statement can be viewed in the
browser cache of the user’s machine.
Transfer funds from another user’s account:
o Check if the SQL query formed by the application to
update the database can be tampered with via SQL
injection.
o Check if the source and destination account numbers
in the funds transfer request can be tampered with.
o Check if a user can be tricked to perform a fund
transfer via a CSRF attack.