Weak authorisations – Security Testing Handbook for Banking Applications

2: Basic Tests and Techniques
Fingerprinting the web/application server also helps in
further attacks. Sometimes the application itself is securely
developed, but the underlying server is a vulnerable
version. In these cases one could compromise the web
server itself. Another threat comes from the vulnerable
sample or default applications on the server.
Ensure that permissions are properly set on all the
directories on the web and application server. Disable
directory listings and traversals completely. Ensure that no
default files or applications that reveal application platform
information remain in any directory that can be publicly
accessed. Ensure that the servers are all updated with the
latest patches.
Weak authorisations
Consider an application with different user levels: a bank
teller, a supervisor and a branch manager. A teller with
malicious intent would love to be able to perform a few
actions that are allowed only to the supervisor or branch
manager and get away with it. Suppose every transaction
the teller enters has to be approved by the supervisor. What
if the teller is able to approve a fraudulent transaction on
the supervisor’s behalf? That is something they will surely
want to do. Here’s what the teller may try.
The teller logs in to their account and accesses the page
where they can view the transactions entered. They
configure a web proxy editor to intercept requests. (Web
proxy editors will be discussed in detail in the next
chapter.) They click on a transaction to view the details and
2: Basic Tests and Techniques
intercept the request. In the proxy editor, they change the
value of the parameter ‘Action’ from ‘View’ to ‘Approve’
and replace their user ID with the supervisor’s ID. If the
application only checks for a valid session ID and does not
check to see whether the user ID correctly maps to the
session ID and that the teller has permissions to approve,
the approval will go through. This is an example of a
variable manipulation attack.
This kind of attack can be used to view/modify/delete
other’s data, perform unauthorised actions and escalate
ones privileges.
Why was the above discussed attack by a teller approving a
fraudulent transaction possible? Wasn’t the application
enforcing the business rule that the teller cannot approve
their own transactions? In most cases, applications do try to
enforce the rules but fail to do so in a foolproof way. The
application may just check that the session ID is valid and
assume that the rest of the details in the request are correct.
To prevent these attacks, the application should map all
important user details to the session ID initially when the
user logs in and store it in a session object. It should then
verify all variables in each request against the session ID.
Whenever the application notices a request has been
tampered with, it should terminate the session and logout
the user.