Cheque management application – Security Testing Handbook for Banking Applications

4: Security Testing Repository
132
An attacker issues a loan without document verification:
o Check if a user can bypass document verification
using parameter manipulation.
An attacker issues a loan without checking the
customer’s credit history:
o Check if a user can delete a customer’s credit history
using SQL injection.
o Check if a user can bypass document verification
using a replay attack or parameter manipulation.
An attacker views all loan-related and personal data of a
customer:
o Check if privileged data can be accessed without
logging into the application.
o Check if sensitive data is visible in browser
cache/history.
o Check if a user can view sensitive data of another
user using parameter manipulation.
An attacker changes details of post-dated cheques issued
by a customer:
o Check if a user can change data of post-dated cheques
using parameter manipulation.
o Check if a user can exploit weak permissions on
shared folders where cheque images are kept and
replace them with fake images.
Cheque management application
Cheques are not as widespread a means of money transfer
as they used to be a decade ago – however they still form an
important and significant part of the national and
international banking industry. The cheque management
4: Security Testing Repository
133
(CM) application is used to track the lifecycle of cheques
issued by the bank’s customers to beneficiaries.
When a chequebook is issued to a customer, the details are
also entered in the CM application – serial number of
cheques, customer name, account number, date mailed, etc.
Later when the customer makes payments using these
cheques, the bank clears these cheques and keeps track of it
in the CM application.
For example, a key feature of the CM application is to
handle credit card payment cheques deposited at ATMs.
These cheques are collected by sales representatives from
ATMs and drop-boxes and submitted to the cheque clearing
department. The cheque number and amount are verified
and entered into the application. In certain applications
we’ve seen there’s a provision to scan cheques directly and
eliminate all manual data entry. The physical security of the
cheques and the storage location of the image files it
generates after scanning them becomes of key importance
in this case. The scanning application might be separate or
integrated with the CM application.
The cheque clearing employee makes a comment against
each cheque specifying whether it is accepted or rejected
due to insufficient funds. In case the cheque is accepted
there’s no problem and the funds are debited and credited
from the respective accounts. In case it’s rejected it will be
handled by the same module which handles bounced, re-
bounced or re-presented cheques.
Another common feature of all CM applications is
automated clearing house (ACH). All deposited cheques
from other banks are collected, sorted and sent to the
respective banks for clearing. Once they clear a cheque the
respective amounts are transferred to the bank. ACH is an
4: Security Testing Repository
134
automated process which runs at end of day (EOD)
everyday, disruption of this process could lead to cheques
not being deposited on time. In case this EOD process is
managed through the application, then it’s a critical part of
the application and needs to be tested well.
The CM application is also responsible for keeping track of
post-dated cheques. For instance, a customer might be
paying loan instalments through post-dated cheques. The
loan management application works in concert with the CM
application. It determines when to debit an instalment, how
much interest is calculated for faulty cheques, etc. These
details are transferred to the core banking system on the due
date.
Threat profile
An attacker issues a chequebook to a user without it
being requested.
An attacker modifies the user–chequebook mapping in
the application.
An attacker modifies the number of free cheque leaves
that are allotted to a specific user.
An attacker enters a cheque amount different from that
present on the cheque before submitting it to the
application.
An attacker changes the status of a re-presented cheque
to bounced.
An attacker changes the status of a bounced cheque to
re-bounced or re-presented.
An attacker submits cheques to the application without a
physical cheque being present.
4: Security Testing Repository
135
An attacker gains unauthorised access to the directory
where the cheque image files are stored.
An attacker disrupts the ACH process of cheque
collection leading to delays in clearance.
An attacker gains access to the post-dated cheque
module and manipulates cheque details accessed by the
LM application.
An attacker changes the due date of post-dated cheques.
Test plan
An attacker issues a chequebook to a user without it
being requested:
o Check if a user can issue a chequebook by
manipulating the account number and changing the
‘chequebook requested’ flag to ‘yes’.
o Check if a user can order chequebooks for all users
using SQL injection.
An attacker modifies the user–chequebook mapping in
the application:
o Check if a user can change database entries using
SQL injection.
An attacker modifies the number of free cheque leaves
that are allotted to a specific user:
o Check if a user can modify the free cheque leaves
parameter in their request using parameter
manipulation.
o Check if a user can grant themself more cheque
leaves using SQL injection.
4: Security Testing Repository
136
An attacker enters a cheque amount different from that
present on the cheque before submitting it to the
application:
o Check if a user can manipulate the cheque image
before it is submitted to the application.
o Check if a user can bypass cheque amount
verification using parameter manipulation.
An attacker changes the status of a re-presented cheque
to bounced:
o Check if a user can change the cheque type to
bounced using parameter manipulation.
o Check if a user can be tricked to change the type of
cheques using a CSRF attack.
o Check if a user can change types of all cheques using
SQL injection.
An attacker changes the status of a bounced cheque to
re-bounced or represented:
o Check if a user can change the cheque type to re-
bounced using parameter manipulation.
o Check if a user can be tricked to change the type of
cheques using a CSRF attack.
o Check if a user can change types of cheques using
SQL injection.
An attacker submits cheques to the application without a
physical check being present:
o Check if a user can create a fake image of the cheque
and enter details into the application.
An attacker gains unauthorised access to the directory
where the cheque image files are stored: