R237. Ascertain human interaction

Requirement

The system must guarantee that user actions are performed by a human (e.g., registration, authentication and password recovery). This can be achieved using CAPTCHA, incremental delays or mechanisms that prevent excessive crawling and indexing.

Description

There exist several attacks that have been automated or depend on a robot for their execution. Many of them focus on exploiting vulnerabilities in authentication forms. In order to hinder the effectiveness of these attacks, the system must implement mechanisms that help ensure that the entity with which it is interacting is a human being.

References

  1. CAPEC-49: Password Brute Forcing. In this attack, the adversary tries every possible value for a password until they succeed. A brute force attack, if feasible computationally, will always be successful because it will essentially go through all possible passwords given the alphabet used (lower case letters, upper case letters, numbers, symbols, etc.) and the maximum length of the password.

  2. 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.

  3. CWE-307: Improper Restriction of Excessive Authentication Attempts. The software does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame, making it more susceptible to brute force attacks.

  4. CWE-799: Improper Control of Interaction Frequency. The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests.

  5. CWE-804: Guessable CAPTCHA. The software uses a CAPTCHA challenge, but the challenge can be guessed or automatically recognized by a non-human actor.

  6. NERC CIP-007-6. B. Requirements and measures. R5.7 Where technically feasible, either limit the number of unsuccessful authentication attempts; or generate alerts after a threshold of unsuccessful authentication attempts.

  7. OWASP Top 10 A2:2017-Broken Authentication. Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users' identities temporarily or permanently.

  8. OWASP-ASVS v4.0.1 V1.2 Authentication Architectural Requirements.(1.2.4) Verify that all authentication pathways and identity management APIs implement consistent authentication security control strength, such that there are no weaker alternatives per the risk of the application.

  9. OWASP-ASVS v4.0.1 V2.2 General Authenticator Requirements.(2.2.1) Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar. Verify that no more than 100 failed attempts per hour is possible on a single account.

  10. OWASP-ASVS v4.0.1 V8.1 General Data Protection.(8.1.4) Verify the application can detect and alert on abnormal numbers of requests, such as by IP, user, total per hour or day, or whatever makes sense for the application.

  11. OWASP-ASVS v4.0.1 V11.1 Business Logic Security Requirements.(11.1.2) Verify the application will only process business logic flows with all steps being processed in realistic human time, i.e., transactions are not submitted too quickly.

  12. OWASP-ASVS v4.0.1 V11.1 Business Logic Security Requirements.(11.1.8) Verify the application has configurable alerting when automated attacks or unusual activity is detected.

  13. OWASP-ASVS v4.0.1 V13.2 RESTful Web Service Verification Requirements.(13.2.4) Verify that REST services have anti-automation controls to protect against excessive calls, especially if the API is unauthenticated.

  14. PCI DSS v3.2.1 - Requirement 6.5.10 Address common coding vulnerabilities in software-development processes such as broken authentication and session management.

Copyright © 2020 Fluid Attacks, We hack your software. All rights reserved.

Service status - Terms of Use - Privacy Policy - Cookie Policy