Server Side Request Forgery (**SSRF**) is a web vulnerability where an attacker manipulates a vulnerable application to make requests to internal or external resources on behalf of the server. This can lead to data exposure, unauthorised access to internal systems, or service disruptions. There are two types of SSRF vulnerability; - The first is a regular SSRF where data is returned to the attacker's screen. - The second is a Blind SSRF vulnerability where an SSRF occurs, but no information is returned to the attacker's screen. Assume the expected server request is as follow: ```http http://website.thm/stock?server=api&id=123 ``` Which translates to ```http http://api.website.thm/api/stock/item?id=123 ``` However, an attacker can use the `&x=` at the end of the payload to redirect the request: ```http http://website.thm/stock?server=hacker-domain.thm/code?id=12&x= ``` which will now translate to ```http http://hacker-domain.thm/code?id=12&x=.website.thm/api/stock/item?id=123 ``` Since variables are delimited by `&`, the server will ignore the value assigned to `x` which is `.website.thm/api/stock/item?id=123` Potential SSRF vulnerabilities can be spotted in web applications in many different ways. ![[Detect SSRF.png]] ### Defences against SSRF #### Deny List A Deny List is where *all requests are accepted apart from resources specified in a list* or matching a particular pattern. A Web Application may employ a deny list to protect sensitive endpoints, IP addresses or domains from being accessed by the public while still allowing access to other locations. A specific endpoint to restrict access is the localhost, which may contain server performance data or further sensitive information, so domain names such as localhost and `127.0.0.1` would appear on a deny list. Attackers can bypass a Deny List by using alternative localhost references such as `0`, `0.0.0.0`, `0000`, `127.1`, `127.\*.\*.\*`, `2130706433`, `017700000001` or subdomains that have a DNS record which resolves to the IP Address `127.0.0.1` such as `127.0.0.1.nip.io`. ^226f5b Also, in a cloud environment, it would be beneficial to block access to the IP address `169.254.169.254`, which contains metadata for the deployed cloud server, including possibly sensitive information. An *attacker can bypass this by registering a subdomain on their own domain with a DNS record that points to the IP Address* `169.254.169.254`. #### Allow List An allow list is where *all requests get denied unless they appear on a list* or match a particular pattern, such as a rule that an URL used in a parameter must begin with `https://website.thm`. An attacker could quickly *circumvent this rule by creating a subdomain on an attacker's domain* name, such as `https://website.thm.attackers-domain.thm`. The application logic would now allow this input and let an attacker control the internal HTTP request. #### Open Redirect If the above bypasses do not work, there is one more trick up the attacker's sleeve, the open redirect. An *open redirect is an endpoint on the server where the website visitor gets automatically redirected to another website address*. Take, for example, the link `https://website.thm/link?url=https://tryhackme.com`. This endpoint was created to record the number of times visitors have clicked on this link for advertising/marketing purposes. But imagine there was a potential SSRF vulnerability with stringent rules which only allowed URLs beginning with `https://website.thm/`. An attacker could utilise the above feature to redirect the internal HTTP request to a domain of the attacker's choice.