CAPEC-58: Restful Privilege Elevation
An adversary identifies a Rest HTTP (Get, Put, Delete) style permission method allowing them to perform various malicious actions upon server data due to lack of access control mechanisms implemented within the application service accepting HTTP messages.
Last updated
Overview
Rest uses standard HTTP (Get, Put, Delete) style permissions methods, but these are not necessarily correlated generally with back end programs. Strict interpretation of HTTP get methods means that these HTTP Get services should not be used to delete information on the server, but there is no access control mechanism to back up this logic. This means that unless the services are properly ACL'd and the application's service implementation are following these guidelines then an HTTP request can easily execute a delete or update on the server side. The attacker identifies a HTTP Get URL such as http://victimsite/updateOrder, which calls out to a program to update orders on a database or other resource. The URL is not idempotent so the request can be submitted multiple times by the attacker, additionally, the attacker may be able to exploit the URL published as a Get method that actually performs updates (instead of merely retrieving data). This may result in malicious or inadvertent altering of data on the server.
What the attacker needs
Prerequisites
- The attacker needs to be able to identify HTTP Get URLs. The Get methods must be set to call applications that perform operations other than get such as update and delete.
Skills required
- Low skill: It is relatively straightforward to identify an HTTP Get method that changes state on the server side and executes against an over-privileged system interface
Consequences
What a successful CAPEC-58 attack can achieve.
Modify Data
Affects: Integrity
Gain Privileges
Affects: Confidentiality, Access Control, Authorization
How to mitigate it
Defenses that reduce the risk of CAPEC-58.
- Design: Enforce principle of least privilege
- Implementation: Ensure that HTTP Get methods only retrieve state and do not alter state on the server side
- Implementation: Ensure that HTTP methods have proper ACLs based on what the functionality they expose
Examples
The HTTP Get method is designed to retrieve resources and not to alter the state of the application or resources on the server side. However, developers can easily code programs that accept a HTTP Get request that do in fact create, update or delete data on the server. Both Flickr (http://www.flickr.com/services/api/flickr.photosets.delete.html) and del.icio.us (http://del.icio.us/api/posts/delete) have implemented delete operations using standard HTTP Get requests. These HTTP Get methods do delete data on the server side, despite being called from Get which is not supposed to alter state.
Frequently asked questions
Common questions about CAPEC-58.
- What is CAPEC-58?
- An adversary identifies a Rest HTTP (Get, Put, Delete) style permission method allowing them to perform various malicious actions upon server data due to lack of access control mechanisms implemented within the application service accepting HTTP messages.
- How do you prevent CAPEC-58?
- Design: Enforce principle of least privilege
- What weaknesses does CAPEC-58 target?
- CAPEC-58 exploits 2 CWE weaknesses, including CWE-267 (Privilege Defined With Unsafe Actions), CWE-269 (Improper Privilege Management).
- How severe is CAPEC-58?
- MITRE rates CAPEC-58 as High severity with high likelihood of attack.
References
Attack-pattern data is sourced from the MITRE CAPEC catalog (v3.9). Weakness associations link to the corresponding CWE entries on RadicalNotion.AI.
Defend against CAPEC-58
Track the CVEs and weaknesses attackers exploit with this technique, with AI-written analysis and remediation guidance.