Server-side request forgery (SSRF) is a vulnerability that lets an attacker send requests on behalf of a server. During an SSRF, attackers forge the request signatures of the vulnerable server, allowing them to assume a privileged position on a network, bypass firewall controls, and gain access

to internal services.

Normally websites are hosted on servers yh, lets say on a single port, port 8080 which is the only public application, from the server, but there are other things and services running on the servers internal network, it can be hosting DNS, local webpages, admin pages, docker, RDP , etc, we as external users are not supposed to access that , since we are outside the network, for example only when you are connected to the network that you can request for something like http://192.0.1.16:8080, which may be hosting something like their router login page or an internal webpage or whatever service, if you typed that on your browser normally you’d only get what your computer has on your own network for example maybe your own router login page or your own internal webpage or whatever is on that port, but now the server we are targeting is hosing their public website and trusts requests from that website , because it holds the database contents and that’s whet the users would be requesting right?, things like their profile pic, their current balance, points or whatever or maybe even something they stored like a file, all these are stored on the server and we can access them through the website despite being outside the network, so are you seeing what i’m talking about now?, we are requesting things from the server, and its responding to the website and to us indirectly, now what if we requested for localhost port 80 from the server hmm?, if no checklists or protections are put in place , the server will also give that to us thinking its a normal resource we are requesting , so now we can see stuff from the internal network we aren’t meant to see.

SSRF vulnerabilities have two types: regular SSRF and blind SSRF. The mechanisms behind both are the same: each exploits the trust between machines on the same network. The only difference is that in a blind SSRF, the attacker does not receive feedback from the server via an HTTP response

SSRF worked if we see admin.example.com displayed. But in a blind SSRF, the forged request executes without any confirmation sent to the attacker. Let’s say that on public.example.com another functionality allows users to send requests via its web server. But this endpoint does not return the

resulting page to the user. If attackers can send requests to the internal network, the endpoint suffers from a blind SSRF vulnerability: https://public.example.com/send_request?url=https://admin.example.com/delete_user?user=1

Prevention

SSRFs happen when servers need to send requests to obtain external resources. For example, when you post a link on Twitter, Twitter fetches an image from that external site to create a thumbnail. If the server doesn’t stop users from accessing internal resources using the same mechanisms, SSRF

vulnerabilities occur. Let’s look at another example. Say a page on public.example.com allows

users to upload a profile photo by retrieving it from a URL via this POST request:

POST /upload_profile_from_url

Host: public.example.com

(POST request body)

user_id=1234&url=https://www.attacker.com/profile.jpeg

To fetch profile.jpeg from attacker.com, the web application would have to visit and retrieve contents from attacker.com. This is the safe and intended behavior of the application. But if the server does not make a distinction between internal and external resources, an attacker could just as easily request a local file stored on the server, or any other file on the network. For instance, they could make the following POST request, which would cause the web server to fetch the sensitive file and display it as the user’s profile picture:

POST /upload_profile_from_url

Host: public.example.com

(POST request body)

user_id=1234&url=https://localhost/passwords.txt

Two main types of protection against SSRFs exist: blocklists and allow lists. Blocklists are lists of banned addresses. The server will block a request if it contains a blocklisted address as input. Because applications often need to fetch resources from a variety of internet sources, too many to explicitly allow, most applications use this method. Companies blocklist internal network addresses and reject any request that redirects to those addresses. On the other hand, when a site implements allowlist protection, the server allows only requests that contain URLs found in a predetermined list