Strengthen SSRF Protection Requirements to Mandatory Standards

[btiernay]

Strengthen SSRF Protection Requirements to Mandatory Standards

Summary: Section 6.5 Server Side Request Forgery (SSRF) Attacks uses SHOULD language and could benefit from more specific implementation guidance to help authorization servers prevent SSRF attacks.

Current Specification Language

From Section 6.5 Server Side Request Forgery (SSRF) Attacks:

Authorization servers fetching the client metadata document and resolving URLs located in the metadata document should be aware of possible SSRF attacks. Authorization servers SHOULD avoid fetching any URLs using private or loopback addresses and consider network policies or other measures to prevent making requests to these addresses. Authorization servers SHOULD also be aware of the possibility that URLs might be non-http-based URI schemes which can lead to other possible SSRF attack vectors.

The current text provides good awareness guidance but could benefit from more concrete implementation details.

Rationale

As discussed in Issue #30, there's community interest in more specific SSRF protection guidance. Implementers would benefit from clearer requirements around IP address validation, timeouts, and redirect handling when fetching metadata documents.

Aaron's recent suggestions for mandatory Accept headers and authentication-first approaches provide a good foundation for more detailed requirements.

Recommendation

Enhancing Section 6.5 with more specific guidance:

6.5 Server Side Request Forgery (SSRF) Attacks

Authorization servers MUST implement SSRF protections when fetching client metadata documents to prevent abuse as attack vectors against internal networks.

Authorization servers MUST validate that client metadata document URLs do not resolve to special-use IP addresses as defined in the IANA Special-Use IP Address Registry [RFC6890]. This validation MUST occur after DNS resolution and MUST account for DNS rebinding attacks.

Authorization servers MUST implement connection timeouts and MUST limit HTTP redirects when fetching metadata documents to prevent resource exhaustion and redirect-based bypass attacks.

And adding to Section 4 Client Information Discovery:

Authorization servers MUST include an Accept: application/json header when fetching client metadata documents.

Authorization servers SHOULD defer fetching client metadata documents until after user authentication to reduce the attack surface for unauthenticated requests.

And adding the following normative reference:

RFC6890:
  title: "Special-Use IP Addresses"
  date: 2013-04
  target: https://www.rfc-editor.org/rfc/rfc6890.html

Related Work

• Builds on community discussion in Issue #30 where implementers shared experiences with SSRF protection
• Incorporates Aaron's recommendations for Accept headers and authentication-first approaches
• Complements existing security considerations in Section 6

Implementation Impact

These enhancements would provide clearer security guidance that authorization server implementers could reference during development. The more specific requirements would help ensure consistent SSRF protections across implementations while maintaining flexibility in deployment-specific timeout and redirect limit values.

[ThisIsMissEm]

The only case where this may not be desirable is when the AS and the client are on the same machine (i.e., both served via loopback IP — I hit into this recently within Bluesky's implementation when I was working on both the AS and the client on my local machine, and had to add in a bunch of workarounds to make it possible to develop both components locally.

[btiernay]

Thanks for that feedback! You raise a good point about the localhost development scenario. The current proposed language might be too restrictive for that use case.

Maybe we could adjust the IP filtering requirement to be more nuanced:

Authorization servers MUST validate that client metadata document URLs do not resolve to special-use IP addresses as defined in [RFC6890], except when the authorization server itself is also running on a loopback address and the resolved address matches the same loopback interface.

This would allow the localhost development scenario you described (AS and client both on 127.0.0.1) while still preventing the main SSRF attack vectors where an external AS fetches internal corporate resources.

Alternatively, we could soften it to:

Authorization servers SHOULD validate that client metadata document URLs do not resolve to special-use IP addresses as defined in [RFC6890] unless explicitly configured to allow such addresses for development purposes.

The goal is preventing production ASs from being used to attack internal networks, but not breaking legitimate development workflows. What do you think would work better for your use case?

[ThisIsMissEm]

I would probably go with the first statement:

Authorization servers MUST validate that client metadata document URLs do not resolve to special-use IP addresses as defined in [RFC6890], except when the authorization server itself is also running on a loopback address and the resolved address matches the same loopback interface.

Bluesky's AT Proto goes a step further as well, verifying that the hostname has at least two components, and prevents usage of the following TLDs:

• .test
• .local
• .localhost
• .invalid
• .example