This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)"

From OWASP
Jump to: navigation, search
(Identify other channels: Added auth/sso terms for searching)
(Added Andrew's changes.)
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
{{Template:OWASP Testing Guide v4}}
 
{{Template:OWASP Testing Guide v4}}
  
== Brief Description ==
+
== Summary==
  
 
Even if the primary authentication mechanisms do not include any vulnerabilities, it may be that vulnerabilities exist in alternative legitimate authentication user channels for the same user accounts. Tests should be undertaken to identify alternative channels and, subject to test scoping, identify vulnerabilities.
 
Even if the primary authentication mechanisms do not include any vulnerabilities, it may be that vulnerabilities exist in alternative legitimate authentication user channels for the same user accounts. Tests should be undertaken to identify alternative channels and, subject to test scoping, identify vulnerabilities.
  
== Issue ==
 
  
The alternative user interaction channels could be utilized to circumvent the primary channel, or expose information that can then be used to assist an attack against the primary channel. Some of these channels may themselves be separate web applications using different hostnames and/or paths. For example:
+
The alternative user interaction channels could be utilized to circumvent the primary channel, or expose information that can then be used to assist an attack against the primary channel. Some of these channels may themselves be separate web applications using different host names or paths. For example:
  
 
* Standard website
 
* Standard website
Line 13: Line 12:
 
* Accessibility optimized website
 
* Accessibility optimized website
 
* Alternative country and language websites
 
* Alternative country and language websites
* Parallel websites that utilise the same user accounts (e.g. another functionally different website of the same organization, a partner website to which user accounts are shared)
+
* Parallel websites that utilize the same user accounts (e.g. another website offering different functionally of the same organization, a partner website with which user accounts are shared)
 +
* Development, test, UAT and staging versions of the standard website
 +
 
  
 
But they could also be other types of application or business processes:
 
But they could also be other types of application or business processes:
Line 19: Line 20:
 
* Mobile device app
 
* Mobile device app
 
* Desktop application
 
* Desktop application
* Call centre operators
+
* Call center operators
 
* Interactive voice response or phone tree systems
 
* Interactive voice response or phone tree systems
  
Note that the focus of this test is on alternative channels, some authentication alternatives might appear as different content delivered via the same website and would almost certainly be in scope for testing. These are not discussed further here, and should have been identified during information gathering and primary authentication testing. For example:
+
 
 +
Note that the focus of this test is on alternative channels; some authentication alternatives might appear as different content delivered via the same website and would almost certainly be in scope for testing. These are not discussed further here, and should have been identified during information gathering and primary authentication testing. For example:
  
 
* Progressive enrichment and graceful degradation that change functionality
 
* Progressive enrichment and graceful degradation that change functionality
Line 29: Line 31:
 
* Site use without plugins such as for Flash and Java
 
* Site use without plugins such as for Flash and Java
  
Even if the scope of the test does not allow the alternative channels to be tested, their existence should be documented. These may undermine the degree of assurance in the authentication mechanisms and may be a pre-cursor to additional testing.
+
 
 +
Even if the scope of the test does not allow the alternative channels to be tested, their existence should be documented. These may undermine the degree of assurance in the authentication mechanisms and may be a precursor to additional testing.
 +
 
  
 
== Example ==
 
== Example ==
Line 45: Line 49:
 
  http://m.example.com/myaccount/
 
  http://m.example.com/myaccount/
  
== Testing Method ==
+
 
 +
==How to Test ==
  
 
=== Understand the primary mechanism ===
 
=== Understand the primary mechanism ===
  
Perform the all testing of the website's primary authentication functions. This should identify whether and how accounts are issued/created, passwords are recovered/reset, usernames are changed, passwords are changed. Additionally knowledge of any elevated privilege authentication and authentication protection measures should be known. These precursors are necessary to be able to compare with any alternative channels.
+
Fully test the website's primary authentication functions. This should identify how accounts are issued, created or changed and how passwords are recovered, reset, or changed. Additionally knowledge of any elevated privilege authentication and authentication protection measures should be known. These precursors are necessary to be able to compare with any alternative channels.
 +
 
  
 
=== Identify other channels ===
 
=== Identify other channels ===
Line 55: Line 61:
 
Other channels can be found by using the following methods:
 
Other channels can be found by using the following methods:
  
* Reading site content, especially the home page, contact us, help pages, support articles and FAQs, T&Cs, privacy notices, the robots.txt file and any sitemap.xml files
+
* Reading site content, especially the home page, contact us, help pages, support articles and FAQs, T&Cs, privacy notices, the robots.txt file and any sitemap.xml files.
* Searching HTTP proxy logs, recorded during previous information gathering and testing, for strings such as "mobile", "android", blackberry", "ipad", "iphone", "mobile app", "e-reader", "wireless", "auth", "sso", "single sign on" in URL paths and body content
+
* Searching HTTP proxy logs, recorded during previous information gathering and testing, for strings such as "mobile", "android", blackberry", "ipad", "iphone", "mobile app", "e-reader", "wireless", "auth", "sso", "single sign on" in URL paths and body content.
* Use search engines to find different websites from the same organization, or using the same domain name, that have similar home page content or which also have authentication mechanisms
+
* Use search engines to find different websites from the same organization, or using the same domain name, that have similar home page content or which also have authentication mechanisms.
 +
 
  
 
For each possible channel confirm whether user accounts are shared across these, or provide access to the same or similar functionality.
 
For each possible channel confirm whether user accounts are shared across these, or provide access to the same or similar functionality.
 +
  
 
=== Enumerate authentication functionality ===
 
=== Enumerate authentication functionality ===
Line 69: Line 77:
 
!width="150"|Mobile
 
!width="150"|Mobile
 
!width="150"|Call Center
 
!width="150"|Call Center
 +
!width="150"|Partner Website
 
|-
 
|-
 
| Register
 
| Register
 
| Yes
 
| Yes
 +
| -
 
| -
 
| -
 
|-
 
|-
Line 77: Line 87:
 
| Yes
 
| Yes
 
| Yes
 
| Yes
 +
| Yes (SSO)
 
|-
 
|-
 
| Log out
 
| Log out
 +
| -
 
| -
 
| -
 
| -
 
| -
Line 85: Line 97:
 
| Yes
 
| Yes
 
| Yes
 
| Yes
 +
| -
 
|-
 
|-
 
| -
 
| -
 
| Change password
 
| Change password
 +
| -
 
| -
 
| -
 
|-
 
|-
 
|}
 
