SSRF and XSPA with Remediation
Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing.
SSRF exists when the server, as part of one of its features, fetches data or queries from internal or external resource. The key is that this request includes a value that the attacker can manipulate, potentially allowing the attacker to completely change the request being performed by the server.
Using SSRF Vulnerability the attacker may perform following Actions:
- Perform banner grabbing
- Enumerate and attack services that are running on these hosts
- Abuse the trust relationship between the vulnerable server and others.
- Bypass IP whitelisting.
- Scan the internal network to which the server is connected.
- Read files from the web server.
- View Status Pages and interact with APIs as the web server.
- Retrieve sensitive information.
In contrast to a thin client, a fat or rich client is a computer with many locally stored programs and resources and little dependence on network resources. By further comparison, a fat client balances program dependence locally with a hard/connected drive and device resources, while a thin client balances program dependence with a network server’s hard/connected drive and device resources.
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:
This 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.
A Docker is made up of the following components.
For example:
Here, the server will fetch the contents of the /admin URL and return it to the user.
Now of course, the attacker could just visit the /admin URL directly. But the administrative functionality is ordinarily accessible only to suitable authenticated users. So, an attacker who simply visits the URL directly won't see anything of interest. However, when the request to the /admin URL comes from the local machine itself, the normal access controls are bypassed. The application grants full access to the administrative functionality, because the request appears to originate from a trusted location.
Remediation.
1. Whitelists and DNS resolution
To prevent SSRF vulnerabilities in your web applications, it is strongly advised to use a whitelist of allowed domains and protocols from where the web server can fetch remote resources.
2. Disable unwanted protocols,
such as file:///, dict:// or ftp://.
3. Response Handling
Validating responses received from remote resources on the server side is the most basic mitigation.
XSPA
An application is vulnerable to Cross Site Port Attacks, if the application processes user supplied URLs and does not verify/sanitize the back-end response received from remote servers before sending it back to the client.
An attacker can send crafted queries to a vulnerable web application to proxy attacks to external Internet facing servers, intranet devices and the web server itself using the advertised functionality of the vulnerable web application. The responses, in certain cases, can be studied to identify service availability (port status, banners etc.) and even fetch data from remote services in unconventional ways.
The attacks that can be launched using this vulnerability.
- Port Scanning remote Internet facing servers, intranet devices and the local web server itself. Banner grabbing is also possible in some cases.
- Exploiting vulnerable programs running on the Intranet or on the local web server
- Attacking internal/external web applications that are vulnerable to GET parameter-based vulnerabilities (SQLi via URL, parameter manipulation etc.)
- Fingerprinting intranet web applications using standard application default files & behaviour
- Reading local web server files using the file:/// protocol handler.
For Example:
The below screenshot shows the port being opened and closed, but it shows the result without exposing the attackers IP on server logs. It also reveals the backend service running on SSH.
Remediation.
- Unauthorized URLs access should be restricted.
- Restrict connectivity to the internal ports.
- Blacklist strange IP addresses.
- Disable unwanted protocols and services
- You can block your ports using firewall for better security.
