Skip to main content

Partial SSRF

Description​

Partial Server-Side Request Forgery occurs when the attacker can manipulate a request made by the server.

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) vulnerabilities in the Apollo framework engine, ensure that all user-supplied URLs are validated against a strict whitelist of allowed domains and protocols. Additionally, implement server-side checks to verify that the response received matches expected criteria before processing it. If possible, use a dedicated service for fetching external resources that can enforce access control and auditing. Limit the response size and timeout to minimize the impact of any potential SSRF attacks. Regularly review and update the whitelist to maintain a strong security posture.

Yoga

To mitigate Server-Side Request Forgery (SSRF) vulnerabilities in the Yoga framework engine, ensure that all user-supplied URLs are validated against a strict whitelist of allowed domains and protocols. Additionally, implement server-side checks to verify that the response from the external service is expected and benign. If possible, use a server-side proxy with a static IP to control outgoing traffic and monitor for any unusual patterns or requests. Always apply the principle of least privilege by restricting the URLs to which the application can send requests, and consider using an allowlist for URL schemas, ports, and methods if applicable.

Awsappsync

To mitigate Server-Side Request Forgery (SSRF) vulnerabilities in AWS AppSync, ensure that the service is configured to only allow access to trusted endpoints. Implement strict validation on user-supplied URLs, including schema validation to only permit https schemes. Use AWS IAM roles and policies to enforce least privilege access control, and regularly audit your AppSync resolvers and data sources for any overly permissive settings. Additionally, consider using VPC endpoints for services that support them to keep traffic within the AWS network.

Graphqlgo

To mitigate Partial Server-Side Request Forgery (SSRF) vulnerabilities in a GraphQL Go framework engine, validate and sanitize all user-supplied URL inputs to ensure they point to allowed destinations. Implement strict allowlists for external services that can be interacted with, and employ network-level controls to restrict outbound traffic to trusted endpoints. Additionally, consider using a dedicated SSRF prevention library or functionality within the framework, if available.

Graphqlruby

To mitigate Partial Server-Side Request Forgery (SSRF) vulnerabilities in a GraphQL Ruby framework engine, ensure that any URL inputs are validated against a strict whitelist of allowed domains and schemes. Additionally, employ server-side checks to verify that the resolved IP addresses of the URLs do not point to internal resources. Implement network-level restrictions to prevent the GraphQL server from making requests to internal infrastructure. Use the 'graphql-pro' gem which includes SSRF protection features, and regularly update all dependencies to incorporate security fixes.

Hasura

To mitigate Server-Side Request Forgery (SSRF) vulnerabilities in the Hasura framework, ensure that any user-supplied URLs are validated against a strict whitelist of allowed domains and protocols. Additionally, employ network-level controls to restrict the Hasura engine's ability to initiate requests to unintended internal services. Consider using a combination of URL parsing libraries to validate and sanitize input, and apply the principle of least privilege by limiting the outbound network capabilities of the server running Hasura.

REST Specific​

Asp_net

In ASP.NET, mitigate partial SSRF vulnerabilities by validating and sanitizing all user inputs, enforcing strict URL schemas, using allowlists for allowable destinations, and employing least privilege principles for server requests. Additionally, consider implementing network-level restrictions and monitoring outbound traffic for unusual patterns.

Ruby_on_rails

In Ruby on Rails, mitigate partial SSRF by validating and sanitizing user input, enforcing strict URL schemas, using a whitelist for allowed domains, and employing the 'resolv-replace' library to prevent DNS rebinding attacks.

Next_js

To mitigate partial SSRF vulnerabilities in a Next.js application, validate and sanitize all user inputs rigorously. Implement strict allowlists for URLs and IP addresses that the server is permitted to interact with. Additionally, use built-in Next.js features like 'getServerSideProps' or 'getStaticProps' for data fetching, which abstract away direct HTTP requests and reduce the attack surface. Always keep Next.js and its dependencies up to date to benefit from the latest security patches.

Laravel

In Laravel, mitigate partial SSRF by validating and sanitizing all user inputs, enforcing strict URL schemas, using built-in HTTP client features to limit request destinations, and implementing access control lists for external services.

Express_js

To mitigate partial SSRF vulnerabilities in an Express.js application, validate and sanitize all user inputs rigorously. Ensure that any URLs or IP addresses supplied by users are checked against a whitelist of allowed destinations. Employ a library like validator to help with input validation. Additionally, configure the HTTP request library to avoid following redirects automatically and to have a strict timeout to prevent long-running requests. Use the principle of least privilege by restricting the server's outbound requests to the minimum necessary for functionality.

Django

In Django, mitigate partial SSRF vulnerabilities by validating and sanitizing all user-supplied URLs before using them in server-side requests. Employ Django's URLValidator for initial validation, ensure only allowed schemes (e.g., 'http', 'https') are used, and restrict target hosts to a predefined whitelist. Additionally, use the 'requests' library with caution, setting a timeout, and avoid sending any sensitive data as part of the request.

Symfony

In Symfony, to mitigate partial SSRF vulnerabilities, validate and sanitize all user inputs, especially URLs, before using them in server-side requests. Employ a whitelist approach to allow only trusted domains and protocols. Additionally, use Symfony's HttpClient component with caution, setting strict options and timeouts to prevent abuse.

Spring_boot

In Spring Boot, to mitigate partial SSRF vulnerabilities, validate and sanitize all user inputs, especially URL parameters. Implement strict input validation using a whitelist approach for URLs and schemes allowed. Additionally, configure the HttpClient to use a URL filter that only permits requests to known, safe domains. Avoid disclosing sensitive information in error messages and ensure that outgoing requests do not expose internal services or resources.

Flask

In the Flask framework, mitigate partial SSRF vulnerabilities by validating and sanitizing all user inputs, ensuring that URLs or IP addresses are from a whitelist of allowed destinations, and using a secure default configuration that restricts outgoing requests to untrusted services. Additionally, employ network-level controls to prevent unauthorized interactions with internal network resources.

Nuxt

In Nuxt.js, to mitigate partial SSRF vulnerabilities, validate and sanitize all user inputs, especially URL parameters, before using them in server-side requests. Implement strict input validation with a whitelist of allowed domains and protocols. Additionally, use network-level controls to restrict the server's ability to make outbound requests only to known, trusted services.

Fastapi

In FastAPI, to mitigate partial SSRF vulnerabilities, validate all URLs and hostname inputs against a whitelist of allowed destinations before making any outbound requests. Additionally, employ client-side libraries that offer safe request functions and avoid directly concatenating user input with request URLs.

Configuration​

Identifier: request_forgery/ssrf_partial

Options​

  • skip_objects : List of object that are to be skipped by the security test.

Examples​

Ignore this check​

checks:
  request_forgery/ssrf_partial:
    skip: true

Score​

  • Escape Severity: HIGH

Compliance​

  • OWASP: API6:2023

  • pci: 6.5.9

  • gdpr: Article-32

  • soc2: CC1

  • psd2: Article-95

  • iso27001: A.14.2

  • nist: SP800-53

  • fedramp: AC-4

Classification​

  • CWE: 918

Score​

  • CVSS_VECTOR: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N/E:H/RL:O/RC:C
  • CVSS_SCORE: 6.2

References​