|}
  
In this example, mobile has an extra function "change password" but does not offer "log out". A limited number of tasks are also possible by phoning the call centre. Call centers can be interesting, because their identity confirmation checks might be weaker than the websites', allowing this channel to be used to aid an attack against a user's account.
 
  
While enumerating these it is worth taking note of how session management is undertaken, in case there is overlap across any channels (e.g cookies scoped to the same parent domain name, concurrent sessions allowed across channels, but not on the same channel).
+
In this example, mobile has an extra function "change password" but does not offer "log out". A limited number of tasks are also possible by phoning the call center. Call centers can be interesting, because their identity confirmation checks might be weaker than the website's, allowing this channel to be used to aid an attack against a user's account.
  
=== Review and/or test ===
 
  
Alternative channels should be mentioned in the testing report, even if they are marked as "information only" and/or "out of scope".
+
While enumerating these it is worth taking note of how session management is undertaken, in case there is overlap across any channels (e.g. cookies scoped to the same parent domain name, concurrent sessions allowed across channels, but not on the same channel).
  
In some cases the test scope might include the alternative channel (e.g. because it is just another path on the target hostname), or may be added to the scope after discussion with the owners of all the channels. If testing is permitted and authorized, all the other Authentication tests in this guide should then be performed, and compared against the primary channel.
 
  
 +
=== Review and test ===
  
== Test Tools ==
+
Alternative channels should be mentioned in the testing report, even if they are marked as "information only" and/or "out of scope". In some cases the test scope might include the alternative channel (e.g. because it is just another path on the target host name), or may be added to the scope after discussion with the owners of all the channels. If testing is permitted and authorized, all the other authentication tests in this guide should then be performed, and compared against the primary channel.
  
None.
 
  
 
== Related Test Cases ==
 
== Related Test Cases ==
  
* [[Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|4.5.1 Testing for Credentials Transported over an Encrypted Channel  (OTG-AUTHN-001)]]
+
The test cases for all the other authentication tests should be utilized.
* [[Testing for default credentials (OWASP-AT-003)|4.5.2 Testing for default credentials (OTG-AUTHN-002)]]
 
* [[Testing for Weak lock out mechanism (OWASP-AT-004)|4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)]]
 
* [[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)]]
 
* [[Testing for Vulnerable Remember Password (OWASP-AT-006)|4.5.5 Test remember password functionality (OTG-AUTHN-005)]]
 
* [[Testing for Browser cache weakness (OWASP-AT-007)|4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)]]
 
* [[Testing for Weak password policy (OWASP-AT-008)|4.5.7 Testing for Weak password policy (OTG-AUTHN-007)]]
 
