+V-RT-B Stream B: Misuse/Abuse Testing
---+V-RT-1-B Perform fuzz testing
---+V-RT-2-B Define and run security abuse cases from requirements
---+V-RT-3-B Perform security stress testing

V-RT-B Stream B: Misuse/Abuse Testing

Misuse/Abuse Testing leverages fuzzing, misuse/abuse cases, and the identification of any functionality or resources in the software that can be abused in order to identify weaknesses in features to attack an application.

1. Ħarsa ġenerali

V-RT-1-B Perform fuzz testing

Maturity level 1 objective of the practice: Opportunistically find basic vulnerabilities and other security issues.

Benefit: Insight into the behavior of your applications when dealing with unexpected input

Short description: Perform security fuzz testing.

Perform fuzzing, sending random or malformed data to the test subject in an attempt to make it crash. Fuzz testing or Fuzzing is a Black Box software testing technique, which consists of finding implementation bugs using automated malformed or semi-malformed data injection. Cover at least a minimum fuzzing for vulnerabilities against the main input parameters of the application.

The advantage of fuzz testing is the simplicity of the test design, and its lack of preconceptions about system behavior. The stochastic approach results in bugs that human eyes or structured testing would often miss. It is also one of the few means of assessing the quality of a closed system (such as a SIP phone). The simplicity of fuzzing a target is offset by the difficulty in accurately detecting and triaging crashes. Favor existing fuzzing tools and frameworks to leverage their supporting tooling.
V-RT-2-B Define and run security abuse cases from requirements

Maturity level 2 objective of the practice: Perform implementation review to discover application-specific risks against the security requirements.

Benefit: Detection of application business logic flaws

Short description: Create and test abuse cases and business logic flaw tests.

Misuse and abuse cases describe unintended and malicious use scenarios of the application, describing how an attacker could do this. Create misuse and abuse cases to misuse or exploit the weaknesses of controls in software features to attack an application. Use abuse-case models for an application to serve as fuel for identification of concrete security tests that directly or indirectly exploit the abuse scenarios.

Abuse of functionality, sometimes referred to as a "business logic attack", depends on the design and implementation of application functions and features. An example is using a password reset flow to enumerate accounts. As part of business logic testing, identify the business rules that are important for the application and turn them into experiments to verify whether the application properly enforces the business rule. For example, on a stock trading application, is the attacker allowed to start a trade at the beginning of the day and lock in a price, hold the transaction open until the end of the day, then complete the sale if the stock price has risen or cancel if the price dropped?
V-RT-3-B Perform security stress testing

Maturity level 3 objective of the practice: Maintain the application security level after bug fixes, changes or during maintenance.

Benefit: Transparency of resilience against denial of service attacks

Short description: Denial of service and security stress testing.

Applications are particularly susceptible to denial of service attacks. Perform denial of service and security stress testing against them in controlled conditions, preferably on application acceptance environments.

Load testing tools generate synthetic traffic, allowing you to test the application's performance under heavy load. One important test is how many requests per second an application can handle while remaining within its performance requirements. Testing from a single IP address is still useful as it gives an indication of how many requests an attacker must generate to impact the application.

Denial of service attacks typically result in application resource starvation or exhaustion. To determine if any resources can be used to create a denial of service, analyze each application resource to see how it can be exhausted. Prioritize actions an unauthenticated user can do. Complement overall denial of service tests with security stress tests to perform actions or create conditions which cause delays, disruptions, or failures of the application under test.

Notes

I removed references to specific tools and a detailed explanation of denial of service tests. These can all be added to the guidance notes.

1.1 Referenzi

1.2 Rekwiżiti identifikati

1.3 Regolamenti relatati

2. Rekwiżiti identifikati

Rekwiżiti

3. Regolamenti relatati

Regolamenti
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.