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.
1) How do we find & secure them before an attacker grabs them?2) How can we predict the likely actions of an attacker?
The best solution is to be proactive & try to be an attacker ourselves.
Application penetration type software testing primarily involves two activities like:
1) Attacking the application in all possible ways � of course with the permission of the owner of the application.
2) Fixing the weaknesses found.
Main steps for structured application penetration testing are:
Step-1: Understand the application:
Before a penetration software testing person starts any testing, he needs to first understand the application and how it works like, its features, its functionality, the business rules and the data.
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.
Step-2: Preparation of a threat profile:
The threat profile is the basis of the entire penetration type software testing. It involves listing down all the possible threats to the application. In other words, we list down all the possible motive attackers may have in targeting the application. Now, this is the most important step in a thorough penetration test as the actual software testing that we carry out is completely dependent on the quality of the preparation: the more exhaustive a threat profile is the more thorough the test will be.
Step-3: Preparation of a test plan:
Once the threat profile is ready, we can start thinking of what attack techniques to try out. For each threat in the threat profile, we list down all the possible ways of realizing it. For example, we can try to view another user�s account information by either an SQL injection attack or by manipulating the request variables or by accessing the information from the browser cache. The test plan has a list of exact test cases that will be tried out for each threat. Each test case will specify the page and the variable where the test will be tried out. This detailed test plan serves an important purpose: it ensures a thorough test is carried out and that no attack vector for any threat is left unexplored.
Step-4: Execution of the test cases:
With a complete test plan in hand, the task of actual testing becomes easy. The penetration software testing engineer now only has to concentrate on carrying out each test case from the test plan. But this too is not s simple activity. As each test case is executed, there may be a need for more tests to confirm the results.
Step-5: Preparation of a report:
A detailed report is then prepared, based on which the application can be secured. Along with the security weaknesses observed, the report also has details of the impact it would have on the business, the ease of exploiting it and the risk rating. It also describes how the exploit was carried out with screenshots wherever required. There is a recommendation section for each finding which explains how the vulnerability can be fixed.
Now we will consider the second & third steps i.e. creation of threat profile & the test plan in more detail.
How do we prepare an effective threat profile for a banking application?
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.
Step-1: Ask yourself two questions like
1) Who are the users? These could be the Internet banking customers.
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
Step-2: Identify sensitive items like
1) Sensitive data could be
# Transaction details
# Balance funds in the account.
2) Sensitive actions could be
# Check account summary.
# Transfer funds.
Step-3: Write
1) View / modify / delete / add sensitive data: We generate possible threats by prefixing view / modify / add / delete for the sensitive data. Some of the statements might not make sense, in which case you can exclude them.
Management of the first item of sensitive data i.e. �Transaction details� and generate potential threats.
# View transaction details of other users
# Modify transaction details of other users
# Delete transaction details of other users
# Add transaction details of other users.
Management of the second item of sensitive data i.e. �Balance funds� and generate potential threats.
# 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.
This makes a total of following seven threats to the application:
# 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.
Step-4: Refine the language
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 the following 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.
How should we prepare an effective test plan?
For the above mentioned threat profile, let�s see how a test plan is prepared. The idea here is to list down all the possible attack vectors for each threat.
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.
Let us consider the last threat in our threat profile above i.e. �Transfer funds from another user�s account & list down its test cases.
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:
A) View transaction details of other users:
# 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.
B) Modify transaction details of other user:
# 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.
C) Delete transaction details of other users:
# 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.
D) Add fake transactions on behalf of other users:
# 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.
E) View balance funds in another user�s account statement:
# 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.
F) Check account statement of other users:
# 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.
G) Transfer funds from another user�s account:
# 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.
0 Comments