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://
, andgopher://
. - Authentication on internal services.
GraphQL Specific
Apollo
Yoga
Awsappsync
Graphqlgo
Graphqlruby
Hasura
REST Specific
Asp_net
Ruby_on_rails
Next_js
Laravel
Express_js
Django
Symfony
Spring_boot
Flask
Nuxt
Fastapi
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