Authorization Request Header Field: CRLF Injections

[lauritzh]

In Section 5.2.1.1. the syntax of access_token values that are used in the context of HTTP headers is explicitly outlined as follows:

b64token    = 1*( ALPHA / DIGIT /
                 "-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token

I think it is a good thing that this description was moved from rfc6750 to the "core". 🙂

One particular issue I observed in the wild are CRLF injection issues caused by access_token values being used without any sanitisation. Examples for this can for instance be found in my master's thesis (section 5.4.3.1) and on my blog.

A CRLF injection via the bearer token could have significant impact, as the IdP may be also in the position to directly make the SP to perform requests to a chosen destination (e.g. "malicious Endpoint Attack" via UserInfo request in OIDC). Cloud providers tend to implement mitigations against SSRF to the internal network using special HTTP headers. This mitigation could be bypassed using this type of injection issue.

Therefore, I would like to propose to add a recommendation to carefully sanitise the bearer tokens before using them in the context of HTTP headers.

[aaronpk]

Newlines aren't allowed in bearer tokens according to that definition. Are you suggesting adding something in the security considerations to suggest that clients double check that there are no newlines in a bearer token before using one in an HTTP header?

[lauritzh]

Hey @aaronpk!

Thank you very much for having a look into this.

Yes, I would suggest to add something to the security considerations regarding the handling of received access_token. SPs must check that the received value follows the specification and does not include any dangerous meta characters like CRLF sequences.

What do you think about this? I could on the one hand think about a general recommendation to carefully sanitize the access_token in a context aware manner before utilizing it. On the other hand a specific recommendation regarding HTTP headers would be maybe easier to follow for implementers.

[aaronpk]

I don't think any recommendation that involves the client modifying (sanitizing) the access token is a good idea. At most I would say check whether the access token has any invalid characters and discard it if there are any.

[lauritzh]

I agree on that. Discarding malformed tokens that include invalid characters sounds like a reasonable recommendation to me and is indeed less complex implementation-wise :+1:

[aaronpk]

On further thought, this actually sounds like more of a recommendation for the HTTP client rather than the OAuth client. An HTTP client shouldn't allow CRLF characters in values of HTTP headers. I don't think it's a good idea to recommend that OAuth clients validate the syntax of an access token without it sounding like we mean clients should be fully parsing an access token.