SSRF attack definitionServer-side request forgery (SSRF) attacks consist of an attacker tricking the server into making an unauthorized request. The name itself implies that a request that should have otherwise been made by the server has been forged by the attacker.SSRF attacks are far more dangerous than cross-site request forgery (CSRF) attacks. That\u2019s because, in a way, CSRF attacks involve an attacker hijacking a user\u2019s web browser and performing unauthorized actions on the user\u2019s behalf. During an active CSRF exploit, the malicious activity triggers from the client-side, and it is typically the individual user or their assets being targeted. Of course, CSRF attacks become dangerous when the targeted user has administrator privileges to the web application\u2014in such a case the entire application could be compromised.SSRF attacks, on the other hand, target the web server itself without any necessary involvement or interaction from its users. Just by making a malicious HTTP request to the server, the attacker can instruct the back end to perform malicious actions.Capital One\u2019s major data breach of 2019 that affected approximately 106 million users across the US and Canada stemmed from an SSRF vulnerability exploit. Some of the compromised information included customer names, addresses, contact information, dates of birth, US Social Security numbers (SSNs), Canadian Social Insurance numbers (SINs), credit scores, payment history, and self-reported income.Many cybersecurity experts including Cloudflare\u2019s Evan Johnson pinned the incident on an SSRF attack. More recently, both the actively exploited Microsoft Exchange zero-days from March 2021\u00a0(CVE-2021-26855) and the recently discovered ProxyShell exploits are the result of SSRF flaws.How does an SSRF attack work?When making a request to a web server or clicking on a hyperlink, visitors are provided files that are meant to be seen by the world\u2014that is, those present in the public_html or www folders. Anything present in private folders or databases is typically restricted to more privileged users, such as server administrators.However, files and assets that are directly accessible to the general audience surfing the web might be accessible by the server itself. For example, as a visitor, you can easily request a public URL like https:\/\/www.csoonline.com\/uk\/events but not the sensitive system files on CSO\u2019s server such as \/etc\/shadow or \/etc\/passwd. The web server can likely access these files.Basic or non-blind SSRFIn a vulnerable environment, a web application running on a server could also have access to these files. The basis of any SSRF attack is that a publicly accessible (web) server can be tricked by the end user into providing access to sensitive files on that server or access to other, more privileged systems or operations that are otherwise restricted for the end user.For example, take the example of a vulnerable e-commerce site at shop.example.com that uses multiple servers. Users can visit shop.example.com to browse through the products, but the product detail sits on another server, to which users don\u2019t have direct access. Let\u2019s assume the server behind shop.example.com does.So, when you click on a product, the shop\u2019s main server makes a secondary request. To keep it simple, let\u2019s assume it\u2019s a simple GET request with the URL visible in your browser\u2019s address bar: shop.example.com\/?url=shop-server-2.example.com\/product555\/Going to this complete URL provides you with the details for product #555. If an attacker can reasonably deduce that they don\u2019t have direct access to http:\/\/shop-server-2.example.com\/product555\/ but shop.example.com does, they have now found a way to use shop\u2019s main server as the middle ground. They can potentially exploit this web server to gain access to restricted assets and files.If shop.example.com has lax protection and is vulnerable to SSRF, an attacker could simply navigate to shop.example.com\/?url=file:\/\/\/etc\/passwd and very likely the vulnerable server now returns contents of the sensitive \/etc\/passwd file if no protections are in place.\u00a0\u00a0Depending on the attacker\u2019s goal, the same URL could be modified to include localhost or an internal IP address, along with a custom port number, among other things.This is just one of the very basic examples of many possibilities SSRF attacks have to offer. The above scenario demonstrates a \u201cbasic\u201d or non-blind SSRF in which a malicious request made by the attacker results in visible data being returned by the server. Such attacks are excellent for threat actors looking to exfiltrate data from secret files and assets or to check if specific system ports are open and running services.Blind SSRFBlind SSRF attacks, on the other hand, do not necessarily return any data but rather focus on performing unauthorized actions on the server\u2019s backend. With blind SSRF attacks, the attacker\u2019s focus would be to, for example, modify something on the server, alter or delete files, change permissions, and perform a variety of unauthorized operations rather than going for data exfiltration.As an extension of the example above, suppose the above URL was modified to go to shop.example.com\/?url=http:\/\/example.com\/some-very-large-file.png where the server keeps attempting to fetch an abnormally large file from an external server. Such a request may cause shop.example.com\u2019s web server to crash, resulting in denial of service (DoS) for everyone. This type of SSRF attack is \u201cblind\u201d as the focus isn\u2019t on retrieving a visible response or data but rather performing a detrimental action on the server\u2019s behalf.How to mitigate SSRF vulnerabilitiesThe basis of mitigating SSRF flaws remains to prevent users from influencing input that reaches your internal applications. Your internal applications should never blindly trust the input or assume that it\u2019s coming from an authentic source.For example, in the above example of shop.example.com, why does the server even accept file:\/\/\/ URLs? The same would go for ftp:\/\/ or application-specific URI schemas such as slack: or skype:. The system should ideally be restricted to only a select few protocols, such as HTTP and HTTPS, depending on the needs of the application. There are better ways to conduct the same operation described in this example so that a URL parameter to an internal server never needs to be passed from the client side.How about just passing a product number\u2014shop.example.com\/?product=555\u2014and letting shop.example.com\u2019s back end fetch details for product 555 from another server, the address to which is hard-coded on the back-end? You would do this only after sanitizing the numerical \u201cproduct\u201d parameter, and ensuring it is free of any malicious data.Secondly, if the logic of the program cannot be modified and it absolutely needs a URL, an allowlist and denylist approach is a solution. For example, some applications implementing OAuth-based logins submit \u201credirect URLs\u201d among other URL parameters in-between requests, and have been found to be vulnerable to SSRF.Allowlist or whitelisting approaches are safer as the program allows access to only the permitted objects or in this context, locations, making the process more selective and secure. The denylist approach, on the other hand, denies access to only certain locations of your choosing, such as localhost or 127.0.0.1 but allows everything else. Denylist approaches run the risk of a clever attacker finding workarounds, e.g., via HTTP redirects, obfuscated URLs, DNS rebinding, or more realistically the server administrator forgetting to include something on the denylist that then gets the attention of the attacker.As with most vulnerabilities, SSRF flaws can be squashed by adopting a trusting no-one mindset\u2014sanitizing input and minimizing the possibility of input being influenced by the end user. Additionally, adopting the principle of least privilege where the system only grants access to APIs and internal systems that are absolutely necessary for the operation via an allowlist is a strong approach toward curtailing SSRF exploits.