Last revision (mm/dd/yy): 07/9/2015

Introduction

Some applications use a second factor to check whether an authorized user is performing sensitive operations. A common example is wire transfer authorization, typically used in internet or mobile banking applications. For the purpose of this document we will call that process: “transaction authorization”. However, usage scenarios are not only limited to financial systems. For example: an e mail with a secret code or a link with some kind of token to unlock user account is also a special case of transaction authorization. User authorizes operation of account unlocking by using second factor (a unique code sent to his email address).

Transaction authorization is currently performed by various methods. The following are common examples:

• cards with transaction authentication numbers (TAN),
• time based OTP tokens, such as SecureID,
• OTP sent by SMS, provided by phone or sent to email address,
• digital signature using a smart card,
• challenge-response tokens (including “disconnected card readers” or solutions which scan transaction data from computer screen).

Some of these can be implemented on a physical device or in a mobile application.

Transaction authorization is implemented in modern financial systems in order to protect against unauthorized wire transfers as a result of attacks using malware, phishing, password or session hijacking, CSRF, XSS, etc. Unfortunately, as with any piece of code, such protection can be improperly implemented and as a result it might be possible to bypass this safeguard. Purpose of this cheat sheet is to provide guidelines on how to properly implement transaction authorization to protect it from bypassing.

1.0 Functional Guidelines

1.1. Transaction authorization method has to allow a user to verify significant transaction data

Users must know what’s being authorized. Based on this, an authorization method must permit a user to verify the data which are significant to given transaction. For example, in case of a wire transfer: target account and amount.

Any method which prevents verifying transaction data on an external device (e.g. a time-based OTP token which shows only generated OTP without any transaction data) doesn’t protect users from malware attacks and shouldn’t be used in applications where such attacks are considered probable.

Decision about which transaction data are significant should be chosen based on: real risk, technical capabilities of chosen authorization method and positive user experience. E.g. when an SMS message is used to send significant transaction data, it is possible to send target account, amount and type of transfer, but for unconnected CAP reader it would be inconvenient for user to enter all of these data. In such cases, entering only the most significant transaction data (e.g. partial target account number and amount) should be sufficient.

1.2. Change of authorization credentials should be authorized using current authorization credentials

When a user is allowed to change authorization credentials by using application interface, then such an operation should be authorized by using current authorization credentials. For example: when a user changes a phone number for SMS codes, then this operation should be authorized using SMS code sent to the current phone number.

1.3. Change of authorization method should be authorized using current authorization method

Some applications allow multiple methods of transaction authorization and a user is permitted to change currently used authorization method, using an application interface. In such cases, the user should authorize this change using current authorization method. Otherwise, malware may change the authorization method to one which is the easiest to attack.

1.4. Different methods should be used for user authentication and transaction authorization or user should be able to easily distinguish between these two operations

When an application requires exactly the same actions for users to authenticate and to authorize, then this could be abused by malware to trick user to authorize fraud operation. Let’s consider the following example:

• For authentication, a user must provide login, password and token response for numerical challenge presented on a login page.
• For transaction authorization – one has to provide token response based on challenge which is a random number presented on a transaction confirmation page and some digits from the target account number.
• Malware after first step (authentication to the application) may present user false error message and trick him into trying authentication procedure once again. This time, a challenge presented on a false login page by malware would be a challenge value collected from the transaction confirmation page, so the user unwittingly authorizes fraud transaction. Such an attack scenario is used widely in malware attacks against electronic banking.

In the abovementioned case, the same method (a challenge-response token) was used to authenticate the user and to authorize the transaction. Malware abused this fact to extract transaction authorization credentials without the user’s knowledge. Of course social engineering methods can be used despite utilized authentication and operation authorization methods but the application shouldn’t simplify such attack scenarios.

Generally – as long as the user is clearly presented with details of whatever he is authorizing, it is much harder to trick him into authorizing unwanted transaction.

1.5. Each operation should be authorized using unique authorization credentials

