Are post_login_success_uri and post_login_failure_uri a security breach?

[ch4mpy]

I recently had a use for the port_login_success_uri and discovered that it’s an open redirect. I could just supply ?post_login_success_uri=https://github.com/ and would be happily redirected away from my application to Github after successful OAuth2 log-in.

I think it’s insecure; c.f. CWE-601: https://cwe.mitre.org/data/definitions/601.html

[ch4mpy]

From the CWE-601 description:

The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.

In the case of an application with oauth2Login, the post_login_success_uri and post_login_failure_uri are set in the frontend sources at development or configuration time. It is not user input at runtime. So, no, CWE-601 is not a concern.

However, it seems possible to alter the X-POST-LOGIN-SUCCESS-URI & X-POST-LOGIN-FAILURE-URI headers or post_login_success_uri & post_login_failure_uri request params with some cross-site scripting.

It should be noted that:

• Even if a compromised dependency could trick the user into another domain, the application on the malicious domain could not access the session ID & CSRF token value. So, the impact of such attacks is limited: as explained in the CWE-601, initiation of a fishing scam or redirection to a page containing some malware, which won't arm careful users with a decent anti-virus.
• A compromised dependency does not need really custom headers or request params to perform a redirection. So, adding some restrictions to the authorized redirection domains in the configuration of applications with oauth2Login wouldn't protect end users much.

So, nothing very special regarding X-POST-LOGIN-SUCCESS-URI & X-POST-LOGIN-FAILURE-URI headers or post_login_success_uri & post_login_failure_uri request params, as long as:

• their value is computed by application code (not user input, but why would it be?)
• the frontend's dependencies security patches are applied

[thomas-seag]

I'm not too happy about this being in a public Github discussion already, but since the cat is out of the bag now:

I can put a link like

<a href="https://legit-application.com/oauth2/authorization/auth0?post_login_success_uri=https://malicious-application.com/">Log in to the legit application</a>

somewhere. A user who follows that link will go through the legit application's OAuth2 flow, but then end up at the malicious application, which doesn't have to care about session or csrf token from the legit application at all.

No front-end involved at all.

[thomas-seag]

The user is initially not "already on the evil domain". The user can be anywhere. The link could be in an e-mail, or on some innocuous third web site. Or even on a legit third website that normally has a link to legit-application.com, but that got hacked and the link now still goes to legit-application.com, but also has this query parameter.

[ch4mpy]

"disallow off-site redirects", but maybe there are use-cases where a whitelist would be more appropriate

Disabled cross-site redirection is the same thing as a white list with the original one as only entry. So, the white list is probably the option to go.

[ch4mpy]

Here is a possible specification for an evolution "Expose a property accepting an array of patterns for redirection URLs. If the property is left empty, accept all URLs starting with the value of the client-uri property".

What do you think?

[thomas-seag]

Sound about right, but two nits:

1. Always allow redirections that do not contain a host/port? Or would the user have to specify a pattern like "/**" (assuming Ant style) for that?
2. Clarify what kind of patterns. Regexp, or Ant, or domain with wildcard (like "*.example.com")? Would the pattern apply to the whole redirect URI, or only to the scheme and authority or scheme and authority plus path?

[ch4mpy]

@thomas-seag I opened an issue for this. It contains more details about the solution I'm working on.

I'm almost done (writing unit tests) and expect to release before the end of the day (Tahiti time).

[ch4mpy]

Closing in favor of:

• issue: CWE-601 with post login/logout URIs #267
• PR: Prevent Open Redirect (CWE-601) #268