Debit card management system – Security Testing Handbook for Banking Applications

4: Security Testing Repository
119
o Check if sensitive reports are visible in browser
cache/history.
o Check if sensitive reports can be accessed without
logging into the application.
An attacker deactivates entries of others without
authorisation:
o Check if a user can deactivate other user entries using
parameter manipulation.
An attacker changes the schedule of credit card
statements being sent to the customer:
o Check if a user can turn off another user’s
subscription using parameter manipulation.
o Check if a user can modify the preferences of other
users using SQL injection.
Debit card management system
Most of us do not like to carry too much cash around when
we move around or travel. We’d much rather carry just
what we need. Mostly however we find it difficult to
predict how much we need. That’s why debit cards have
become ubiquitous. Anyone who’s got a valid account at a
bank can withdraw money from an ATM based on their
requirements using a debit card. Before customers can take
advantage of this facility, they need to apply for a debit
card which the bank then issues. To manage debit card
issuance and maintain an accurate record of the
transactions, banks use an application called a debit card
management system (DCMS).
The DCMS manages the entire lifecycle of ATM cards and
debit cards. The DCMS keeps track of all debit cards and
information on its users. It synchronises user information
4: Security Testing Repository
120
with core banking and keeps track of daily limits. It
maintains all transaction details made by a user on a day-to-
day basis and can ‘hotlist’ debit cards exceeding their
transaction limit. The data collected in the DCMS is used to
generate reports. Advanced systems have a built-in address
verification module thus automating the solution even
further and expediting the process of debit card issuance.
When the customer applies for a debit card, they are
required to submit residence and identity proof. All the
customer information is sent to the DCMS application and
reviewed by designated bank administrators.
A DCMS has different categories of users with different
privilege levels. Designated bank employees create new
customers and issue debit cards. The help desk users can
query the application and answer the queries they receive
on the status of a transaction or a debit card. Higher
privileged users manage and maintain the application.
Master users maintain the credentials, roles and privileges
of the application users. An attacker could belong to any of
these above categories.
DCMSs were traditionally thick-client applications. Over
time, enterprises have converted them to browser-based
applications. This has extended their reach – now the help
desk team can be dispersed across continents and time
zones to reduce cost and ensure 24×7 operations.
While many of the security threats related to debit cards are
associated with the processes used to issue and distribute
debit cards, the DCMS application itself is an interesting
piece in the puzzle. After all, this is where most of the
sensitive debit-card-related information is processed.
4: Security Testing Repository
121
Threat profile
An attacker hotlists a debit card without valid access
credentials.
An attacker increases/decreases the fund limit of a debit
card.
An attacker issues a debit card, bypassing user
verification.
An attacker steals debit card PIN from DCMS
database/core banking database.
An attacker adds/modifies/deletes all valid transactions
performed by the user with a specific debit card.
An attacker adds/modifies/deletes other user details in
the core banking server by exploiting vulnerabilities in
DCMS.
An attacker gains access to all user transactions by
exploiting vulnerabilities in the reports download
feature.
An attacker waives charges for interbank money
transfers made using debit card.
An attacker steals card information of customers without
authentication.
Test plan
An attacker hotlists a card without valid access
credentials:
o Check if privileged data can be accessed without
logging into the application.
o Check if a user can hotlist all debit cards using SQL
injection.
o Check if a user can hotlist another user’s debit card
using parameter manipulation.
4: Security Testing Repository
122
An attacker increases/decreases the fund limit of a debit
card:
o Check if a user can manipulate another card’s fund
limit using parameter manipulation.
o Check if privileged data can be accessed without
logging into the application.
An attacker issues a debit card, bypassing user
verification:
o Check if a user can bypass debit card verification
using parameter manipulation.
o Try to bypass client-side validation.
o Check if privileged data can be accessed without
logging into the application.
An attacker steals debit card PIN from DCMS
database/core banking database:
o Check if a user can manipulate database queries using
SQL injection to retrieve unauthorised data from the
database.
An attacker adds/modifies/deletes all valid transactions
performed by the user with a specific debit card:
o Check if a user can view/modify all valid transactions
using parameter manipulation.
An attacker adds/modifies/deletes other user details in
the core banking server by exploiting vulnerabilities in
DCMS:
o Check if a user can view/modify user details in
integrated application using parameter manipulation.
o Check if a user can add/modify/delete sensitive user
data using SQL injection.