We are all aware of what phishing is. Think of phishing as a server that is not the client or victim. Server-Side Request Forgery (SSRF), is the simple act of tampering with requests that are submitted to the server in order to extract important data from them.
The only vulnerability type that has its own category in the OWASP Top 10 2021 list is server-side request forgery (SSRF). SSRF was used as one of the break-in tactics in a number of significant cybersecurity breaches in recent years, including the Capital One and MS Exchange assaults.
What exactly is Server-Side Request Forgery (SSRF)
?
A server-site attack referred to as SSRF causes the application’s back-end server to reveal sensitive data. In server site request forgery, attackers transmit malicious packets to any web server that is accessible via the Internet, and this web server then sends the attacker’s malicious packets to the back-end server that is connected to the internal network.
An attacker can use a vulnerable application’s back-end server to deliver specially crafted requests due to SSRF flaws. SSRF assaults are frequently used by criminals to attack internal systems protected by firewalls and inaccessible from the outside network. Additionally, an attacker can use SSRF to access services accessible via the server’s loopback interface (127.0.0.1).
How does it impact us?
If an SSRF attack is successful, it may lead to unauthorized data access or activities within the business, either on the susceptible application’s own back-end systems or on other back-end systems that the application can interact with. The SSRF vulnerability may, in some circumstances, enable an attacker to execute any command.
Some impacts are but are not limited to Data Exposure, Reconnaissance, Port Scans or Cross Site Port Attacks (XSPA), Denial of Service (DoS), and Remote Code Execution (RCE).
Server-Side Request Forgery (SSRF) attack types
SSRF attacks frequently take advantage of a trust relationship, either between the server and other back-end systems or within the server itself (referred to as a server SSRF attack) (known back-end SSRF attack).
SSRF server attacks
Attackers use a procedure in which a browser or other client system directly accesses a URL on the server in a server SSRF attack.
The attacker will swap out the original URL for a different one, frequently utilizing the IP 127.0.0.1 or the hostname “localhost,” which refers to the server’s local file system.
The attacker discovers a file path to sensitive data under this hostname.
For example, on a hacker website, the web application queries its server for current ASPIA_payloads to display. It can do this using a REST API, passing a URL with an API request from the user’s browser to the server. The request might look like this:
POST /hackdb/ASPIA_payloads HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 113 hackdbApi=http://data.hackerapp.com:8080/hackdb/ASPIA_Payloads/check%3FcurrentDateTime%3D6%26Payloads%3D1
The attacker can change this to the following:
hackdbApi=http://localhost/admin
This will display the contents of the /admin folder to the attacker.
Back-End SSRF attacks
When a server has a trustworthy relationship with a back-end component, this is another kind of SSRF. An attacker can fake a request and obtain access to sensitive data or carry out illegal activities if the server connecting to that component has full access permissions. Since back-end components are considered safe inside the network perimeter, their security is frequently weak.
Just like the previous API request, the attacker may substitute the API call with:
hackdbApi=http://192.168.10.5/admin
The attacker can similarly get access and examine the directory’s contents if the server connects to a back-end component at IP address 192.168.10.5 and is permitted to access the /admin directory on that component’s file system.
Mitigating Server-Side Request Forgery (SSRF)
DNS Resolution and Whitelisting
Whitelisting the IP addresses or DNS names that your application needs access to is a good strategy for preventing SSRF. The use of a blacklist should only be made when a whitelist method is unsuitable. Effective user input authorization is critical. Don’t, for instance, allow requests from private IP addresses (which are non-routable).
Response Management
Make sure the response obtained complies with expectations in order to prevent response information from reaching the cybercriminal. Under no circumstances should the client see the server’s initial request’s raw response body.
Unused URL Schemas must be disabled
Allow just these URL types if your application entirely relies on HTTPS or HTTP to initiate queries. You can prevent attackers from using the application to send requests with potentially destructive schemas, such as dict:/, file:/, and gopher:/, by deactivating unnecessary URL schemas.
Integrity Checking for Internal Services
Redis, MongoDB, Elasticsearch, and Memcached are examples of services that do not require verification by default. Using SSRF vulnerabilities, a cybercriminal might access some services without being verified. Therefore, it is preferable to allow verification whenever you can, especially for local network services, to ensure web application security.
Conclusion:
The necessary web page has been redirected to some other websites as a result of the Server Side Request Forgery attack being made from the server side.
Allowing only certain subdomains of the necessary web page and then whitelisting the other web pages that are not in use will help prevent these types of attacks.
ASPIA offers an innovative cybersecurity platform for security workflow automation and orchestration which covers managing the complete OWASP top 10 2021 checklist of vulnerabilities contact us today to streamline the existing security workflows.
