SSRF
Server-Side Request Forgery (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 can lead to unauthorized access to data and systems.
Types of SSRF
Regular SSRF (Non-Blind): In this type, the attacker receives a response to their forged request. This allows the attacker to interact directly with the response, making it easier to exploit the vulnerability as they can observe the impact of their actions in real-time. The attacker can modify the request to probe internal networks or access restricted resources, using the response to refine their attack.
Blind SSRF: In Blind SSRF, the attacker does not receive a direct response from the forged request. This makes it more challenging to exploit since the attacker cannot directly see the result of the attack. However, Blind SSRF can still be very dangerous. Attackers may use other techniques such as monitoring changes on the server, using out-of-band interactions (like DNS lookups or external web interactions initiated by the server), or relying on the server's behavior to infer the success of their requests.
Impact of SSRF Attacks
Access to Unauthorized Areas: SSRF can be used to bypass firewalls and access services that are only accessible from the server itself or from certain internal networks. This includes accessing metadata services of cloud providers, which can lead to the disclosure of sensitive data.
Access to Customer/Organizational Data: An attacker could access confidential databases or API endpoints that are not meant to be accessible from the outside world, leading to data breaches.
Scaling to Internal Networks: SSRF can be a stepping stone to further attacks within an organization’s internal network. Once the attacker has breached the perimeter via SSRF, they can move laterally within the network, potentially accessing other internal systems.
Reveal Authentication Tokens/Credentials: SSRF attacks can expose sensitive information like API keys, database credentials, or session tokens. If the server makes requests to internal services that include authentication credentials, an attacker might intercept or reuse these credentials.
Last updated