Some applications are asking for operation authorization credentials only once (e.g. static password, code sent through SMS, token response) and then a user is able to authorize any transaction during the whole user’s session or he has to reuse these credentials each time when he wants to authorize any operation. Such behavior is not sufficient to prevent malware attacks because malware will sniff such credentials and use them to authorize any transaction without the user’s knowledge.

1.6. Authorization component should present authorized operation data clearly

When a user authorizes an operation then he needs to know what is being “signed”. Authorized operation data should be presented clearly in an authorization component and not only in the application as due to malware threat the user’s computer should not be considered trusted. Moreover, the decision regarding whether operation data should be displayed or not cannot be user-dependent. E.g. it is not recommended to require additional user’s step/input to see authorized transaction data (e.g. in mobile authorization apps, a user shouldn’t be forced to press any key in order to see transaction details). Significant transaction data (see paragraph 1.1) should be presented always, as an inherent part of the transaction authorization process and user experience should be built in such way to encourage users to verify these data.

If a transaction authentication process requires a user to enter transaction data into an external device, then such a user should be prompted for providing specific value (e.g. a target account number). Methods which require only entering a value without the prompt could be easily abused by malware as in the example described in paragraph 1.4. For more detailed discussion of input overloading problems, see this paper.

2.0 Non-functional guidelines

2.1. Authorization should be performed and enforced server-side

As for all other security controls – transaction authorization should be enforced server-side. It should not be possible to change or influence authorization result by changing or removing any data which flows from a client to a server, e.g. by:

• removing parameters which carry authorization data
• adding parameters which will disable authorization check
• causing an error

To achieve this, general security programming best practices should be applied, such as:

• default deny
• avoiding debugging functionality in production code

2.2. Authorization method should be enforced server side

When multiple transaction authorization methods are available to the user, the server should enforce use of current (chosen by the user in the application settings) authorization method. It should be impossible to change an authorization method by manipulating with parameters passed from the client. Otherwise, malware can downgrade an authorization method to less or even least secure.

This is especially important when an application is developed to add a new, more secure authorization method. It is not very rare, that a new authorization method is built on top of an old code and as a result, when a client is sending parameters characteristic to the old method, the transaction may be authorized, despite the fact that the user has already switched to a new method.

2.3. Transaction verification data should be generated server-side

For transaction authorization methods, when significant transaction data are transmitted programmatically to an authorization component, extra care should be put into forbidding client modifications on these transaction data. Significant transaction data to be verified by the user, should be generated on a server, kept server side, and passed to an authorization component without any possibility of tampering by the client.

A common anti pattern is to collect significant transaction data client-side and pass it to the server. In such cases, malware can manipulate these data and as a result – show faked transaction data in an authorization component.

2.4. Application should prevent authorization credentials brute-forcing

When transaction authorization credentials are sent to the server for verification, an application has to prevent brute-forcing. E.g. Transaction authorization process should restart after the server-side defined unsuccessful attempts or other anti brute-forcing techniques must be used (see OWASP Authentication Cheat Sheet).

2.5. Application should control which transaction state transitions are allowed

Transaction authorization usually is performed in multiple steps. E.g.:

1. user enters transaction data
2. user verifies entered data and requests authorization
3. application initializes an authorization mechanism (or sends challenge)
4. user enters OTP (authorization credentials)
5. an application validates authorization and executes a transaction

An application should process such business logic flow in sequential step order, and prevent processing steps out of order and especially skipping any steps (see OWASP ASVS requirement 15.8). This should protect against attack techniques such as:

• overwriting transaction data before user will enter OTP
• skipping authorization

2.6. Transaction data should be protected against modification after their entering

The transaction authorization process should protect against attack scenarios that modify transaction data after initial entry by the user. For example, bad implementation of a transaction authorization process may allow the following attacks (for reference, see steps of transaction authorization described in paragraph 2.5):

