> For the complete documentation index, see [llms.txt](https://kero0x1.gitbook.io/general/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kero0x1.gitbook.io/general/web-vulnerabilities/ssrf.md).

# SSRF

Today i will Explain what is SSRF in simple way  :

* It means Server-Side Request Forgery (SSRF); it's a server-side vulnerability that allows an attacker to read or update internal resources on the server.
* An attacker might cause the organization's server to establish a connection with internal servers within the organization's infrastructure.
* The attacker may also be able to force the server to connect to arbitrary external servers, potentially leaking sensitive data such as authorization credentials."
* Note: If a request is made to the server but it cannot access internal resources, it does not qualify as SSRF."

### how This Vuln happen :

1. A hacker requests a public server to access files on the internal server or system, such as localhost, similar to Facebook
2. The public server then requests the internal server to access its internal resources.
3. The internal server at Facebook allows the public server to access its internal resources.
4. The public server responds to the hacker with internal resources.
5. Red indicates a scenario without SSRF, while green indicates a scenario with SSRF.

![](https://2140186435-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpoPpsF6DyQtOrXy70rxC%2Fuploads%2FoEWLZDL3ZRHB7D0Tvcs2%2FUntitled.png?alt=media\&token=209334f3-1935-4ff9-a908-b45c9e08209b)![](https://2140186435-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpoPpsF6DyQtOrXy70rxC%2Fuploads%2Fbpv3NiD8MtuJieg3qH4u%2F2.png?alt=media\&token=9c6c8b91-eeda-480d-9dc9-fde0bc6e85e6)

###

### How can Server Request another server :

1. when we put link like Facebook in google translate or any Application like this :![](https://2140186435-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpoPpsF6DyQtOrXy70rxC%2Fuploads%2Fuj8wMI7nJ07zuuuUhQaZ%2FUntitled.png?alt=media\&token=10574dfe-676c-4df4-bc71-8961f3133fb2)
2. In this scenario, the Telegram server sends a request to the Facebook server. We can observe this communication in Facebook's logs, including the IP address and referrer information.
3. Is this a vulnerability? No, it's a feature designed to facilitate easier connections between applications.
4. It becomes a vulnerability when an attacker can read or modify files or access administrative functions.

#### 😃External server interaction (HTTP) :

1. Allowing attackers to use a vulnerable server to request external servers can lead to a common vulnerability known as Cross-Site Port Scanning (XSPS).
2. Attackers can use a vulnerable server to perform port scans on common ports for Facebook, such as [https://www.facebook.com:80-22-338](https://kero0x1.gitbook.io/general/web-vulnerabilities/https:/www.facebook.com:80-22-338).
3. This action doesn't constitute SSRF but can damage a company's reputation by creating a low-security perception.

#### 🤑External server interaction (DNS) :

1. it’s not be SSRF ,, just make low reputation of company
2. happen because of ::
   1. when request normal website it happen immediately to resolve name to IP
   2. Reverse Proxy using (X-Forwarded-For) header
3. happen with use **Burp collaborator or plugin** **Collaborator Everywhere ⇒** it use a lot of headers and when interaction happen it alert you

## 😃**Common  SSRF attacks :**

1. **SSRF attacks against the server itself :**
   1. here **attacker make an HTTP request to the local host of server 127.0.0.1**
   2. if it success then attacker can do many things like use admin Functions to add or delete users
2. **SSRF attacks against other back-end systems :**
   1. the application server is able to interact with back-end systems that are not directly reachable by users.
   2. these systems often **have non-routable private IP addresses.**
   3. In many cases, internal back-end systems contain s**ensitive functionality can be accessed without authentication** by anyone who is able to interact with the systems.
3. **Bypassing SSRF filters via open redirection :**
   * sometimes possible to bypass defenses by exploiting an open redirection vulnerability.

#### 🤩 Blind SSRF and **How to find and exploit** :

* arise when an **application can be induced to issue a back-end HTTP request** to the URL, but the **response not returned from back-end request to front-end response**.
* **Impact :**

  * lower than fully informed SSRF vulnerabilities because of their one-way nature

  * cannot be trivially exploited to retrieve sensitive data from back-end systems, some times can get RCE

  > **How To Find Blind SSRF :**

  * using **out-of-band techniques** ,,this involves attempting to **trigger an HTTP request to an external system** th**at you control, and monitoring** for network interactions with that system.
  * use [Burp Collaborator](https://portswigger.net/burp/documentation/desktop/tools/collaborator) to **generate unique domain names, send these in payloads to the application**, and mon**itor for any interaction with those domains**. If an
  * if we get incoming HTTP request is observed coming from the application, then it is vulnerable to SSRF
  * but you cannot view the response from the back-end request, the behavior can't be used to explore content on systems to server we reach
  * but **it can still be leveraged to probe for other vulnerabilities on the server** itself or on other back-end systems. like scan internal IP address space, sending payloads designed to detect well-known vulnerabilities.

#### Filters and how can we bypass :

* Some applications block input containing hostnames like `127.0.0.1` and `localhost`, or sensitive URLs like `/admin`. we can bypass by
  1. Using an alternative IP representation of `127.0.0.1`, such as `2130706433`, `017700000001`, or `127.1`.
  2. Registering your own domain name that resolves to `127.0.0.1`. You can use `spoofed.burpcollaborator.net` for this purpose.
  3. Obfuscating blocked strings using URL encoding or case variation.
  4. Providing a URL that you control, which subsequently redirects to the target URL. Try using different redirect codes, as well as different protocols for the target URL. For example, switching from an `http:` to `https:` URL during the redirect has been shown to bypass some anti-SSRF filters.
* Some applications only allow input that matches, begins with, or contains, a whitelist of permitted values. we can exploiting inconsistencies in URL parsing.
  * **تحتوي عناوين URL في بعض الأحيان على عدد من الميزات التي قد يتم التغاضي عنها عند تنفيذ التحليل المخصص والتحقق من صحة عناوين URL:**
  * try to embed credentials in a URL before the hostname, using `@` : `https://expected-host:fakepassword@evil-host`
  * You can use the `#` character to skip the next in url For example:`https://evil-host#expected-host`
    1. when someone clicks on this URL, browser will load the page and automatically scroll to the `expected-host`

3. try leverage the DNS to input DNS name that you control(server). For example:`https://expected-host.evil-host`