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 exploited

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'

CTF: Portfolio Walkthrough

Scenario A passionate web developer recently launched his personal portfolio website, proudly displaying his projects and sharing his thoughts through a vibrant blog. His focus on design and functionality has left glaring security holes. As his blog gains popularity, you, a skilled hacker, spot the perfect target. Your mission is clear: exploit the vulnerabilities, compromise his site, and expose his negligence. Every weakness is an opportunity, every oversight a path to control. In this CTF challenge, you are the hacker. Uncover the flaws, break through the defenses, and leave your mark on the developer’s digital pride. Welcome to "Portfolio CTF" The game is on. Good luck! You can download the OVA for the Portfolio CTF from this  link SPOILER ALERT: Do not read further if you intend to solve the CTF challenge on your own. The write-up follows below. Introduction I created this Capture The Flag (CTF) machine with dual objectives: to provide a comprehensive training ground fo