Skip to main content

Understanding SSRF: Types & Example


SSRF, or Server-Side Request Forgery, is a security vulnerability that occurs when an attacker can make a web application send arbitrary requests to other resources on the server or to external servers, typically without the user's knowledge. This can have serious consequences, such as unauthorized access to internal resources, data leakage, or even remote code execution.

There are two main types of SSRF:
  • Classic SSRF: In this type, an attacker manipulates a web application to make a request to an internal server or resource, such as a database server or a local file. The attacker can often control the content and parameters of the request, allowing them to exfiltrate data or interact with internal systems.
  • Blind SSRF: In a blind SSRF, the attacker cannot directly see the response of the request they triggered, but they can still infer the success or failure of their actions through side-channel attacks. For example, the attacker might trigger a request and then observe changes in the application's behavior, response times, or error messages to determine if their attack was successful.

Here's an example of SSRF:


Suppose you have a web application that allows users to input a URL and then fetch and display the content of that URL. An attacker discovers that this application is vulnerable to SSRF and exploits it in the following way:
  • The attacker submits a URL pointing to an internal resource, like "http://internal-server/admin-page."
  • The web application fetches the content of the provided URL and displays it to the user.
  • The attacker is able to view sensitive information from the "admin-page" on the internal server because the application, due to the SSRF vulnerability, was tricked into making a request to an internal resource.

To prevent SSRF attacks, web developers can implement several countermeasures:
  • Input validation: Carefully validate and sanitize any user-supplied URLs and input to ensure they do not point to internal resources or unauthorized locations.
  • Whitelisting: Allowlisted domains and IP addresses can be defined, so the application only fetches data from trusted sources.
  • Use network-level protections: Configure network-level firewalls, proxies, and other security measures to restrict outgoing traffic from the application to prevent SSRF.
  • Least privilege principle: Limit the permissions and access rights of the web application and its server to reduce the potential damage an attacker can do if they manage to exploit an SSRF vulnerability.


SSRF is a significant security concern, and developers should be aware of the potential risks and take measures to mitigate them to protect their applications and data from unauthorized access and manipulation.

Popular posts from this blog

Open eClass – CVE-2024-26503: Unrestricted File Upload Leads to Remote Code Execution

During an assessment, I identified a severe security vulnerability within Open eClass, an e-learning platform extensively utilized across educational institutions, notably within Greece, where it is deployed by virtually all Greek Universities and educational entities. Open eClass, developed by GUnet (Greek Universities Network), is instrumental in delivering asynchronous e-learning services. The vulnerability, cataloged under CVE-2024-26503, involves an unrestricted file upload flaw that enables remote code execution (RCE), impacting versions 3.15 and earlier of the platform. This critical security lapse presents a significant risk, potentially allowing unauthorized access and control over the system, thereby compromising the integrity and security of the educational infrastructure. Affected Versions: ●   version <=  3.15 CVSSv3.1 Base Score: 9.1 ( Critical ) CVSSv3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H Exploitation Guide The vulnerability can be e...

Chamilo LMS: CVE-2024-27524 & CVE-2024-27525

CVE-2024-27524:  Stored XSS in tickets Severity:  High  (Base Score  7.1 ) CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H   Mitigation: Upgrade to Chamilo LMS 1.11.28 and above. Patch:  https://github.com/chamilo/chamilo-lms/commit/53275c152275958b33a1f87a21843daa52fb543a CVE-2024-27525:  Self XSS in social network Base Score:  Medium  (Base Score  4.6 ) CVSS Vector:  CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L Mitigation: Upgrade to Chamilo LMS 1.11.28 and above. Patch:  https://github.com/chamilo/chamilo-lms/commit/a63e03ef961e7bf2dab56f4ede6f87edef40ba0c Overview This advisory covers the discovery of two vulnerabilities within Chamilo LMS, an open-source learning management system (LMS) widely used across educational institutions. These vulnerabilities—stored cross-site scripting (Stored XSS) and self-cross-site scripting (Self XSS)—pose different levels of security risks but highlight critical consideration...

How I Use Obsidian for Penetration Testing, CVE Hunting, and Studying

In the ever-evolving realm of cyber security, the tools and techniques at our disposal are as varied as the threats we aim to counteract. Among these tools, note-taking applications play a pivotal role, not just in organizing our thoughts but in streamlining our entire workflow. Today, I'm excited to share how Obsidian, a tool I embraced over two and a half years ago while preparing for my eJPT exam, has become an indispensable ally in my journey through penetration testing, CVE hunting, and continuous learning. If you're not yet familiar with Obsidian, it's a robust note-taking application that operates on a local collection of plain text Markdown files. What sets it apart is its capability to interlink ideas, forming an expansive web of knowledge that is both intuitive and comprehensive to explore. Through considerable customization, I've developed what I consider to be an ideal method for consolidating notes, insights, and projects into a unified workspace. Here'...