CAPEC-664: Server Side Request Forgery
An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.
Last updated
Overview
CAPEC-664 (Server Side Request Forgery) is a standard-level attack pattern catalogued by MITRE in the Common Attack Pattern Enumeration and Classification (CAPEC). It describes a recurring method attackers use to exploit software weaknesses.
How the attack works
The phases an attacker typically follows to carry out this attack.
- Step 1Explore
[Find target application] Find target web application that accepts a user input and retrieves data from the server
- Step 2Experiment
[Examine existing application requests] Examine HTTP/GET requests to view the URL query format. Adversaries test to see if this type of attack is possible through weaknesses in an application's protection to Server Side Request Forgery
- Attempt manipulating the URL to retrieve an error response/code from the server to determine if URL/request validation is done.
- Use a list of XSS probe strings to specify as parameters to known URLs. If possible, use probe strings with unique identifiers.
- Create a GET request with a common server file path such as /etc/passwd as a parameter and examine output.
- Step 3Exploit
[Malicious request] Adversary crafts a malicious URL request that assumes the privilege level of the server to query internal or external network services and sends the request to the application
What the attacker needs
Prerequisites
- Server must be running a web application that processes HTTP requests.
Skills required
- Medium skill: The adversary will have to detect the vulnerability through an intermediary service or specify maliciously crafted URLs and analyze the server response.
- High skill: The adversary will be required to access internal resources, extract information, or leverage the services running on the server to perform unauthorized actions such as traversing the local network or routing a reflected TCP DDoS through them.
Resources required
- [None] No specialized resources are required to execute this type of attack.
Consequences
What a successful CAPEC-664 attack can achieve.
Modify Data
Affects: Integrity, Confidentiality, Availability
Read Data
Affects: Confidentiality
Resource Consumption
Affects: Availability
How to mitigate it
Defenses that reduce the risk of CAPEC-664.
- Handling incoming requests securely is the first line of action to mitigate this vulnerability. This can be done through URL validation.
- Further down the process flow, examining the response and verifying that it is as expected before sending would be another way to secure the server.
- Allowlist the DNS name or IP address of every service the web application is required to access is another effective security measure. This ensures the server cannot make external requests to arbitrary services.
- Requiring authentication for local services adds another layer of security between the adversary and internal services running on the server. By enforcing local authentication, an adversary will not gain access to all internal services only with access to the server.
- Enforce the usage of relevant URL schemas. By limiting requests be made only through HTTP or HTTPS, for example, attacks made through insecure schemas such as file://, ftp://, etc. can be prevented.
Examples
An e-commerce website allows a customer to filter results by specific categories. When the customer selects the category of choice, the web shop queries a back-end service to retrieve the requested products. The request may look something like: POST /product/category HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 200 vulnerableService=http://vulnerableshop.net:8080/product/category/check%3FcategoryName%3DsomeCategory A malicious user can modify the request URL to look like this instead: POST /product/category HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 200 vulnerableService=http://localhost/server-status or vulnerableService = file:///etc/passwd or vulnerableService=dict://localhost:12345/info If the exploit is successful, the server may return the data requested by the adversary root:!:0:0::/:/usr/bin/ksh daemon:!:1:1::/etc: bin:!:2:2::/bin: sys:!:3:3::/usr/sys: adm:!:4:4::/var/adm: uucp:!:5:5::/usr/lib/uucp: guest:!:100:100::/home/guest: nobody:!:4294967294:4294967294::/: lpd:!:9:4294967294::/: lp:*:11:11::/var/spool/lp:/bin/false invscout:*:200:1::/var/adm/invscout:/usr/bin/ksh nuucp:*:6:5:uucp login user:/var/spool/uucppublic:/usr/sbin/uucp/uucico paul:!:201:1::/home/paul:/usr/bin/ksh jdoe:*:202:1:My name:/home/myname:/usr/bin/ksh
The CallStranger attack is an observed example of SSRF. It specifically targets the UPnP (Universal Plug and Play) protocol used by various network devices and gaming consoles. To execute the attack, an adversary performs a scan of the LAN to discover UPnP enabled devices, and subsequently a list of UPnP services they use. Once the UPnP service endpoints are listed, a vulnerability in the UPnP protocol is used to send these endpoints as encrypted to a verification server via the UPnP Callback method. Because the encryption is done on the client side, the server returns an encrypted list of services which is decrypted on the client side. The adversary then has a list of services running the vulnerable UPnP protocol, which the adversary can leverage to make spoofed requests. [REF-646]
Frequently asked questions
Common questions about CAPEC-664.
- What is CAPEC-664?
- An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.
- How does a Server Side Request Forgery attack work?
- It typically unfolds over 3 phases. It begins with: [Find target application] Find target web application that accepts a user input and retrieves data from the server
- How do you prevent CAPEC-664?
- Handling incoming requests securely is the first line of action to mitigate this vulnerability. This can be done through URL validation.
- What weaknesses does CAPEC-664 target?
- CAPEC-664 exploits 2 CWE weaknesses, including CWE-20 (Improper Input Validation), CWE-918 (Server-Side Request Forgery (SSRF)).
- How severe is CAPEC-664?
- MITRE rates CAPEC-664 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-664
Track the CVEs and weaknesses attackers exploit with this technique, with AI-written analysis and remediation guidance.