Server-side request forgery

Server-side request forgery (SSRF) is a computer security vulnerability that enables an attacker to send requests from a vulnerable server to internal or external systems^[1] or the server itself^[2]. The vulnerability arises when server functionality can be manipulated to access or modify resources that are otherwise inaccessible^[3]. SSRF is listed among the most critical API security risks^[4] and is recognized as one of the most serious software weaknesses^[5].

In an SSRF incident, the vulnerable server issues a request to a URL supplied or altered by the attacker. While the supplied URL can target any endpoint, common destinations include internal networks, localhost services, and cloud metadata endpoints that are otherwise inaccessible to external users.

SSRF is not limited to the HTTP protocol. In cases where the application itself performs the second request, it could use different protocols (e.g. FTP, SMB, SMTP, etc.) and schemes (e.g. file://, phar://, gopher://, data://, dict://, etc.)^[2]

The severity of an SSRF attack depends on the assets that can be accessed and whether the server’s response is observable to the attacker. In severe cases, SSRF can compromise cloud environments, exploit internal hosts, obtain sensitive information, or use the server as a proxy to conceal other malicious activities.

Similar to cross-site request forgery which utilizes a web client, for example, a web browser, within the domain as a proxy for attacks; an SSRF attack utilizes a vulnerable server within the domain as a proxy.

In this type of attack the response is displayed to the attacker. The server fetches the URL requested by the attacker and sends the response back to the attacker.

In this type of attack the response is not sent back to the attacker. Therefore, the attacker has to devise ways to confirm this vulnerability.

SSRF occurs when an API endpoint accesses a URL supplied by the client without verifying that the request is directed to an intended destination^[6].

Prevention measures include input validation, which can be supported through Static Analysis Security Testing (SAST) tooling. When feasible, restricting server requests to an allowlist of trusted applications is recommended, although additional safeguards may still be necessary to address hostname resolution, redirects and DNS rebindings. When servers must send requests to arbitrary external domains or IP addresses, network segregation is recommended to block unauthorized traffic at the network layer^[2].

• Capital One (2019) A SSRF exploit that exposed an AWS credential key led to the breach of 1 million social insurance numbers, 140,000 Social Security Numbers, and 80,000 bank account numbers, affecting approximately 100 million individuals in the United States and approximately 6 million in Canada^[7]. The company received an $80 million fine from the U.S. Office of the Comptroller of the Currency (OCC)^[8], and paid $190 million to settle a class-action lawsuit^[9] related to the breach.
• Microsoft Exchange Server (2021) An SSRF vulnerability was leveraged to send arbitrary HTTP requests and authenticate as the Exchange server^[10]. It became the most well-known and impactful Exchange exploit chain and affected an estimated 250,000 servers and 30,000 organizations in the US^[11].

0.00 (0 votes) Original source: https://en.wikipedia.org/wiki/Server-side request forgery. Read more