APP-6932 better local redirect validation

[DTCurrie]

Updates our backto redirect logic to only allow fully-qualified whitelisted https URLs. This will require a change in app to no longer pass just the current pathname for backto and instead to pass the full current URL.

[ohEmily]

trying to get a grip on this.

[q1] could you remind me why we have both a backto as well as a redirect_uri?

[q2] why can't we go with his proposed fix (which Google also confirmed is the best fix for an "open redirect attack"), which is Only allow fully qualified URLs from a whitelist?

Seems like FusionAuth would allow us to lock down our list of redirect URIs, hence q1 above:

[DTCurrie]

trying to get a grip on this.

[q1] could you remind me why we have both a backto as well as a redirect_uri?

[q2] why can't we go with his proposed fix (which Google also confirmed is the best fix for an "open redirect attack"), which is Only allow fully qualified URLs from a whitelist?

Seems like FusionAuth would allow us to lock down our list of redirect URIs, hence q1 above:

The redirect_uri is the path we are redirecting the users to from fusion auth into the app, the backto parameter is something we set in order to redirect the user back to the correct route in app after they have logged in. The flow would go something like:

1. Logged out user goes to /registry
2. They click the login button, which redirects them to /login with the current route set as the backto parameter
3. In /login we check backto to see if it is valid, if so we save it in the session data
4. They log in, and they are sent back to the redirect_uri, in this case /callback.
5. In /callback we check the session data for a backto, in this case that would be /registry so we redirect them there instead of /

backto is unrelated to the redirect_uri and something we handle internally. I don't think fusion auth has a handler for this, if it does it would probably be a larger code change right now to use that over the current sessions implementation.

[jr22]

should these be app.viam.dev and app.viam.com?

[DTCurrie]

I left them as this because we have toyed with allowing users to log in from the marketing page and docs, but maybe I am being a little too forward-thinking here 😃 .

Let's start stricter; I'll update it.

[jr22]

gotcha! yeah i wasnt sure if it would pass the hostnameWhitelist[hostname] check for app.viam.com urls otherwise. could be misreading though

[jr22]

Updates our backto redirect logic to only allow fully-qualified whitelisted https URLs. This will require a change in app to no longer pass just the current pathname for backto and instead to pass the full current URL.

is there an app pr up yet with these changes and the goutils bump so we can test?

[DTCurrie]

Updates our backto redirect logic to only allow fully-qualified whitelisted https URLs. This will require a change in app to no longer pass just the current pathname for backto and instead to pass the full current URL.

is there an app pr up yet with these changes and the goutils bump so we can test?

Not yet, I will set that up.

[DTCurrie]

Potential missing cases:

• CI/Test envs
• PR temp envs