* [[Testing for Weak security question/answer (OTG-AUTHN-008)|4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)]]
 
* [[Testing for weak password change or reset functionalities (OWASP-AT-011)|4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)]]
 
 
 
== References == 
 
  
None.
 
  
 
== Remediation ==
 
== Remediation ==
  
Ensure a consist authentication policy is applied across all channels so that they are equally secure.
+
Ensure a consistent authentication policy is applied across all channels so that they are equally secure.

Latest revision as of 19:55, 1 August 2014

This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project

Summary

Even if the primary authentication mechanisms do not include any vulnerabilities, it may be that vulnerabilities exist in alternative legitimate authentication user channels for the same user accounts. Tests should be undertaken to identify alternative channels and, subject to test scoping, identify vulnerabilities.


The alternative user interaction channels could be utilized to circumvent the primary channel, or expose information that can then be used to assist an attack against the primary channel. Some of these channels may themselves be separate web applications using different host names or paths. For example:

  • Standard website
  • Mobile, or specific device, optimized website
  • Accessibility optimized website
  • Alternative country and language websites
  • Parallel websites that utilize the same user accounts (e.g. another website offering different functionally of the same organization, a partner website with which user accounts are shared)
  • Development, test, UAT and staging versions of the standard website


But they could also be other types of application or business processes:

  • Mobile device app
  • Desktop application
  • Call center operators
  • Interactive voice response or phone tree systems


Note that the focus of this test is on alternative channels; some authentication alternatives might appear as different content delivered via the same website and would almost certainly be in scope for testing. These are not discussed further here, and should have been identified during information gathering and primary authentication testing. For example:

  • Progressive enrichment and graceful degradation that change functionality
  • Site use without cookies
  • Site use without JavaScript
  • Site use without plugins such as for Flash and Java


Even if the scope of the test does not allow the alternative channels to be tested, their existence should be documented. These may undermine the degree of assurance in the authentication mechanisms and may be a precursor to additional testing.


Example

The primary website is:

http://www.example.com

and authentication functions always take place on pages using Transport Layer Security:

https://www.example.com/myaccount/

However, a separate mobile-optimized website exists that does not use Transport Layer Security at all, and has a weaker password recovery mechanism:

http://m.example.com/myaccount/


How to Test

Understand the primary mechanism

Fully test the website's primary authentication functions. This should identify how accounts are issued, created or changed and how passwords are recovered, reset, or changed. Additionally knowledge of any elevated privilege authentication and authentication protection measures should be known. These precursors are necessary to be able to compare with any alternative channels.


Identify other channels

Other channels can be found by using the following methods:

  • Reading site content, especially the home page, contact us, help pages, support articles and FAQs, T&Cs, privacy notices, the robots.txt file and any sitemap.xml files.
  • Searching HTTP proxy logs, recorded during previous information gathering and testing, for strings such as "mobile", "android", blackberry", "ipad", "iphone", "mobile app", "e-reader", "wireless", "auth", "sso", "single sign on" in URL paths and body content.
  • Use search engines to find different websites from the same organization, or using the same domain name, that have similar home page content or which also have authentication mechanisms.


For each possible channel confirm whether user accounts are shared across these, or provide access to the same or similar functionality.


Enumerate authentication functionality

For each alternative channel where user accounts or functionality are shared, identify if all the authentication functions of the primary channel are available, and if anything extra exists. It may be useful to create a grid like the one below:

Primary Mobile Call Center Partner Website
Register Yes - -
Log in Yes Yes Yes (SSO)
Log out - - -
Password reset Yes Yes -
- Change password - -


In this example, mobile has an extra function "change password" but does not offer "log out". A limited number of tasks are also possible by phoning the call center. Call centers can be interesting, because their identity confirmation checks might be weaker than the website's, allowing this channel to be used to aid an attack against a user's account.


While enumerating these it is worth taking note of how session management is undertaken, in case there is overlap across any channels (e.g. cookies scoped to the same parent domain name, concurrent sessions allowed across channels, but not on the same channel).


Review and test

Alternative channels should be mentioned in the testing report, even if they are marked as "information only" and/or "out of scope". In some cases the test scope might include the alternative channel (e.g. because it is just another path on the target host name), or may be added to the scope after discussion with the owners of all the channels. If testing is permitted and authorized, all the other authentication tests in this guide should then be performed, and compared against the primary channel.


Related Test Cases

The test cases for all the other authentication tests should be utilized.


Remediation

Ensure a consistent authentication policy is applied across all channels so that they are equally secure.