ReturnUrl as query parameter : good practice ?

[baouchemaya]

Hi,

Using one of the samples, I get redirected to thedemo.duendesoftware.com login page and in the url, we can find the ReturnUrl parameter. I wanted to know if doing this was not a vulnerability and if this was a good practice ?

Thank you in advance

[AndersAbel]

You are right in that exposing the return url in the query string makes it possible for a malicious user to manipulate the URL. The query string parameter must be treated as untrusted input. In the code from our quick start UI the return url is properly validated before it is used with a call to Url.IsLocalUrl.

The redirect is then back to /connect/authorize/callback with a set of query string parameters. They are all also properly validated before being used.

[josephdecock]

Also, if you're just generally concerned about protocol parameters in the url, there is a relatively new spec called Pushed Authorization Requests (PAR) that I am working on for the next major release of identity server. In PAR, all the protocol parameters that are normally sent over the front channel are instead sent over the backchannel in an initially pushed request, which stores them at the identity provider and returns a random id value back to the client. Then the front channel request only needs to include that id. This hides and prevents tampering with the request parameters, which can provide an extra layer of security and privacy.

This is most useful in specialized applications like open banking. All the validation that Anders is referring to above is already in place to protect you today.

https://www.rfc-editor.org/rfc/rfc9126

https://github.com/DuendeSoftware/IdentityServer/pull/1424

[AndersAbel]

Closing due to inactivity. Please feel free to reopen if needed.