The Harvest redirect_uri is registered with Microsoft. Harvest implements its own redirect after the Microsoft OAuth server redirects to them, based on the data in the state.

I agree the fact that Harvest blindly redirects helps enable the attack, but according to the OAuth standard, a redirect_uri which does match a registered one should not be accepted before authorization takes place.

From the POC authorization URL, the redirect_uri parameter and value are:

    redirect_uri=https%3A%2F%2Foutlook-integration.harvestapp.com%2Fauth%2Foutlook-calendar%2Fcallback?state=%7b%22return_to%22:%22/time%22%2c%22subdomain%22:%22example.com/%22%7d

So if Harvest registered the redirect_uri as:

    https%3A%2F%2Foutlook-integration.harvestapp.com%2Fauth%2Foutlook-calendar%2Fcallback

then why does any extra URL parameters added to that value get accepted by the Microsoft OAuth server before authorization, when they clearly do not match the registered one?

edit: I tried authorizing using another OAuth server provider, with a changed redirect_uri by appending URL parameters to the encoded value, and the OAuth server (I believe, quite rightly) rejected the authorization request.

Allowing the query string to be altered is allowed but discouraged by the OAuth 2.0 spec: https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2....

Interesting, thanks!

They are adding a second redirect on top and sticking it into the state parameter, presumably so they can redirect to anywhere. so the flow wanted was

Go the some harvest authorize url,

That redirects to the Microsoft authorize url with redirect_uri=registered_uri and state=some_encoded_final_uri,

user enters credentials,

redirect to a registered uri

read state parameter and redirect to uri encoded in state.

This exploit still redirect to an authorized uri, then authorized uri then reads the the state parameter and happily forwards the response.

3 mistakes in this, abusing state, not encypting and validing state if you are going to abuse it. Enabling implicit grant(even if they needed it, should have made a second registration with limited uses).

It's kinda normal that you'd want to let a user log in and return them to the page they were at.

For example, if you're making a shopping website and a user asks to put something in their basket and you send them to log in, you'd want to return them to the item they were about to buy, not dump them back at the homepage.

What's the proper way of doing this, without "abusing state" ?

Don't attach the sensitive URL parameters to the second redirect. The first redirect logs you in via cookie, and then if the second redirect is on the right origin it will have access to your cart.

Store the basket in a temporary cookie, not the oauth state parameter.

Also only allow redirects to your domain or website, not literally anywhere on the internet. And the token should stay in your website’s cookies - it’s unclear why the second redirect would ever need to pass a token if it can read it from site cookies in the first place.

At the least you're supposed to validate the at the returning "state" parameter is the same value as what you sent (using cookies or local storage).

Ideally you would 'consume' the token before redirecting, and not send it to the second redirecting url.

There's no reason to have a URL (or any data) encoded in the state parameter. The purpose of the parameter is to provide an opaque lookup key which you can utilize to provide correct, validated responses. This is usually done in some sort of database or Redis-like cache. My workflows have always used a random UUID for the state key and I just encode the necessary (validated) data items needed for the next step as a JSON blob. It's essentially a very short-lived web session.

If for some reason you really do need to transmit this data in-band (ultra rare use case) you should at least be using something like HMAC to verify that all carriers have transported the data unmodified. It is your responsibility to ensure the integrity of the data end-to-end.

But in the POC link, they have state=1 as a parameter for the authorization server, there is another state parameter encoded into the value for the redirect_uri, which makes me wonder why that even matches the registered redirect_uri.

You are right that redirect_uri must match the exact registered redirect_uri.

But some providers allow query parameters. For Microsoft, it was possible in 2020 when I reported the vulnerability. In 2022, they restricted query parameter support to only applications that is built for Work and School accounts and in August 2022, they added a section for this in the documentation.

See: - Commit: https://github.com/MicrosoftDocs/azure-docs/commit/c249a0548... - Current Documentation: https://learn.microsoft.com/en-us/azure/active-directory/dev...