Server-Side Request Forgery (SSRF)

In an SSRF attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL that the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP-enabled databases or perform HTTP POST requests towards internal services which are not intended to be exposed.

An attacker can use an SSRF vulnerability as a way to gather information about the server and the local network.

For example, on the "Research" page ( /research) in the application, a user submits a stock symbol. The stock symbol is concatenated to a Yahoo URL and the server fetches the response and displays the page.

Here is a code snippet from routes/research.js,

    // If a stock symbol has been submitted, concatenate the symbol to the URL and return the HTTP Response
    if (req.query.symbol) {
        var url = req.query.url+req.query.symbol; 
        needle.get(url, function(error, newResponse) { ... }
                    

An attacker can change the url and symbol parameters to point to an attacker-controlled website to interact with the server.

To prevent SSRF vulnerabilities in web applications, it is recommended to adhere to the following guidelines:

1. Use a whitelist of allowed domains, resources and protocols from where the web server can fetch resources.
2. Any input accepted from the user should be validated and rejected if it does not match the positive specification expected.
3. If possible, do not accept user input in functions that control where the web server can fetch resources.