Server Side Request Forgery

Description

SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL).

Remediation

Basic blacklisting and regular expressions are a bad approach to mitigating SSRF.

The correct ways to prevent SSRF are:

• Whitelisting and DNS resolution: whitelist the hostname (DNS name) or IP address that your application needs to access. (Best method to prevent SSRF))
• Response handling: To prevent response data from leaking to the attacker, you must ensure that the received response is as expected. Under no circumstances should the raw response body from the request sent by the server be delivered to the client.
• Disabling unused URL schemas: if your application only uses HTTP or HTTPS to make requests, allow only these URL schemas. Once unused URL schemas are disabled, the attacker will be unable to exploit the web application to make requests using potentially dangerous schemas such as file:///, dict://, ftp://, and gopher://.
• Authentication on internal services.

GraphQL Specific

Apollo

To mitigate Server Side Request Forgery (SSRF) in the Apollo framework engine, ensure that any user-supplied URLs are validated against a strict whitelist of allowed domains and protocols. Implement proper input validation and sanitization to reject malicious or unexpected input. Additionally, consider using a server-side proxy with an allowlist to restrict outbound traffic to trusted destinations only. Employ least privilege principles by restricting the server's network access, and regularly audit and monitor outgoing requests to detect and respond to any SSRF attempts.

Yoga

To mitigate Server Side Request Forgery (SSRF) in the Yoga framework engine, ensure that any functionality allowing for URL fetching is restricted to trusted domains. Implement strict input validation, whitelist allowable protocols and domains, and consider using a server-side proxy with an allowlist to further restrict outbound requests. Additionally, avoid disclosing sensitive information in error messages and regularly audit your code for potential SSRF vulnerabilities.

Awsappsync

To mitigate Server Side Request Forgery (SSRF) in AWS AppSync, ensure that your resolvers do not accept arbitrary URLs from client-side input for data fetching. Implement strict input validation to accept only well-defined, whitelisted external endpoints. Use AWS IAM roles and policies to enforce least privilege access, and consider using VPC endpoints for services to keep traffic within the AWS network. Regularly review and update your security groups and network ACLs to restrict outbound traffic. Additionally, enable logging and monitoring to detect and respond to any SSRF attempts promptly.

Graphqlgo

To mitigate Server Side Request Forgery (SSRF) in a GraphQL Go framework engine, validate and sanitize all user-supplied URLs and inputs. Implement strict allowlists for external services that can be accessed, and use a dedicated HTTP client with limited permissions. Additionally, consider employing network-level controls to restrict outbound traffic to trusted endpoints only.

Graphqlruby

To mitigate Server Side Request Forgery (SSRF) in a GraphQL Ruby framework, ensure that any user-supplied URLs or input used in network requests are validated against a whitelist of allowed domains and protocols. Additionally, employ least privilege by restricting the server's network access to only necessary external services, and consider using a dedicated library or service for fetching URLs that has built-in SSRF protection. Regularly review and update the whitelist and security policies to adapt to new threats.

Hasura

To mitigate Server Side Request Forgery (SSRF) in Hasura, ensure that any user-supplied URLs for webhooks or remote schemas are validated against a whitelist of allowed domains and protocols. Additionally, employ network policies to restrict the Hasura engine's outbound traffic to known safe destinations, and consider using a server-side proxy to handle external requests, which can provide an additional layer of filtering and access control.

REST Specific

Asp_net

To mitigate SSRF vulnerabilities in ASP.NET applications, validate all user-supplied URLs to ensure they point to allowed destinations. Implement a whitelist of approved services and reject any requests not matching the criteria. Additionally, use built-in .NET classes such as 'HttpClient' with proper URL validation, and avoid concatenating user input in URLs. Employ least privilege principles by restricting the server's ability to make outbound requests to only necessary services and ports.

Ruby_on_rails

In Ruby on Rails, mitigate SSRF by validating and sanitizing user input, ensuring URLs are from an allowed list of hosts and schemes. Employ the 'uri' standard library to parse and validate URLs, and consider using a dedicated gem like 'ssrf_filter' for enhanced protection. Additionally, apply network-level controls to restrict outbound traffic to trusted destinations.

