HoT-TAI-0009: Weak or no authentication
Summary:
CWE-287 Improper Authentication: When an actor claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct. The following CWEs are children of CWE-287:
- CWE-261 Weak cryptography for passwords
- CWE-262 Not using password aging
- CWE-263 Password aging with long expiration
- CWE-288 Authentication bypass using an alternate path or channel
- CWE-289 Authentication bypass by alternate name
- CWE-290 Authentication bypass by spoofing
- CWE-294 Authentication bypass by capture-replay
- CWE-301 Reflection attack in an authentication protocol
- CWE-302 Authentication bypass by assumed-immutable data
- CWE-303 Incorrect implementation of authentication algorithm
- CWE-304 Missing critical step in authentication
- CWE-305 Authentication bypass by primary weakness
- CWE-306 Missing authentication for critical function
- CWE-307 Improper restriction of excessive authentication attempts
- CWE-308 Use of single-factor authentication
- CWE-309 Use of password system for primary authentication
- CWE-384 Session fixation
- CWE-521 Weak password requirements
- CWE-522 Insufficiently protected credentials
- CWE-593 Authentication bypass: OpenSSL CTX object modified after SSL objects are created
- CWE-603 Use of client-side authentication
- CWE-620 Unverified password change
- CWE-640 Weak password recovery mechanism for forgotten password
- CWE-645 Overly restrictive account lockout mechanism
- CWE-798 Use of hard-coded credentials
- CWE-804 Guessable CAPTCHA
- CWE-836 Use of password hash instead of password for authentication
OTG-AUTHN-004: While most applications require authentication to gain access to private information or to execute tasks, not every authentication method is able to provide adequate security. Negligence, ignorance, or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the log in page and directly calling an internal page that is supposed to be accessed only after authentication has been performed. In addition, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that the user is already authenticated. This can be accomplished either by modifying the given URL parameter, by manipulating the form, or by counterfeiting sessions. Problems related to the authentication schema can be found at different stages of the software development life cycle (SDLC), like the design, development, and deployment phases:
- In the design phase errors can include a wrong definition of application sections to be protected, the choice of not applying strong encryption protocols for securing the transmission of credentials, and many more.
- In the development phase errors can include the incorrect implementation of input validation functionality or not following the security best practices for the specific language.
- In the application deployment phase, there may be issues during the application setup (installation and configuration activities) due to a lack in required technical skills or due to the lack of good documentation.
OTG-AUTHN-010: 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
- Weak device to device authentication
- Weak device to mobile Application authentication
- Weak device to cloud system authentication
- Weak mobile application to cloud system authentication
- Weak web application to cloud system authentication
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.
Estimated Overall Risk Assessment: HIGH
Technical Impacts:
Business Impacts:
Detectability:
Prevalence:
Exploitability:
Attack Surfaces Grouped By Layer of Cyberspace
- Physical Network Layer
- Device Network Services
- Administrative Interface
- Device Web Interface
- Ecosystem Communications
- Mobile Application
- Logical Network Layer
- Vendor Backend APIs
- 3rd Party Backend APIs
- Ecosystem
- Cloud Web Interface
Known Intrusion / Exploit / Attack Cases and Threats
TBD
Identify, Detect, Protect, Respond, and Recover (NIST FICIC)
TBD
Analysis Tools and Training
TBD
Associated CVEs / Manufacturers / Devices
TBD
References
TBD