Mutual funds management – Security Testing Handbook for Banking Applications

4: Security Testing Repository
123
An attacker gains access to all user transactions by
exploiting vulnerabilities in the reports download
feature:
o Check if a user can view sensitive reports using
parameter manipulation.
o Check if a user can view reports in browser
cache/history.
An attacker waives charges for interbank money
transfers made using debit card:
o Check if a user can bypass charges using parameter
manipulation.
o Check if validations performed at the browser can be
bypassed.
An attacker steals the card information of customers
without authentication:
o Check if the password/sensitive data is transmitted in
plain text on the wire.
o Check if a user can obtain sensitive card information
using SQL injection.
o Check if a user can steal another user session using
XSS/CSRF attacks.
o Check if customer card information is visible in
browser cache/history.
Mutual funds management
Banks use a mutual funds management (MFM) application
to manage the mutual funds portfolio of its customers. Both
retail and corporate clients of the bank may invest in mutual
funds through the bank. The bank provides value-added
services like advising clients on their mutual funds
4: Security Testing Repository
124
investments and helping them make better investment
decisions.
The MFM application is used by internal bank employees
as well as end clients. Customers can see their portfolio and
its performance via the MFM application. The bank’s
specialists can advise the customers on the fund’s
performance also via the MFM.
In many countries, customers buy mutual funds from a
bank’s representative – there is a lot of face-to-face
interaction before the client places orders to buy mutual
funds. In such cases, the MFM application serves as a
central repository to track the workflow. The bank’s
representative enters buy/sell details on behalf of the
customer into the MFM application.
The MFM application also plays a key role when a
customer is first registered to buy/sell mutual funds. When
a customer first registers for mutual funds, the operations
team verifies all customer details and sends a field
executive to collect all relevant documents from the
customer. These documents are scanned or manually
entered into an application by the front desk. The
operations team re-verifies this deal and forwards it to the
deal processing team who then finalises the deal. As is the
case with most other financial transactions, it is near
impossible to keep accurate track of the data without some
automation. All this data is uploaded into the MFM
application along with the details of the mutual fund that
the customer bought. The application thus retains a lot of
sensitive data about clients and their mutual fund portfolios.
4: Security Testing Repository
125
Threat profile
An attacker sells a mutual fund instead of buying it on
behalf of other users.
An attacker scans, re-verifies and finalises a mutual fund
deal themself.
An attacker deletes deals made by other users.
An attacker views the portfolio of another user.
An attacker edits the workflow of the mutual fund
buying process.
An attacker steals collection data report or account
statement of other users.
An attacker modifies customer appointment details of
other users.
Test plan
An attacker sells a mutual fund instead of buying it on
behalf of other users:
o Check if a user can manipulate activities performed
on a mutual fund using parameter manipulation.
o Check if a user can sell all mutual funds of another
user using SQL injection.
An attacker scans, re-verifies and finalises a mutual fund
deal themself:
o Check if a user can perform privilege escalation using
parameter manipulation.
o Check if a user can gain complete access to another
user’s profile using SQL injection or by hijacking that
user’s session.
o Check if a user can be tricked into verifying a deal
using a CSRF attack.
4: Security Testing Repository
126
An attacker deletes deals made by other users:
o Check if a user can exploit an SQL injection flaw and
delete other user’s deals.
o Check if a user can manipulate requests and gain
unauthorised access using parameter manipulation.
o Check if a user can be tricked into deleting their own
deals by using a CSRF attack or an XSS attack.
An attacker views the portfolio of another user:
o Check if a user can view portfolio of other users by
manipulating requests using parameter manipulation.
o Check if privileged data can be accessed without
logging into the application.
o Check if the user’s portfolio is visible in browser
cache/history.
An attacker edits the workflow of the mutual fund
buying process:
o Check if a user can gain access to the process
workflow and edit it using parameter manipulation.
An attacker steals collection data report or account
statement of other users:
o Check if a user can view reports of other users by
manipulating requests using parameter manipulation.
o Check if privileged data can be accessed without
logging into the application.
o Check if the user’s collection data/reports are visible
in browser cache/history or stored offline in any other
hidden folder.
An attacker modifies customer appointment details of
other users:
o Check if a user can change appointment details of
another user using parameter manipulation.