4 ms·
RFC 6749 goes into details on how the authorization server should prevent this type of attack The authorization server MUST require public clients and SHOU
by matja 3y ago
RFC 6749 goes into details on how the authorization server should prevent this type of attack
The authorization server MUST require public clients and SHOULD require
confidential clients to register their redirection URIs. If a redirection
URI is provided in the request, the authorization server MUST validate it
against the registered value.
So how is this possible, when presumably the Harvest app did not register the malicious redirect_uri?
Does the Microsoft OAuth server ignore URL parameters within a redirect_uri when comparing with registered redirect URIs for the OAuth client?
- Uvix 3y agoThe 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.
- matja 3y agoI 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.
- scurvy_steve 3y agoThey 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, but that endpoint then reads the the state parameter and happily forwards the response/token. 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).
- michaelt 3y agoIt'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" ?
- Operyl 3y agoStore the basket in a temporary cookie, not the oauth state parameter.
- lstamour 3y agoAlso 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.
- johncolanduoni 3y agoDon'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.