Transaction Authorization Cheat Sheet - Revision history

Dominique RIGHETTO: Point to the official site

2019-07-15T14:25:39Z

Point to the official site

Thunder-Son: Migration to GitHub

2019-02-14T14:46:41Z

Migration to GitHub

Show changes

Jmanico: /* Other Cheatsheets */

2017-09-11T06:11:56Z

‎Other Cheatsheets

Wojciech Dworakowski: Major revision after contributors comments.

2015-12-23T10:22:48Z

Major revision after contributors comments.

Show changes

Jmanico: moving nav to bottom for mobile friendliness

2015-07-18T23:14:37Z

moving nav to bottom for mobile friendliness

Wojciech Dworakowski: TOC numbering cleanup

2015-07-09T08:16:57Z

TOC numbering cleanup

Wojciech Dworakowski at 08:04, 9 July 2015

2015-07-09T08:04:14Z

Wojciech Dworakowski at 14:59, 8 July 2015

2015-07-08T14:59:28Z

Jmanico: /* Authors and Primary Editors */

2015-07-07T00:29:35Z

‎Authors and Primary Editors

Jmanico: /* Authors and Primary Editors */

2015-07-07T00:29:19Z

‎Authors and Primary Editors

← Older revision		Revision as of 14:25, 15 July 2019
Line 4:		Line 4:
	The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!		The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

−	Please visit [https://~~github~~.~~com/OWASP/CheatSheetSeries/blob/master~~/cheatsheets/Transaction_Authorization_Cheat_Sheet.md Transaction Authorization Cheat Sheet] to see the latest version of the cheat sheet.	+	Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html Transaction Authorization Cheat Sheet] to see the latest version of the cheat sheet.

@@ Line 185: / Line 185: @@
 # Arjan Blom , Gerhard de Koning Gans , Erik Poll , Joeri de Ruiter , and Roel Verdult; Designed to Fail: A USB-Connected Reader for Online Banking [http://www.cs.ru.nl/~rverdult/Designed_to_Fail_A_USB-Connected_Reader_for_Online_Banking-NORDSEC_2012.pdf]
-== Other Cheatsheets ==
+= Other Cheatsheets =
 {{Cheatsheet_Navigation_Body}}

@@ Line 160: / Line 160: @@
 # OWASP Anti-Malware - Knowledge Base; [https://www.owasp.org/index.php/OWASP_Anti-Malware_-_Knowledge_Base]
 # OWASP Anti-Malware Project - Awareness Program; [https://www.owasp.org/index.php/OWASP_Anti-Malware_Project_-_Awareness_Program]
 == Other Cheatsheets ==

@@ Line 5: / Line 5: @@
 | valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 = 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).

@@ Line 33: / Line 33: @@
 ==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 and to a new number.
+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==
@@ Line 145: / Line 145: @@
 I would like to thank the following persons who helped by reviewing and providing valuable feedback to this work:<br>
-* Steven Wierckx, Toreon<br>
+* Steven Wierckx, Toreon
 = References and future reading =

@@ Line 8: / Line 8: @@
   __TOC__{{TOC hidden}}
-Some applications use second factor to check whether sensitive operations are being performed by an authorized user. Common example is wire transfer authorization, typically used in internet or mobile banking applications. For the purpose of this document we will call such 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).
+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:
@@ Line 20: / Line 20: @@
 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 and other. 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.
+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 =
@@ Line 29: / Line 29: @@
 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 (which is target account number) should be sufficient.
+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 [https://en.wikipedia.org/wiki/Chip_Authentication_Program 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==
@@ Line 45: / Line 45: @@
 * 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.
+* 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 [http://securityintelligence.com/back-basics-malware-authors-downgrade-tactics-stay-radar/#.VX_qI_krLDc 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.
+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 [http://securityintelligence.com/tatanga-attack-exposes-chiptan-weaknesses/#.VZAy9PkrLDc 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.
@@ Line 59: / Line 59: @@
 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 [1].
+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 [http://www.cl.cam.ac.uk/~sjm217/papers/fc09optimised.pdf this paper].
 = 2.0 Non-functional guidelines =
@@ Line 68: / Line 68: @@
 * removing parameters which carry authorization data
 * adding parameters which will disable authorization check
-* inducting an error
+* causing an error
 To achieve this, general security programming best practices should be applied, such as:
@@ Line 87: / Line 87: @@
 ==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).
+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 [https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Prevent_Brute-Force_Attacks OWASP Authentication Cheat Sheet]).
 ==2.5.	Application should control which transaction state transitions are allowed==
@@ Line 107: / Line 107: @@
 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).
+* 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 [https://cwe.mitre.org/data/definitions/367.html 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.
@@ Line 135: / Line 135: @@
 * 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.
+* There are some anti-malware solutions that protect against malware threats but such solutions [http://www.securing.pl/en/script-based-malware-detection-in-online-banking-security-overview/index.html do not guarantee 100% effectiveness] and should be used only as an additional layer of protection.
 <br/>
 = Authors and Primary Editors  =
-[https://www.owasp.org/index.php/User:Wojciech_Dworakowski Wojciech Dworakowski] [mailto:wojciech.dworakowski@owasp.org @]<br/>
+[https://www.owasp.org/index.php/User:Wojciech_Dworakowski Wojciech Dworakowski], SecuRing [mailto:wojciech.dworakowski@owasp.org @]<br/>
 | valign="top"  style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" |

← Older revision		Revision as of 00:29, 7 July 2015
Line 141:		Line 141:

	[https://www.owasp.org/index.php/User:Wojciech_Dworakowski Wojciech Dworakowski] [mailto:wojciech.dworakowski@owasp.org @]<br/>		[https://www.owasp.org/index.php/User:Wojciech_Dworakowski Wojciech Dworakowski] [mailto:wojciech.dworakowski@owasp.org @]<br/>
−	~~Wojciech.Dworakowski@owasp.org~~

	\| valign="top" style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" \|		\| valign="top" style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" \|

← Older revision		Revision as of 00:29, 7 July 2015
Line 140:		Line 140:
	= Authors and Primary Editors =		= Authors and Primary Editors =

		+	[https://www.owasp.org/index.php/User:Wojciech_Dworakowski Wojciech Dworakowski] [mailto:wojciech.dworakowski@owasp.org @]<br/>
	Wojciech.Dworakowski@owasp.org		Wojciech.Dworakowski@owasp.org