Generic threat profile and test plan – Security Testing Handbook for Banking Applications

4: Security Testing Repository
83
Generic threat profile and test plan
Before we create threat profiles and test plans for each of
these applications, it’s useful to remember that there are
some threats common to most applications. The tests for
these threats will also be common across all applications.
We extract these common threats and tests in a generic
threat profile and a generic test plan for applications. This
lets us avoid repeating these common threats and tests for
every banking application we discuss. The simplest way to
visualise an application’s full security test plan is as the
union of the generic test plan and the more specific test plan
for the application.
Generic threat profile
An attacker violates maker-checker controls.
An attacker violates the integrity of data in the
application.
An attacker bypasses the authentication system.
An attacker steals the password of other users.
An attacker shuts down the application.
An attacker hijacks the session of another user.
A local attacker steals sensitive data from the user’s
machine.
An attacker takes control of the underlying server.
An attacker evades audit trails.
Generic test plan
An attacker violates maker-checker controls:
o Check if all key transactions have maker-checker
facility.
4: Security Testing Repository
84
o Check if maker can escalate privileges to checker
with variable manipulation attacks and vice versa.
o Check if maker can escalate privileges to checker
with SQL injection attacks and vice versa.
o Check if maker can escalate privileges to checker
with CSRF attacks and vice versa.
An attacker violates the integrity of data in the
application:
o Check if the application verifies the integrity of the
data entered before accepting it.
o Check if the data type and range is verified before the
data is accepted.
o Check if the application validates inputs at the server
and not only at the client.
o Check if the application rejects special characters in
inputs.
An attacker bypasses the authentication system:
o Check if privileged data can be accessed without
logging into the application by pasting a deep URL.
o Check if the login feature can be bypassed with SQL
injection.
o Check if the password can be stolen by exploiting the
refresh feature of the browser, even after the user has
logged out.
An attacker steals the password of other users:
o Check if the password/sensitive data is sent in plain
text on the wire.
o Check if the plain text password is visible in the
browser’s memory even after the user has logged out.
o Check if the application allows user to set weak
passwords.
4: Security Testing Repository
85
o Check if the application provides a virtual keyboard
to defeat keystroke loggers.
o Check if bank makes users aware of the threat of
phishing.
o Check if bank implements technical controls to
mitigate the risk of phishing.
An attacker shuts down the application:
o Check if tables in the database can be deleted with
SQL injection attacks .
o Check if the database can be shut down with SQL
injection attacks.
o Check if application is vulnerable to denial of service
attacks.
o Check if application employs anti-bot strategies to
prevent flooding attacks (e.g. CAPTCHAs –
Completely Automated Public Turing test to tell
Computers and Humans Apart).
An attacker hijacks the session of another user:
o Check if session token is random.
o Check if session token is sent encrypted on the wire.
o Check if session token is invalidated on log out.
o Check if session token expires after a defined period
of inactivity.
o Check if application is vulnerable to cross-site
scripting attacks.
o Check if session cookie is marked ‘HTTPOnly’.
o Check if session cookie is marked ‘secure’ .
A local attacker steals sensitive data from the user’s
machine:
o Check if the <specific sensitive data> is visible in the
browser cache/history.