• Replying step 1 (sending transaction data) in the background and overwriting transaction details with fraudulent transaction, before the user enters authorization credentials.
• Adding parameters with transaction data to a HTTP request which authorizes the transaction. In such a case, poor implementation will authorize the initial transaction and then execute a fraudulent transaction (specific example of Time of Check to Time of Use vulnerability).

Protection against modification could be implemented using various techniques dependent of a used framework, but the following ideas should be considered:

• Any modification of transaction data should trigger invalidation of any previous authorization data. E.g. Generated OTP or challenge is invalidated.
• Any modification of transaction data should trigger reset of an authorization process.
• Any attempts to modify transaction data after initial entry by the user is a symptom of tinkering with an application and should be logged and carefully investigated.

2.7. When a transaction is executed, the system should check whether it was authorized

The result of the transaction entry and the authorization process described in paragraph 2.5 is the transaction execution. Just before the transaction is executed there should be a final control gate which verifies whether the transaction was properly authorized by the user. Such control, tied to execution, should prevent attacks such as:

• Time of Check to Time of Use (TOCTOU) – example in paragraph 2.6
• Skipping authorization check in the transaction entry process (see. paragraph 2.5)

2.8. Authorization data should be valid only by limited period of time

In some malware attacks scenarios, authorization data entered by the user is passed to C&C and then used from an attacker-controlled machine. Such a process is often performed manually by an attacker. To make such attacks difficult, the server should allow authorizing the transaction only in a limited time window between generating of challenge or OTP and the transaction authorization. Additionally, such safeguard will also benefit to prevention of resource exhaustion attacks. The time window should be carefully selected to not disrupt normal users’ behavior.

2.9. Authorization data should be unique for every operation

To prevent all sorts of replay attacks, authorized transaction data should be unique for every operation. It could be achieved using different methods depending on the applied transaction authorization mechanism. For example: using a timestamp, a sequence number or a random value in signed transaction data or as a part of a challenge.

Remarks

Some other issues that should be taken into consideration while implementing transaction authorization, but they are beyond the scope of this cheat sheet:

• Authorization of all transactions or only some of them. Each application is different and an application owner should decide if all transactions should be authorized or only some of them, considering risk analysis, risk exposition of given application, and other safeguards implemented in an application.
• Use some kind of cryptographic operations to “sign” the transaction, to ensure integrity and non-repudiation.
• Device enrolment or “pairing” of an external authorization device (or a mobile application) with the user account.
• User training. E.g.: For transaction authorization methods, when a user types-in significant transaction data to an authorization component (e.g. an external dedicated device or a mobile application), users should be trained to rewrite transaction data from trusted source and not from a computer screen.
• There are some anti-malware solutions that protect against malware threats but such solutions do not guarantee 100% effectiveness and should be used only as an additional layer of protection.

Authors and Primary Editors

Wojciech Dworakowski, SecuRing @

Contributors

I would like to thank the following persons who helped by reviewing and providing valuable feedback to this work:

• Steven Wierckx, Toreon
• Adam Zachara, SecuRing
• Adam Lange

References and future reading

References and future reading:

1. Wojciech Dworakowski; E-banking transaction authorization - possible vulnerabilities, security verification and best practices for implementation. Presentation from AppSec EU 2015: [1]
2. Saar Drimer, Steven J. Murdoch, and Ross Anderson; Optimised to Fail: Card Readers for Online Banking, [2]
3. Jakub Kałużny, Mateusz Olejarka; Script-based Malware Detection in Online Banking Security Overview; [3]
4. List of websites and whether or not they support 2FA. [4]
5. Laerte Peotta, Marcelo D. Holtz, Bernardo M. David, Flavio G. Deus, Rafael Timóteo de Sousa Jr.; A Formal Classification Of Internet Banking Attacks and Vulnerabilities; [5]
6. Marco Morana, Tony Ucedavelez; Threat Modeling of Banking Malware-Based Attacks; [6]
7. OWASP Anti-Malware - Knowledge Base; [7]
8. OWASP Anti-Malware Project - Awareness Program; [8]

Other Cheatsheets