Next_js

In Next.js applications, mitigate SSRF by validating and sanitizing all user inputs, implementing strict URL allowlists, and using built-in server-side functions like fetch with caution. Ensure that any URLs constructed from user inputs are checked against a predetermined list of allowed destinations. Additionally, consider using network-level controls to restrict the server's ability to initiate requests to untrusted hosts.

Laravel

In Laravel, mitigate SSRF by validating and sanitizing all user inputs, especially URL parameters. Use Laravel's built-in validation rules, such as 'url' or custom regex patterns, to ensure only allowed URLs are processed. Additionally, restrict outgoing requests to a predefined list of trusted domains and employ the 'GuzzleHttp' client with caution, setting appropriate timeouts and redirect limits.

Express_js

To mitigate SSRF vulnerabilities in an Express.js application, ensure that all user-supplied URLs are validated against a whitelist of allowed domains and paths. Implement strict input validation, use a dedicated library for URL parsing, and avoid passing user-controlled data to networking functions. Additionally, consider using a server-side proxy with an allowlist to restrict outbound traffic to trusted destinations only.

Django

In Django, to mitigate Server Side Request Forgery (SSRF) vulnerabilities, ensure that any function making external requests validates and sanitizes the URLs provided by users. Use Django's URLValidator for initial validation. Additionally, restrict the outgoing requests to a predefined whitelist of allowed domains and schemes, and consider implementing network-level firewall rules that limit the destinations your application can interact with. Always apply the principle of least privilege, granting minimal access necessary for the application to function.

Symfony

In Symfony, to mitigate Server Side Request Forgery (SSRF) vulnerabilities, ensure that any functionality allowing users to supply URLs for fetching resources implements strict input validation. Use Symfony's built-in validation constraints to whitelist allowed protocols and domains, and avoid disclosing sensitive information through error messages. Additionally, consider using the HttpClient component with a preconfigured base URI and limited permissions to further restrict outbound requests to trusted destinations.

Spring_boot

In Spring Boot applications, to mitigate SSRF vulnerabilities, validate and sanitize all user-supplied URLs before using them to initiate a request. Implement a strict allowlist of allowed domains and schemes, and use a dedicated library for URL parsing to avoid bypasses. Additionally, configure your HTTP client to resolve DNS names using a trusted server and to disallow interactions with internal network resources.

Flask

To mitigate SSRF vulnerabilities in a Flask application, ensure that any user-supplied URLs are validated against a whitelist of allowed domains and schemes. Additionally, use the 'requests' library with caution, setting a timeout and explicitly disabling redirects. Employ network-level controls to restrict outbound traffic to trusted services, and consider using a server-side proxy to handle external requests. Always apply the principle of least privilege to minimize the potential impact of an SSRF attack.

Nuxt

In Nuxt.js applications, to mitigate SSRF vulnerabilities, ensure that all user-supplied URLs are validated against a strict whitelist of allowed domains and protocols. Additionally, employ server-side input validation to reject malformed URLs and unexpected input. Use built-in Nuxt.js or server features to set timeouts and limit redirects on outgoing requests. Avoid disclosing sensitive information through error messages and consider implementing a proxy to handle outgoing requests, which can provide an additional layer of control and monitoring.

Fastapi

In FastAPI, to mitigate SSRF vulnerabilities, validate all user-supplied URLs before using them to make a request. Implement a whitelist of allowed domains and ensure that only URLs starting with these domains are accepted. Additionally, use built-in FastAPI dependencies to restrict input and avoid revealing sensitive information through error messages. Regularly update FastAPI and its dependencies to incorporate security fixes.

Configuration

Identifier: request_forgery/ssrf

Examples

Ignore this check

checks:
  request_forgery/ssrf:
    skip: true

Score

• Escape Severity: HIGH

Compliance

• OWASP: API7:2023

• pci: 6.5.9

• gdpr: Article-32

• soc2: CC1

• psd2: Article-95

• iso27001: A.14.2

• nist: SP800-53

• fedramp: SI-10

Classification

• CWE: 918

Score

• CVSS_VECTOR: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
• CVSS_SCORE: 7.3