Loan management application – Security Testing Handbook for Banking Applications

4: Security Testing Repository
127
Loan management application
Banks use a loan management (LM) application to keep
track of the loans issued and the status of repayments.
To apply for a loan, a customer approaches a branch and
provides the necessary information. The bank analyses
whether the person is creditworthy and is in a position to
repay the loan. It then calculates the interest on the loan and
advises the customer about the repayment options. Once the
customer decides on a particular type of loan, the branch
employee initiates a case in the LM application, filling in
all the customer information, loan amount and other
relevant loan-related details. The case is then authorised by
the branch manager, at which time the customer’s loan is
approved. The person is not required to have an account in
the bank before they apply for a loan.
The loan management application also tracks whether the
loan repayments are being made on time. The customer can
make repayments by depositing money at the branch before
repayment date. Alternatively, the customer can choose to
opt for direct debit where the amount of the loan instalment
will automatically be withdrawn from their bank account.
Some customers choose to issue post-dated cheques for
long periods of time, at the time of taking the loan. This is
done especially if they are certain that they will have the
equated monthly instalment (EMI) amount with them on
their repayment date every month for say, the next six
months.
Once the loan is taken and the customer chooses to repay
using post-dated cheques, they submit the relevant
documents and post-dated cheques against the loan. The
loan department will scan the loan documents, cheques and
upload the same to a cheque management (CM) application.
4: Security Testing Repository
128
Key details that are captured include company branch,
product, loan account number, city, bank, bank branch,
cheque serial number, cheque date, presentation date,
cheque amount, bin number, and multiple loan links. The
LM application inventories all these details and presents
cheques on the due date.
The cheque may be bounced, re-bounced or re-presented.
All these details are captured by the LM application and fed
to the CM application and synchronised with the data used
by core banking.
Once the money is received by the bank, the branch
employee initiates a case in the LM application, completing
all the necessary information about the customer and the
amount of money repaid. The case is then authorised by the
branch manager. Where the customer has an account in the
same bank, the data entered into the LM application is
synchronised with their account-related data available on
the core banking server.
It also manages cases where a customer changes their loan
type from a fixed to a floating loan or increases the loan
repayment tenure.
There are two user categories in this application. Normal
branch users initiate and manage the cases whereas higher
privileged users like the branch manager authorise or reject
the initiated cases. The attacker could have the privileges of
either of these two users.
Threat profile
An attacker increases/decreases the loan tenure of a
customer.
4: Security Testing Repository
129
An attacker changes the loan type from a fixed loan to a
floating loan.
An attacker increases the monthly instalments or interest
rates of a loan.
An attacker adds a fake loan record for a bank customer
and sets repayment type to direct debit.
An attacker approves a loan themself without it being
authorised by a manager.
An attacker who deals only with one type of loan
approves another type of loan.
An attacker changes the loan repayment type from
quarterly to monthly.
An attacker updates the status of all unpaid instalments
to ‘paid’.
An attacker waives the charge for a late EMI payment.
An attacker changes the EMI collection date of a
customer.
An attacker causes a direct debit of a monthly EMI from
another customer’s account.
An attacker issues a loan without document verification.
An attacker issues a loan without checking the
customer’s credit history.
An attacker views all loan-related and personal data of a
customer.
An attacker changes details of post-dated cheques issued
by a customer.
Test plan
An attacker increases/decreases the loan tenure of a
customer:
4: Security Testing Repository
130
o Check if a user can increase their loan tenure by
changing a sent request using parameter
manipulation.
An attacker changes the loan type from a fixed loan to a
floating loan:
o Check if a user can change their loan type using
parameter manipulation.
An attacker increases the monthly instalments or interest
rates of a loan:
o Check if a user can increase their monthly instalments
using parameter manipulation.
o Check if a user can change their interest rates using
parameter manipulation.
o Check if a user can change interest rates using SQL
injection.
An attacker adds a fake loan record for a bank customer
and sets repayment type to direct debit:
o Check if a user can add a new record using parameter
manipulation.
o Check if privileged data can be accessed without
logging into the application.
An attacker approves a loan themself without it being
authorised by a manager:
o Check if a user can approve a loan themself using
parameter manipulation.
o Check if a user can escalate their privilege and
approve loans of all customers.
An attacker who deals only with one type of loan
approves another type of loan:
o Check if a user can escalate their privileges and
approve other types of loans.
4: Security Testing Repository
131
o Check if a user can approve other types of loans using
parameter manipulation.
o Check if a user can approve other types of loans using
SQL injection.
o Check if a user can be tricked into approving a loan
using a CSRF attack.
An attacker changes the loan repayment type from
quarterly to monthly:
o Check if a user can change their loan type to monthly
using parameter manipulation.
An attacker updates the status of all unpaid instalments
to ‘paid’:
o Check if a user can change all unpaid instalments to
‘paid’ using parameter manipulation.
An attacker waives the charge for a late EMI payment:
o Check if validations performed at the browser can be
bypassed.
o Check if a user can waive EMI charges using
parameter manipulation.
An attacker changes the EMI collection date of a
customer:
o Check if a user can change their EMI payment date
using parameter manipulation.
An attacker causes a direct debit of a monthly EMI from
another customer’s account:
o Check if a user can cause another user’s account to be
debited using parameter manipulation.
o Check if a user can be tricked into adding a periodic
debit instruction using a CSRF attack.
o Check if validations performed at the browser can be
bypassed.