Open redirect in oauth path

[saez0pub]

The state is used in order to redirect user after authentication.
It is composed of crsf_cookie:redirect_url.
redirect_url is not validated and could lead to an open redirect (CWE-601: URL Redirection to Untrusted Site ('Open Redirect')) in case of xss forging the crsf cookie in the website protected by the authentication.
A prevention could be to use a whitelist: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.md

Looking at the code, the state parameter of the auth cannot be on another domain and scheme than the redirect parameter in state.

So I added the verification of the redirect parameter based on how the state parameter.

[thomseddon]

@saez0pub Thank you for this and my apologies for the delayed response.

I agree this is a possible issue, so let's get this resolved, I like the approach here but we'll also need to support the use of AuthHost...can I suggest:

• Rename redirectBase to be forwardedRequestBase and use this in returnUrl
• Create a new function redirectBase which includes the auth host check logic from redirectUri, use this in redirectUri function
• Encapsulate the logic of this PR into a new function validateRedirect, this can use the new redirectBase and move tests to just test this function

Sorry I've taken a while to pick this up, if you don't have time to do this I can pick it up over the next couple of weeks, no problemo.

Thanks again :)

[thomseddon]

I've just pushed another version of this, it works slightly differently as I realised the patch you initially provided would not work with an auth host setup.

I need to do a little more testing on this, as the lack of validation could be considered a bug I'd like to release this ASAP.

[thomseddon]

I've thought a little more about this and I'm not sure this is actually anything to exploit here.

The redirect is read from the CSRF cookie here:

traefik-forward-auth/internal/server.go

Lines 127 to 133 in 68c3299

	// Validate state
	valid, providerName, redirect, err := ValidateCSRFCookie(r, c)
	if !valid {
	logger.Warnf("Error validating csrf cookie: %v", err)
	http.Error(w, "Not authorized", 401)
	return
	}

During the CSRF "validation", the nonce is also read and the function just verifies that the nonce matches the state param in the URL, which could be forged.

However, the redirect is only followed if the code is successfully exchanged for an access token with the provider. If the exchange fails or the user cannot be retrieved, the server returns a 503 and does not follow the redirect:

traefik-forward-auth/internal/server.go

Lines 146 to 159 in 68c3299

	// Exchange code for token
	token, err := p.ExchangeCode(redirectUri(r), r.URL.Query().Get("code"))
	if err != nil {
	logger.Errorf("Code exchange failed with: %v", err)
	http.Error(w, "Service unavailable", 503)
	return
	}
	// Get user
	user, err := p.GetUser(token)
	if err != nil {
	logger.Errorf("Error getting user: %s", err)
	return
	}

As such, to exploit this redirect the attacker would need to pass a valid code - which can only be obtained following successful authentication of the user. Additionally, by design the code is prevented from being intercepted as the user must explicitly configure valid return_url's with the provider, so the code will only ever be sent to an expected destination.

I understand this was a vulnerability in the oauth2-proxy module, but I believe they were vulnerable as they have a sign in page that will redirect an authenticated user: https://github.com/oauth2-proxy/oauth2-proxy/blob/dd05e7ff0bad417b088c9e67e5eaa624e30e3ddc/oauthproxy.go#L684-L705

Reading here: https://tools.ietf.org/id/draft-ietf-oauth-security-topics-05.html#rfc.section.3.8.2

In order to prevent open redirection, clients should only expose such a function, if the target URLs are whitelisted or if the origin of a request can be authenticated.

And so it seems that successful code exchange should be sufficient for validating the origin of the request. There is the possible vector of the attacker generating a valid code themself, injecting a malicious redirect_uri and tricking another use to visit, however our use of the state param here is designed to prevent that exact CSRF attack.

If anyone thinks I have missed something here, please let me know - I will leave this open for a while in case anyone can show how this could be exploited, but otherwise I will close this

[sauyon]

I've thought a little bit about this and I think I agree with your assessment of the situation, though if redirects are only meant to go to certain places I'd suggest doing checks against the redirect URL just in case.