Interactive voice response system – Security Testing Handbook for Banking Applications

4: Security Testing Repository
178
o Check if a user can manipulate requests and modify
credit/debit card details of a customer using
parameter manipulation.
o Check if a user can gain unauthorised access to
privileged functions by escalating privileges using
SQL injection.
An attacker creates new users and assign roles to them:
o Check if a user can create new users by manipulating
requests using parameter manipulation.
Interactive voice response system
Interactive voice response systems (IVRs) are used by
banks as a customer service interface. Customers can use
the IVR to get answers to frequently asked questions – this
reduces the number of support personnel the bank requires
to answer customer queries.
Most IVRs answer common questions a client might have:
the balance in an account
the status of a transaction
the status of a cheque
finding the nearest ATM or branch.
More advanced IVRs also let customers give instructions as
part of telephone banking:
instructions for fund transfer
instructions to schedule transfers
instructions to stop cheques
instructions to change the PIN
instructions to change the address.
4: Security Testing Repository
179
The IVR in turn interfaces with back-end systems to get
answers to the queries and initiate the transactions.
Customers with active accounts in the bank can use the IVR
to make queries or perform transactions. It is primarily
useful for those customers who do not have or are
unfamiliar with an Internet connection. It is also useful for
customers who do not have the time to go to a branch.
The IVR application contains three back-end components.
Their functions are:
Manage valid user accounts who wish to use phone
banking.
PIN management when a customer enters their
credit/debit card details.
Web user interface to complete the transaction after
customer verification.
Customer care administrators control these components.
The customer has no direct login to these back-end
components. The attacker could be a customer care
administrator who has access to any of the components of
the application. The attacker could also be a customer who
tries to bypass the menus provided by the IVR to the
customer.
Threat profile
An attacker gains unauthorised access to another agent’s
screen.
An attacker gains complete access to customer credit
card data.
An attacker deletes customer debit/credit card PINs
without an audit trail.
4: Security Testing Repository
180
An attacker performs a customer transaction even
without a phone call being made.
An attacker bypasses predefined menus which don’t map
to a specific telephone code.
An attacker forces the system to misbehave by
forwarding incorrect calls to agents.
An attacker performs a transaction with a fake credit
card.
An attacker bypasses application restrictions to perform
other customer transactions without valid authorisation.
Test plan
An attacker gains unauthorised access to another agent’s
screen:
o Check if a user can gain unauthorised access to the
database by using SQL injection.
o Check if a user can view another user’s screen using
parameter manipulation.
o Check if a user can obtain physical access to another
user machine.
An attacker gains complete access to customer credit
card data:
o Check if a user can gain unauthorised access to the
database by using SQL injection.
o Check if a user can obtain credit card information
using parameter manipulation.
An attacker deletes customer debit/credit card PINs
without an audit trail:
o Check if a user can gain unauthorised access to the
database by using SQL injection.
4: Security Testing Repository
181
o Check if a user can delete user credit/debit card PINs
using parameter manipulation.
o Check if a user can gain access to the folders where
the audit trail is stored.
An attacker performs a customer transaction even
without a phone call being made:
o Check if a user can simulate valid phone traffic.
o Check if a user can create a fake transaction by
replaying a valid request.
An attacker bypasses predefined menus which don’t map
to a specific telephone code:
o Check if an attacker can enter an invalid combination
of codes which cause hidden menus to be invoked by
the application.
An attacker forces the system to misbehave by
forwarding incorrect calls to agents:
o Check if a user can gain access to the middleware
which stores the mapping of agents and their skill
sets.
o Check if a user can gain physical access to the
middleware.
An attacker performs a transaction with a fake credit
card:
o Check if a user can gain access to the middleware
which stores credit card information.
o Check if a user can trick the agent into believing that
a valid credit card number was entered.
An attacker bypasses application restrictions to perform
other customer transactions without valid authorisation:
o Check if a user can replay a previous valid request
using parameter manipulation.