In the previous part 1 and part 2, we explored different techniques for detecting and exploitation of Server-Side Request Forgery (SSRF) based on the application's scenarios. Server-Side Request Forgery (SSRF) vulnerabilities pose a formidable threat to web applications, enabling malicious actors to exploit internal network assets, potentially leading to data breaches or unauthorized access to both the application and its underlying infrastructures. Within this discourse, we shall embark upon a profound exploration of potent SSRF mitigation techniques, designed to bolster the security of your applications across diverse scenarios – securing internal pages, and network URLs, handling external URL requests, and ensuring proper protocol/schema use. Additionally, we will offer specific advice for safeguarding cloud-hosted applications on platforms like AWS, Azure, and Google.
Constructing Resilient Applications: Scenarios and Strategies
In the realm of application development, consider these situations:
Securing Internal Pages Access Architecture:
- Enlist a secure URL parsing library to meticulously extract schema, hostname, URL path, and query string.
- Employ judicious input validation even though data are encoded or in different formats, as each parameter undergoes rigorous scrutiny to eliminate potential vulnerabilities.
- In the case of dynamic generation of URL, only append the path associated with the specific page into the designated host configuration, while excluding extraneous parameters.
- Unleash the power of map path functions to transform relative URLs into absolute URLs.
- Validate input for URL formats, scrutinizing binary characters relevant to localhost URLs, employing techniques such as CIDR, dots, decimal/octal/hexadecimal, and domain parser confusion attacks.
Securing Internal URL Access Architecture:
- Keep an updated list of internal IPs and domains, using it for whitelist/blacklist approaches to control access.
- Enlist a secure URL parsing library to meticulously extract schema, hostname, URL path, and query string along with strict input validation on hostname and IPs.
- Employ a local DNS resolver for converting DNS requests.
- Validate destination IP against whitelist/blacklist IPs before granting access.
- Handle encodings and null characters securely.
- Avoid taking the internal application's IP address as user input; manage it from the backend.
- Resolve DNS to A and AAAA IPs, validating them.
- Make a single DNS call and use the IP for subsequent calls, preventing DNS rebinding attacks (time to check vs time to use).
Securing External URL Access: Few applications fetch or send data to an external domain through webhooks or external calls for image rendering, metadata processing, etc functionalities.
- Permit access only to public IP ranges and limit access from private IP ranges.
- Ensure that the backend web client does not reveal any sensitive information in the HTTP request’s headers such as user-agent, cookies, etc.
- Do not throw any errors when IPs or URLs cannot be reached.
- Follow guidelines for internal URL access architecture for validating input against IPs and domains.
- Whitelisting of external URLs or domains would be a better approach.
Securing Protocol/Schema Usage in the Application:
- Allow only HTTPS access.
- Explicitly disable undesired URL schemas like gopher, sftp, file, dict, ftp, etc.
- Ensure your URL parsing tool disables these schemas as well.
Securing Metadata of the Cloud hosted application:
- AWS - Disable IMDSv1. Only enable IMDSv2 if required.
- IMDSv2 - Token is being used as an authorization header. The value of the token is collected from the PUT request and the same token value is passed in the next request used as an authorization header to get the metadata details.
- TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
- curl http://169.254.169.254/latest/meta-data/profile -H "X-aws-ec2-metadata-token: $TOKEN"
- Azure – By default “Metadata"="true" header is passed as a request header in the HTTP request to get the metadata details. (ref: - https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service?tabs=windows)
- Google – By default “Metadata-Flavor: Google” header is passed as a request header in the metadata HTTP request to get the metadata details. (ref: https://cloud.google.com/compute/docs/metadata/querying-metadata)
Strengthening Defences: Extra Layers of Security
Along with the above techniques, network layer and host-based firewalls can be utilized as an additional layer of protection that complements application layer protection. Also, enable authentication/access control for internal applications to thwart unauthorized access.
By implementing these Server-Side Request Forgery (SSRF) mitigation techniques, you can significantly reduce the risk of SSRF attacks and protect your applications from potential vulnerabilities. It is crucial to adopt a layered approach to security, combining proper input validation, access controls, and secure configurations to ensure the integrity and confidentiality of your application’s resources.
Article by Amish Shah