SSRF (Server Side Request Forgery)

👉 Overview


👀 What ?

Server Side Request Forgery (SSRF) is a type of security vulnerability that allows an attacker to compel a networked server to send HTTP requests to an arbitrary domain of the attacker's choosing. This can potentially allow the attacker to access information from services that are not directly exposed on the Internet.

🧐 Why ?

SSRF is a significant threat as it can be used by an attacker to bypass access controls, such as firewalls, that prevent them from directly reaching the internal services. By exploiting SSRF, an attacker can cause the server to make requests that expose sensitive information, conduct port scanning of internal resources, or even execute arbitrary commands.

⛏️ How ?

SSRF can be exploited when a web application makes a request to a specified URL and does not properly validate or restrict the URL. For instance, an attacker might manipulate the URL to point to localhost or to another server within the organization's internal network. It is crucial to properly sanitize user input and use allow-lists for server-side requests to mitigate this risk.

⏳ When ?

SSRF vulnerabilities have been discovered and exploited in recent years as more applications rely on server-side HTTP requests. It has been used in several high-profile attacks, including the 2017 Equifax data breach.

⚙️ Technical Explanations


At its core, SSRF is about manipulating the target server to send requests on behalf of the attacker. The attacker leverages the fact that the server has more privileges than an external user might have, and can thus access resources that are otherwise inaccessible. From a technical perspective, SSRF can be seen as an instance of an injection attack, where the 'injected' material is a malicious URL. Mitigation strategies involve careful validation of user input, use of allow-lists, and limiting the server's privileges as much as possible.

We use cookies

We use cookies to ensure you get the best experience on our website. For more information on how we use cookies, please see our cookie policy.