📌
Software Security
  • README
  • Prerequisites
    • Prerequisites
  • Introduction
    • Cyber security principles
    • Basic web concepts
      • HTTP
      • JavaScript
      • Cookies
      • SQL
      • DOM
      • APIs and the multitier architecture
    • Basic browser security concepts
      • Same-Origin Policy (SOP)
      • Cross-Origin Resource Sharing (CORS)
      • Cookies
      • Tracking
    • Basic security concepts
      • Hashing
  • Access Control: Basics
    • Authentication
      • Passwords
      • Password managers
      • Attacking passwords - online
      • Attacking passwords - offline
    • Authorization
      • Insecure direct object references
    • Session Management
    • CSRF
      • CSRF: why & how it works
      • Protecting against CSRF attacks
    • SSRF
      • SSRF: how it works and how we can protect against it
  • Access Control: Advanced
    • Authentication
      • Federation
      • Alternative authentication mechanisms
      • FIDO2 and WebAuthn
  • Injection attacks
    • Injection attacks
    • SQL Injection
    • Command Injection
    • Cross-site scripting
      • Input validation
      • Context sensitive output encoding
      • About the HttpOnly flag
      • Content Security Policy
    • Subresource integrity
    • Sandboxing
  • HTTPS
    • HTTPS
    • Introduction to cryptography
    • PKI
    • Setting up HTTPS
    • References
  • HTTP Headers for security
    • HTTP Headers
  • Threat Modeling
    • Threat modeling introduction
    • Threat modeling basics
    • Inspiration for threats
  • Bringing it all together
    • A comprehensive overview of controls
Powered by GitBook
On this page
  • Why and how does SSRF work?
  • How can we protect against SSRF?
  • Source attribution

Was this helpful?

  1. Access Control: Basics
  2. SSRF

SSRF: how it works and how we can protect against it

PreviousSSRFNextAuthentication

Last updated 1 year ago

Was this helpful?

Why and how does SSRF work?

An attacker can usually only reach applications that are exposed to the Internet. Applications running locally on the server (i.e. bound to the localhost interface - 127.0.0.1), or non-internet exposed applications running in the same network as the server are usually not reachable to the attacker. However, through a successful server-side request forgery attack the attacker can trick the server into executing requests and thereby circumvent these restrictions. Indeed, since these requests are initiated by the server, they are treated with much more trust.

Visually, the attack looks as follows:

Examples of requests to applications that are not intended to be exposed but that are likely to succeed when they are executed from the trusted server:

  • requests to the localhost interfaces;

  • requests to other applications on the same private network;

  • requests to servers that have IP filtering enabled.

How can we protect against SSRF?

The first defense would of course be to not have any back-end functionality in place that requires calling an external URL based on user input.

However, if such functionality is required, the following defense mechanisms should be deployed:

  • allowlist + input validation: ensure that the url that is called based on user input is part of a allowlist;

  • allowlist + network layer protection: ensure that only allowlisted urls can be reached via the network (e.g. through firewall configurations);

  • blocklist: if a allowlist approach is infeasible, ensure that there is a blocklist which at least comprises the localhost interface and all private internet address ranges (such as 192.168.0.0). This list must be completed with all internally used domain names if the blocklist check occurs at application level (since the DNS translation happens after the blocklist has been checked).

Source attribution

Some parts of this page are based on and by OWASP, which is licensed under .

Server Side Request Forgery
Server Side Request Forgery Prevention
FLOSS