SSRF

Server-Side Request Forgery. It’s a vulnerability that allows a malicious user to cause the web server to make an additional or edited ==HTTP request to the resource of the attacker’s choosing.==

Types of SSRF

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.

A Deny List is where all requests are accepted apart from resources specified in a list or matching a particular pattern.
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==.
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 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.

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/====.==