Server-Side Request Forgery (SSRF) is a new entry into the OWASP Top 10. As SSRF is new to the Top 10 there are only 385 Common Vulnerability and Exposures. The data shows a relatively low incidence rate with above average testing coverage and above-average Exploit and Impact potential ratings. SSRF is increasing and the severity of SSRF is becoming higher due to cloud services and the complexity of architectures.
What is Server-Side Request Forgery?
What’s the impact of SSRF?
A successful SSRF attack can often result in unauthorized actions or access to data within the organization, either in the vulnerable application itself or on other back-end systems that the application can communicate with.
In some situations, the SSRF vulnerability might allow an attacker to perform arbitrary command execution, connect to internal services like http enabled databases or perform post requests towards internal services which are not intended to be exposed. An SSRF exploit that causes connections to external third-party systems might result in malicious onward attacks that appear to originate from the organization hosting the vulnerable application.
Preventing Server-Side Request Forgery
At the Application Layer
String – Regular Expressions (Regex) can be used to ensure that data received is valid from a security point of view if the data has a simple format (token, zip code, etc.). Validation should be conducted using libraries available from the string object in other cases because of the complex formats it can take.
IP address – Ensure that the data provided has a valid IP V4 or V6 address. Ensure that the IP address provided belongs to one of the IP addresses of the identified and trusted applications. Do not permit requests to private IP addresses (which are non-routable).
Domain name – Ensure that the data provided is from a valid domain name. Ensure that the domain name provided belongs to one of the domain names of the identified and trusted applications.
URL – Do not accept complete URLs from the user because URL are difficult to validate, and the parser can be abused depending on the technology used. If network related information is really needed, only accept a valid IP address or domain name from an allow list.
Preventing SSRF at the application layer can be done by implementing a handful of protections. It is important that you do not mitigate Server-Side Request Forgery using a deny list or regular expression because attackers have a variety of weapons including payload lists, tools, and skills to bypass deny lists.
You may also consider additional measures including not deploying other relevant security services on front systems and controlling local traffic on others. Additionally, for frontends with dedicated and manageable user groups, use network encryption like a VPN on independent systems for very high protection needs.
At the Network Layer
Authentication – Services like Redis, MongoDB, Elasticsearch, and Memcached do not demand verification by default. A cybercriminal may gain access to certain services without verification, using SSRF vulnerabilities. Thus, to enforce web application security, it is desirable to allow verification whenever you can, including for local network services.
It is also recommended to restrict using network calls if it’s not required, since it can lead to sensitive information being exposed. The raw response body received from the request initiated by the server be transferred to the client.
Prevent server-side request forgery attacks
Foresite offers in-depth web application penetration tests to help organizations find the weaknesses in their web apps before attackers do. Our team of highly experienced security professionals are here to help you ensure your data and networks remain secure. Contact us today for a quote!
James Clements
After 10 years in various IT Support roles Mr. Clements made the move into IT Security starting off as a Security Analyst. As a Security Analyst Mr. Clements provided log analysis on Firewalls, Windows Servers and End Points as well as performing change requests on Firewalls. As part of his role Mr. Clements was also a technical account manager for various SME/Public Sector customers providing detailed reporting on logs, incidents as well as providing security recommendations to harden their security posture.
Mr. Clements has since made the move into Consulting and Compliance services and performs Internal and External penetration testing and vulnerability assessments as well as Web application and Mobile application testing for both authenticated and un-authenticated applications.
