Hello Hacker!!
I am excited to announce that i am sharing my learnings, learning together, hunting, growing our skills and knowledge, and making a small contribution to the community!.
Today’s topic is server-side Request Forgery(SSRF), also known as SSRF!
Let’s dive into the topic.
SSRF
Server-side Request Forgery(SSRF) is a web application vulnerability that allows attacker to make unauthorized requests from the server to other internal or external systems. The attacker exploit the trust that the server places in its own request and allows attackers to manipulate the server into performing unintended actions.
The attacker can craft a malicious request with a URL or IP address that points to an internal system that should not be accessible from the outside, such as a database server, network appliance or backend application.
Types of SSRF Vulnerabilities
1. Basic SSRF
Basic SSRF involves exploiting a web application’s ability to make HTTP requests to arbitrary destinations. Attackers can forge requests to internal services or external systems, often leading to unauthorized data access.
2. Blind SSRF
Blind SSRF occurs when an attacker can trigger SSRF but doesn’t receive the response directly. Instead, they rely on other techniques, like out-of-band (OOB) requests, to confirm the attack’s success. This makes detection and mitigation more challenging.
3. Advanced SSRF Techniques
Advanced SSRF techniques involve complex manipulation of input parameters and payloads. Attackers may use techniques like request smuggling or encoding to obfuscate their malicious requests, making them harder to detect.
Server-Side Request Forgery, also known as SSRF refers to an attack which lets an attacker send crafted requests from the back-end server of a vulnerable web application.
SSRF vulnerabilities occur when the attacker has full or partial control of the request sent by the web application. If the vulnerable web application processes the user-supplied URLs then the application is vulnerable to SSRF attacks.
Impact of a Server Side Request Forgery Attack
If the user-supplied URL is processed and the back-end response is not sanitised then the attack can lead to several impacts like:
- Port scanning: A user can scan the port of a particular website through the vulnerable web application which is processing the user’s URL.
- Fingerprinting intranet.
- Attacking internal or external web applications.
- Reading local web server files using the file:/// protocol handler.
- In some cases, a successful SSRF attack can even lead to Remote Code Execution (RCE).
SSRF attack against the server itself
In an SSRF attack against the server itself, the attacker induces the application to make an HTTP request back to the server that is hosting the application, via its loopback network interface. This will typically involve supplying a URL with a hostname like 127.0.0.1 (a reserved IP address that points to the loopback adapter) or localhost (a commonly used name for the same adapter)
For example, consider a shopping application that lets the user view whether an item is in stock in a particular store. To provide the stock information, the application must query various back-end REST APIs, dependent on the product and store in question. The function is implemented by passing the URL to the relevant back-end API endpoint via a front-end HTTP request. So when a user views the stock status for an item, their browser makes a request like this:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26stThis causes the server to make a request to the specified URL, retrieve the stock status, and return this to the user.
In this situation, an attacker can modify the request to specify a URL local to the server itself. For example:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://localhost/adminHere, the server will fetch the contents of the /admin URL and return it to the user. The application grants full access to the administrative functionality, because the request appears to originate from a trusted location.
SSRF attacks against other back-end systems
Another type of trust relationship that often arises with server-side request forgery is where the application server is able to interact with other back-end systems that are not directly reachable by users. These systems often have non-routable private IP addresses. Since the back-end systems are normally protected by the network topology, they often have a weaker security posture. In many cases, internal back-end systems contain sensitive functionality that can be accessed without authentication by anyone who is able to interact with the systems.
In the preceding example, suppose there is an administrative interface at the back-end URL https://192.168.0.68/admin. Here, an attacker can exploit the SSRF vulnerability to access the administrative interface by submitting the following request:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://192.168.0.68/adminSSRF with blacklist-based input filters
Some applications block input containing hostnames like 127.0.0.1 and localhost, or sensitive URLs like /admin. In this situation, you can often circumvent the filter using various techniques:
- Using an alternative IP representation of 127.0.0.1, such as 2130706433, 017700000001, or 127.1.
- Registering your own domain name that resolves to 127.0.0.1. You can use spoofed.burpcollaborator.net for this purpose.
- Obfuscating blocked strings using URL encoding or case variation.
- 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.
SSRF with whitelist-based input filters
Some applications only allow input that matches, begins with, or contains, a whitelist of permitted values. In this situation, you can sometimes circumvent the filter by exploiting inconsistencies in URL parsing.
The URL specification contains a number of features that are liable to be overlooked when implementing ad hoc parsing and validation of URLs:
- You can embed credentials in a URL before the hostname, using the @ character. For example:
https://expected-host:fakepassword@evil-host- You can use the # character to indicate a URL fragment. For example:
https://evil-host#expected-host- You can leverage the DNS naming hierarchy to place required input into a fully-qualified DNS name that you control. For example:
https://expected-host.evil-hostRemember that SSRF attacks are constantly evolving and it’s important to keep up to date with the latest attack techniques and best practices for mitigating SSRF risks.
Cloud Metadata: https://gist.github.com/BuffaloWill/fa96693af67e3a3dd3fb
Thank You!!
@theUnixe
