Is there protection against SSRF and cloud metadata (169.254.169.254) access attempts?

Short answer

Yes, at the signature level. The Server-Side Request Forgery category in the Signature & Rule Library contains 140 rules; 19 of them target cloud metadata services. The rules look for the 169.254.169.254 address and the /latest/meta-data path, the metadata.google.internal and Azure metadata names, the decimal (2852039166), hexadecimal (0xa9fea9fe) and URL-encoded spellings of the address, the AWS ECS metadata address (169.254.170.2) and URLs that target the internal network (127.0.0.1, private network blocks, localhost). The signatures look for the address in the query, form and JSON fields of the request, and some of the rules in the header, path, XML and raw body. Most of the metadata rules are 8 points, and the Cloud Metadata SSRF rule is 9 points; at the default Very Tight protection level, these scores exceed the blocking threshold on their own. WAF inspects only the incoming request; it does not see the connection that the Backend Service opens to the outside, and these connections are restricted at the network layer. In applications that legitimately carry an internal network address in a parameter, false positives can occur; in this case, the signature is excluded only for the relevant parameter.

How Does It Work?

In an SSRF (Server-Side Request Forgery) attack, the client writes an internal network or cloud metadata address into a parameter that makes the application send a request to an address on its own behalf (e.g. ?url=, {"webhook": "…"}). In cloud environments, since metadata addresses such as 169.254.169.254 can return temporary access keys, these addresses are the most frequent target of SSRF (OWASP SSRF).

WAF catches this attack as the request arrives, through the address carried in the parameter. The example values below have been tested against the patterns in the library:

Value in the parameter	Some of the rules that catch it	Score
http://169.254.169.254/latest/meta-data/	Cloud Metadata Ssrf · Cloud Metadata Service Access · SSRF AWS Metadata Service Access	8
http://metadata.google.internal/computeMetadata/v1/	Cloud Metadata SSRF	9
http://2852039166/latest/meta-data (decimal spelling)	SSRF Metadata Service Obfuscated Targeting · Cloud metadata SSRF	8
http://0xa9fea9fe/ (hexadecimal spelling)	SSRF Metadata Service Obfuscated Targeting	8
http%3A%2F%2F169.254.169.254%2Flatest (URL-encoded)	Cloud Metadata Ssrf · Cloud metadata SSRF	8
http://169.254.170.2/v2/credentials (AWS ECS)	SSRF AWS ECS Metadata IP	8
http://127.0.0.1:8080/admin	SSRF rules that target the internal network	8

Each rule works only in the fields within its own inspection scope: most of the rules in the category scan the query, form and JSON values, and some of them scan the header, path, XML and raw body (In which parts of a request are signatures scanned (Path, Query, Header, JSON, XML, Form and Raw)?). If more than one rule matches in a request, the scores are added up (If a request contains several attacks, does the WAF stop at the first match or evaluate all of them?).

SSRF Protection in TR7

• Default state: The rules of the category are active when WAF is turned on; no separate setting is required. Low-risk rules with 2 points are loaded only at the Aggressive protection level; since the metadata rules are 6, 8 and 9 points, they are loaded at every level. While the host group is in Blocking mode, the matching request is blocked; in Monitor mode, it is recorded and passed (WAF Mode).
• Viewing the rules: On the WAF → Signature & Rule Library screen, Filter is clicked; Server-Side Request Forgery is selected in the Signature Categories group or Metadata Service in the Protected Target Types group (What does "Protected Target Types" mean?). Which rules are active on a vService is seen on the OWASP Rules screen of that vService.
• Examining the event: The Attacks tab of the vService's Event Logs record shows the rule name, the score, the field and the parameter name (What do I see in a log record's details (Summary, Attacks, Request & Location)?).
• Additional signature: If an application-specific target address or format (e.g. the application's own internal service name) is not among the built-in patterns, a custom rule is added at the global or vService level (How do I add my own custom rule (regex)?).
• False positive: On endpoints that legitimately carry a URL in a parameter, such as a webhook or a proxy, the signature is excluded only for that parameter (Can I turn off OWASP scanning for a specific parameter?); disabling the signature on the whole vService or putting it into the Monitor state affects a wider area (Is it better to disable a signature entirely or to add an OWASP exclusion?).
• Outgoing connection: WAF does not see the connection that the Backend Service opens itself. The Backend Service's access to the metadata address and to the internal network is restricted at the server or network layer (firewall, the cloud provider's metadata access settings).

Common Misconceptions

• "WAF blocks the requests that the server makes to the outside." WAF inspects only the address in the incoming request; the outgoing connection of the Backend Service is restricted at the network layer.
• "If the address is written in a different form, the signature does not catch it." There are separate rules for the decimal, hexadecimal and URL-encoded spellings; for a new spelling for which there is no pattern, a custom rule is added.
• "The SSRF signature blocks every URL parameter." The high-score rules look for internal network and metadata targets; a parameter that carries a general internet address is not blocked at the default protection level. At the Aggressive level, since rules with 2 points (e.g. HTTPS Scheme Injection) are also loaded, every parameter that carries a URL receives a score.

How it is done in the documentation

• Signature & Rule Library · Signature Categories
• Signature & Rule Library · Protected Target Types
• Signature & Rule Library · Filter
• WAF · The Blocking Threshold

Related questions

• Which attack categories do the signatures cover?
• What does "Protected Target Types" mean?
• Is it better to disable a signature entirely or to add an OWASP exclusion?