Back-office trading application – Security Testing Handbook for Banking Applications

4: Security Testing Repository
153
An attacker deletes/modifies valid requests
created/approved by another user:
o Check if a user can delete/modify requests using
parameter manipulation.
o Check if users can be tricked to approve malicious
requests using CSRF attacks.
o Check if scripts can be embedded in inputs and
reflected to users to gain control of their sessions.
An attacker enables a disabled account:
o Check if a user can change the value of a disabled
flag to ‘enabled’ by using parameter manipulation.
o Check if user can be tricked to approve a malicious
request using CSRF attacks.
An attacker adds a new service to the application even
before it has been approved:
o Check if a user can modify the services offered
during account opening by parameter manipulation.
Back-office trading application
Customers use the front-end trading engine to buy and sell
securities. The back-office is the administrative back-end
for the trading front-end. As the name suggests, the back-
office trading application is used to perform back-office
operations for the front-end trading engine.
The back-office application has several functions:
create and maintain trading accounts for customers;
validate trades performed in the front end – an additional
layer of validation;
clear and settle trades done in a day;
provide information systems to analyse the activity;
4: Security Testing Repository
154
generate reports for various activity;
ensure credit is given out properly;
comply with securities trading regulations.
The reports generated by back-office trading applications
include:
volume of trades across days;
list of accounts with very high volume of trades;
list of scripts that are most heavily traded;
new accounts opened during a period.
The back-office applications are used by internal bank
employees with sufficient security clearance – they have
access to a lot of sensitive customer data, including details
of specific trades.
This is an internal application and can usually be accessed
only from the bank’s internal network.
Threat profile
An attacker adds/modifies/deletes valid trading accounts.
An attacker creates a deal directly and validates it on the
back-end systems.
An attacker rejects a successful deal already completed
by a customer.
An attacker gains unauthorised access to confidential
reports.
An attacker bypasses background checks while issuing
credit to users.
An attacker causes specific trades to violate specific
security regulations.
4: Security Testing Repository
155
An attacker performs a denial-of-service (DOS) attack
on the information systems that provide live tickers
(updates) for the front-end application.
Test plan
An attacker adds/modifies/deletes valid trading accounts:
o Check if SQL queries can be tampered with via SQL
injection.
o Check if the activity performed by a specific request
can be changed from ‘modify’ to ‘delete’ by another
user using privilege escalation.
o Check if user can be tricked to add/modify/delete
valid accounts via CSRF attacks.
An attacker creates a deal directly and validates it on the
back-end systems:
o Check if a user can modify their account’s privilege
level and approve a deal they created themself.
An attacker rejects a successful deal already completed
by a customer:
o Check if a user can set the ‘rejected’ flag to ‘yes’ by
using parameter manipulation.
o Check if a user can reject all successful deals by
tampering with SQL queries using SQL injection.
An attacker gains unauthorised access to confidential
reports:
o Check if an attacker can view confidential reports
using privilege escalation.
o Check if confidential reports are visible in browser
cache/history.