Chapter 1: Approach to Security Testing – Security Testing Handbook for Banking Applications

We’ve seen how important banking applications are and the
kind of threats they are faced with. The most effective
approach to securing them would be to follow a secure
development lifecycle and take care of security right from
the design and code level. This would work for future
applications; but what about the thousands of applications
already in use? How do we secure them before an attacker
gets to them? How can we predict an attacker’s actions?
We can’t do this without becoming attackers ourselves.
That’s what application penetration testing is all about –
first (with the application owner’s formal, documented
permission) attack the application in all possible ways and
then fix the weaknesses found.
That’s easier said than done. Where do we start and how
can we be sure all possibilities have been covered? What
we need is a structured approach for testing these
applications. We can come up with a structure if we
understand how an attacker will go about attacking an
application. Though a few do it for fun, for most it is
serious business. They are after some specific goal like
stealing credit card information or changing the address of
another user. Since different attackers may attack the
application for different goals, we need to think through all
the possible options and list all the possible threats.
Here are the main steps we follow in a structured
application penetration test:
Understand the application.
Prepare the threat profile.
1: Approach to Security Testing
Prepare the test plan.
Execute the test cases.
Prepare the report.
The developers or the end users will not be testing the
applications. It requires professional penetration testers
with expertise in attack techniques and security. Before a
penetration tester starts any testing, they have to first
understand the application and how it works – the features,
the functionality, the business rules and the data.
When an attacker is at work, they have a definite motive
like siphoning off funds from a user’s bank account. They
will try out different attack techniques to realise this
motive. But we have to defend against all the different
motives that different attackers may have. That is what a
threat is – the goal of an attacker. So, in the second step of
our penetration test, we list down all the possible threats to
the application. In other words, we list down all the
possible motives attackers may have in targeting the
application. Now, this is the most important step in a
thorough penetration test as the actual 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. We’ll discuss creating a threat
profile in greater detail in a later section.
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
realising 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