İstanbul evden eve nakliyat Beylikd®Ļz®Ļ evden eve nakliyat Tuzla evden eve nakliyat
Security Penetration Testing-A Software Testing Technique for Banking Applications
Delicious Bookmark this on Delicious
software testing genius

Security Penetration Testing-A Software Testing Technique for Banking Applications

Welcome to “Software Testing Genius”. Subscribe to my RSS feed for latest content on Software Testing.

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

Largest Database of Sample Papers - 1000+ Unique Questions for ISTQB Foundation Exam

ISTQB Foundation Exam - Full Crash Course for Download

ISTQB Advanced CTAL Test Analysts Exam - Full Crash Course for Download


ISTQB Advanced CTAL Test Manager Exam - Full Crash Course for Download


What Successful Testers say about the Quality of this website

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.

Get your Absolutely Free Copy of Several MS PowerPoint Presentations & E-Books related to ISTQB, HP Load Runner, IBM RFT, HP QTP & QC Certification Exams, prepared by Popular Writers & Trainers, by writing to: Software.testing.genius@gmail.com

Full Study Material for Popular Certification Exams:

Study Material - HP QTP & QC Certification Exam

Study Material - IBM RFT Certification Exam

Study Material - HP LoadRunner Certification Exams for All Modules

Study Material - ISTQB Certification Exam

Most Popular Topics in Demand:

Practical Roadmap to QTP Certification

Practical Roadmap to CSTE Certification

Consolidated Study Material - Testing & QA

Rehearsal of QTP in 1 Hr. -  Interview Questions

 

Comments :

comments ↓


Leave Your Comments: (*) Marked Fields are Mandatory

You can apply basic formatting to the text

Name *
 
Email Address *
 
Website
 
Speak your mind
characters
sex hikayeleri