> For the complete documentation index, see [llms.txt](https://heinosass.gitbook.io/leet-sheet/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://heinosass.gitbook.io/leet-sheet/web-app-hacking/server-attacks/server-side-request-forgery.md). # Server Side Request Forgery Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing. This allows you to: * Make requests to internal services that you wouldn't be able to interact with otherwise. * Force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials. This can even lead to RCE when the SSRF allows you to interact with certain services that outsiders aren't supposed to be able to access (e.g Redis in certain cases). ## Tricks ### Use DNS to Access Internal IP Addresses If the IP address 127.0.0.1 is blocked, then you might be able to get around that by making the request to your-malicious-dns.com and your DNS will resolve the hostname to 127.0.0.1. You don't even have to pay to do this. There are a number of "wildcard DNS" services, such as [xip.io](https://ourcodeworld.com/articles/read/1510/xip-io-a-magic-domain-name-that-provides-wildcard-dns-for-any-ip-address), that can be used to resolve a hostname to an internal IP address. ### IPv6 to IPv4 Mapping Ipv6 maps to ipv4 with a certain prefix (`::ffff:`). So if localhost (`127.0.0.1`) is blocked, then `::ffff:127.0.0.1` might not be. ### Protocol Smuggling You can send a HTTP request to a non-HTTP text-based service. In the likely scenario that invalid commands get thrown out without invalidating the entire interaction, you will be able to smuggle valid text-based commands in the middle of the HTTP request. Therefore, you can interact with non-HTTP services HTTP based protocols: * Elastic * CouchDB * MongoDB * Docker Text-based protocols: * FTP * SMTP * Redis * Memcached If **gopher** is enabled, then that can make your life really easy, but it's usually not. However, often, controls have been put in place to try to prevent protocol smuggling. To read about how to circumvent these controls, read about [CRLF Injection](/leet-sheet/web-app-hacking/server-attacks/server-side-request-forgery.md#crlf-injection). ### CRLF Injection Often, controls have been put in place to try to prevent protocol smuggling. CRLF Injection is one way to overcome that. #### CRLF Injection in HTTPS You can’t smuggle SMTP over HTTP, because servers won’t accept `http://` requests. It will cut off the connection. But you can smuggle it over HTTPS, because of the TLS handshake. The Server Name Indication isn’t encrypted in a TLS handshake. If you put a space there, then you can smuggle an SMTP request. This works because of the way Linux’s glibc works. I think normally the after the space part is supposed to be metadata/comment or something. ``` https://127.0.0.1 %0D%0AHELO orange.tw%0D%0AMAIL FROM…:25/ ``` Before the space is HTTP, and after the space is an SMTP request we smuggled. You should test this using: ![](https://lh4.googleusercontent.com/D5zHpOMsEVbb5bR5QAhGrC_PIAlOeuXE_jnbcWr6RbpHMhCwCaNV1rAruf9MRfNDABQnnLs3hTCTBbHVpmaFaJ0gHTbcFrDIgYagPdYt-jASMx9pCPHCvdXPl384NPuxP1Cgi2jF) ### URL Parsing Issues Fantastic talk on how URL parsers can be tricked into doing weird things: Parsing the URL correctly is difficult. There's an RFC for it, but some libraries still do it differently. Issues can arise when there's inconsistency between components that parse URLs differently. For example, when one component verifies an URL and then another one makes a request to it. If the two components parse the URL differently, then you likely have an SSRF vulnerability. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://heinosass.gitbook.io/leet-sheet/web-app-hacking/server-attacks/server-side-request-forgery.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.