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)"
m (→Enumerate authentication functionality: Fix table) |
(→Issue: Added dev, test, etc sites) |
||
Line 14: | Line 14: | ||
* 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 utilise the same user accounts (e.g. another functionally different website of the same organization, a partner website to 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: |
Revision as of 12:00, 15 October 2013
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
Brief Description
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:
- Standard website
- Mobile, or specific device, optimized website
- Accessibility optimized website
- 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)
- 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 centre 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 pre-cursor 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/
Testing Method
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.
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 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. This example also illustrates how a user is provided access through to a partner's website.
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/or 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 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.
Test Tools
None.
Related Test Cases
- 4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)
- 4.5.2 Testing for default credentials (OTG-AUTHN-002)
- 4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)
- 4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)
- 4.5.5 Test remember password functionality (OTG-AUTHN-005)
- 4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)
- 4.5.7 Testing for Weak password policy (OTG-AUTHN-007)
- 4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)
- 4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)
References
None.
Remediation
Ensure a consist authentication policy is applied across all channels so that they are equally secure.