Security Penetration Testing – A Software Testing Technique for Banking Applications
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) 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.
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.
Ideally, who should do the penetration type software testing?
The developers or the end users should never do the penetration testing of the applications. For this we should deploy special software testing professionals having sound expertise of penetration type software testing using attack techniques and security.
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.
Tags: Security Testing, Software Testing
Many More Articles on Risk Analysis & Security Testing
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.
I was looking for some good tips for testing of security aspects of banking applications since quite some time & today I got the descriptive article. I liked this article a lot becoz it is quite self explanatory. Thanx . Harsh
Fantastic article on Security testing. Its really very clear.
Neha
From my understanding on penetration testing, a penetration-test (actually, we prefer the term security assessment) is the process of actively evaluating your information security measures. Please correct me if I am wrong
Thanks Moderator for the very useful information on Penetration testing, Security Testing and related stuff. I am sure it would be like Ready made Test Scenarios written already for some of the testers who are working in the same field.
Hope to see good articles like this with some more Automation stuff in it.
Thanks
Suresh
Hello Carrie Wainer, Thanks for adding the term Security Assessment aimed at hunting for security issues in the applications
Hi Yoginder,
Its really helpful. I was searching for long time. Helped a lot.
Thanks,
Hema.
I have few job openings with Accenture for Manual testing Professionals for 3-8 experience level. Job Location: Pune.
In case anyone is interested, then send your CVs to nischal.sl@accenture.com
Hi,
I am hiring QA Engineers for ORACLE Czech! Anyone looking for Software Quality Assurance engineer position, then let me know.
Regards,
Vendula
Hi friends,
Can anyone please answer me which automation testing tool is more popular now a days out of the tools: QTP, TestComplete, Selenium, Watir and Rational Functional Tester.
Hi Caroline,
I can try to answer your question based upon casual observation of discussions on various QTP forums on internet
1. QTP is still a market leader amongst various automation tools.
2. QTP has started losing the market share to selenium which is growing very fas
3. Test Complete is good tool and looks very promising.
However, I would say that dont go by the people rather use the tool which suits your testing approach and test environment.
I will vote for Watir (and the associated Ruby libraries), even though I have not worked much on Watir. Currently we are working on QTP frameworks. I have tried selenium also but for some strange reasons I dont like it.
I second Williams. I agree that Watir is very powerful but since not many people know about Ruby, I believe that its not getting too much of focus while selenium is quite hot cake these days because of most popular Java and python.
This discussion is going very interesting. However, I can not see anyone mention about Watin even though its not in the list of Caroline. In Watin, tests are written in C# language.
Hi friends, I would like to add my thoughts here. I have been working with QTP for many years but still I will vote for Selenium as the tool which is gaining more popularity specially with the upcoming Selenium 2.0. Also, its an open source tool. However, being an open source tool doesnt mean it is always better. Selenium is still evolving but I can see that the learning curve is a bit difficult as compared to QTP. You need to have a full fledged java programming background to work with Selenium which doesnt happen with most of the testers.… Read more »
I am finding it very strange but nobody is talking about ranorex here. I will recommend ranorex to those people with a real programming background. It has great error handling and debugging facilities. It also supports WPF, Windows form and many controls of Web based version.