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 "Test defenses against application mis-use (OTG-BUSLOGIC-007)"
(Final edit) |
|||
Line 2: | Line 2: | ||
== Brief Description == | == Brief Description == | ||
− | + | The misuse and invalid use of of valid functionality can identify attacks attempting to enumerate the web application, identify weaknesses, and exploit vulnerabilities. Tests should be undertaken to determine whether there are application-layer defensive mechanisms in place to protect the application. | |
+ | |||
== Issue == | == Issue == | ||
− | The lack of active defenses allows an attacker | + | The lack of active defenses allows an attacker to hunt for vulnerabilities without any recourse. The application's owner will thus not know their application is under attack. |
+ | |||
== Example == | == Example == | ||
An authenticated user undertakes the following (unlikely) sequence of actions: | An authenticated user undertakes the following (unlikely) sequence of actions: | ||
+ | #Attempt to access a file ID their roles is not permitted to download | ||
+ | #Substitutes a single tick (') instead of the file ID number | ||
+ | #Alters a GET request to a POST | ||
+ | #Adds an extra parameter | ||
+ | #Duplicates a parameter name/value pair | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | The application is monitoring | + | The application is monitoring for misuse and responds after the 5th event with extremely high confidence the user is an attacker. For example the application: |
+ | *Disables critical functionality | ||
+ | *Enables additional authentication steps to the remaining functionality | ||
+ | *Adds time-delays into every request-response cycle | ||
+ | *Begins to record additional data about the user's interactions (e.g. sanitized HTTP request headers, bodies and response bodies) | ||
− | |||
− | |||
− | |||
− | |||
− | If the application does not respond in any way and the attacker can continue to abuse functionality and submit clearly malicious content at the application, the application has failed this test case. | + | If the application does not respond in any way and the attacker can continue to abuse functionality and submit clearly malicious content at the application, the application has failed this test case. In practice the discrete example actions in the example above are unlikely to occur like that. It is much more probable that a fuzzing tool is used to identify weaknesses in each parameter in turn. This is what a security tester will have undertaken too. |
− | |||
== Testing Method == | == Testing Method == | ||
Line 36: | Line 37: | ||
* Blocked requests | * Blocked requests | ||
* Actions that log a user out or lock their account | * Actions that log a user out or lock their account | ||
+ | |||
These may only be localised. Common localized (per function) defenses are: | These may only be localised. Common localized (per function) defenses are: | ||
Line 41: | Line 43: | ||
* Rejecting input containing certain characters | * Rejecting input containing certain characters | ||
* Locking out an account temporarily after a number of authentication failures | * Locking out an account temporarily after a number of authentication failures | ||
+ | |||
Localized security controls are not sufficient. There are often no defenses against general mis-use such as: | Localized security controls are not sufficient. There are often no defenses against general mis-use such as: | ||
Line 57: | Line 60: | ||
* Large number of, or high rate of use of, application-specific functionality (e.g. voucher code submission, failed credit card payments, file uploads, file downloads, log outs, etc). | * Large number of, or high rate of use of, application-specific functionality (e.g. voucher code submission, failed credit card payments, file uploads, file downloads, log outs, etc). | ||
− | |||
− | Not all the above need to be monitored by the application, but there is a problem if none of them are. By testing the web application, doing the above type of actions, was any response taken against the tester? If not, the tester should report that the application appears to have no application-wide active defenses against | + | These defenses work best in authenticated parts of the application, although rate of creation of new accounts or accessing content (e.g. to scrape information) can be of use in public areas. |
+ | |||
+ | |||
+ | Not all the above need to be monitored by the application, but there is a problem if none of them are. By testing the web application, doing the above type of actions, was any response taken against the tester? If not, the tester should report that the application appears to have no application-wide active defenses against misuse. Note it is sometimes possible that all responses to attack detection are silent to the user (e.g. logging changes, increased monitoring, alerts to administrators and and request proxying), so confidence in this finding cannot be guaranteed. In practice, very few applications (or related infrastructure such as a web application firewall) are detecting these types of misuse. | ||
+ | |||
== Test Tools == | == Test Tools == | ||
− | + | The tester can use many of the tools used for the other test cases. | |
+ | |||
== Related Test Cases == | == Related Test Cases == | ||
All other test cases are relevant. | All other test cases are relevant. | ||
+ | |||
== References == | == References == | ||
Line 77: | Line 85: | ||
* [[:File:Owasp-appensor-guide-v2.doc | AppSensor Guide v2]], OWASP | * [[:File:Owasp-appensor-guide-v2.doc | AppSensor Guide v2]], OWASP | ||
* Watson C, Coates M, Melton J and Groves G, [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf Creating Attack-Aware Software Applications with Real-Time Defenses], CrossTalk The Journal of Defense Software Engineering, Vol. 24, No. 5, Sep/Oct 2011 | * Watson C, Coates M, Melton J and Groves G, [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf Creating Attack-Aware Software Applications with Real-Time Defenses], CrossTalk The Journal of Defense Software Engineering, Vol. 24, No. 5, Sep/Oct 2011 | ||
+ | |||
== Remediation == | == Remediation == | ||
− | Build inactive defenses against application | + | Build inactive defenses against application misuse. |
Revision as of 11:31, 19 May 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
Brief Description
The misuse and invalid use of of valid functionality can identify attacks attempting to enumerate the web application, identify weaknesses, and exploit vulnerabilities. Tests should be undertaken to determine whether there are application-layer defensive mechanisms in place to protect the application.
Issue
The lack of active defenses allows an attacker to hunt for vulnerabilities without any recourse. The application's owner will thus not know their application is under attack.
Example
An authenticated user undertakes the following (unlikely) sequence of actions:
- Attempt to access a file ID their roles is not permitted to download
- Substitutes a single tick (') instead of the file ID number
- Alters a GET request to a POST
- Adds an extra parameter
- Duplicates a parameter name/value pair
The application is monitoring for misuse and responds after the 5th event with extremely high confidence the user is an attacker. For example the application:
- Disables critical functionality
- Enables additional authentication steps to the remaining functionality
- Adds time-delays into every request-response cycle
- Begins to record additional data about the user's interactions (e.g. sanitized HTTP request headers, bodies and response bodies)
If the application does not respond in any way and the attacker can continue to abuse functionality and submit clearly malicious content at the application, the application has failed this test case. In practice the discrete example actions in the example above are unlikely to occur like that. It is much more probable that a fuzzing tool is used to identify weaknesses in each parameter in turn. This is what a security tester will have undertaken too.
Testing Method
This test is unusual in that the result can be drawn from all the other tests performed against the web application. While performing all the other tests, take note of measures that might indicate the application has in-built self-defense:
- Changed responses
- Blocked requests
- Actions that log a user out or lock their account
These may only be localised. Common localized (per function) defenses are:
- Rejecting input containing certain characters
- Locking out an account temporarily after a number of authentication failures
Localized security controls are not sufficient. There are often no defenses against general mis-use such as:
- Forced browsing
- Bypassing presentation layer input validation
- Multiple access control errors
- Additional, duplicated or missing parameter names
- Multiple input validation or business logic verification failures with values that cannot be the result user mistakes or typos
- Structured data (e.g. JSPN, XML) of an invalid format is received
- Blatant cross-site scripting or SQL injection payloads are received
- Utilising the application faster than would be possible without automation tools
- Change in continental geo-location of a user
- Change of user agent
- Accessing a multi-stage business process in the wrong order
- Large number of, or high rate of use of, application-specific functionality (e.g. voucher code submission, failed credit card payments, file uploads, file downloads, log outs, etc).
These defenses work best in authenticated parts of the application, although rate of creation of new accounts or accessing content (e.g. to scrape information) can be of use in public areas.
Not all the above need to be monitored by the application, but there is a problem if none of them are. By testing the web application, doing the above type of actions, was any response taken against the tester? If not, the tester should report that the application appears to have no application-wide active defenses against misuse. Note it is sometimes possible that all responses to attack detection are silent to the user (e.g. logging changes, increased monitoring, alerts to administrators and and request proxying), so confidence in this finding cannot be guaranteed. In practice, very few applications (or related infrastructure such as a web application firewall) are detecting these types of misuse.
Test Tools
The tester can use many of the tools used for the other test cases.
Related Test Cases
All other test cases are relevant.
References
- Resilient Software, Software Assurance, US Department Homeland Security
- IR 7684 Common Misuse Scoring System (CMSS), NIST
- Common Attack Pattern Enumeration and Classification (CAPEC), The Mitre Corporation
- OWASP_AppSensor_Project
- AppSensor Guide v2, OWASP
- Watson C, Coates M, Melton J and Groves G, Creating Attack-Aware Software Applications with Real-Time Defenses, CrossTalk The Journal of Defense Software Engineering, Vol. 24, No. 5, Sep/Oct 2011
Remediation
Build inactive defenses against application misuse.