Every thing required to check a novel OAuth 2.Zero implementation.
You’ve been assigned to your subsequent gig and the first focus is to judge a customized OAuth 2.Zero implementation. You’ve heard of OAuth as a third-party authorization delegation service, however want a set of take a look at instances and a few context.
I’ll clarify every little thing it’s essential to learn about OAuth from a safety standpoint and supply a transparent record of take a look at instances so you possibly can report excessive severity points in your subsequent engagement.
This information will cowl the Authorization Code Grant circulation. After studying this text, you must have sufficient context to plot your individual take a look at instances for the remaining authorization flows. Future articles will focus on the remaining authorization flows in additional element.

What’s OAuth?
OAuth is an try to migrate authorization to a 3rd social gathering service. It permits a useful resource supplier (RP), to request entry to a consumer’s assets from an id supplier (IDP) topic to the consumer’s approval. The RP is often the web site in scope for the engagement and the IDP is often an exterior service like GitHub, Bitbucket, or Fb.
There are a number of completely different grant sorts that change the OAuth circulation. Initially, this web page will doc a few of the edge instances which needs to be lined throughout Authorization Code Grant flows.
Comply with this circulation chart to know which Grant the service you might be testing ought to use. The required parameters and menace mannequin adjustments relying on the kind of Grant the service makes use of.
The Authorization Code Grant
This diagram succinctly illustrates a typical Authorization Code Grant circulation:

Diagram Credit score: https://arxiv.org/abs/1601.01229v4
On this diagram, the RP is the web site you can be testing, and the IDP is the id supplier who owns the consumer’s assets. Let’s stroll by way of every step of the diagram with a little bit of hypothetical commentary so the unaltered circulation is known.
This will get a bit dense. Understanding these steps intimately is essential if you wish to discover points throughout the OAuth implementation. If attainable I’d suggest opening the picture and these steps side-by-side so you possibly can reference forwards and backwards as wanted.
The steps beneath correspond to the steps within the diagram above:

The Browser selects a supplier, let’s say GitHub, within the utility and clicks “Connect with GitHub”.
The RP receives this request and directs the Browser to the IDP together with a public Client_Id, a Redirect URI and a State.
The Browser accepts the redirect and goes to the IDP endpoint.
The IDP responds and asks for the consumer to authenticate and to approve the scope of the OAuth request (scope right here that means, repo stage, admin stage…)
The Browser sends authentication data and approves the scope of the OAuth request.
The IDP directs the Browser to the Redirect_URI together with the Code and the State.
The Browser follows the redirect to the RP’s OAuth endpoint and passes alongside the Code and the State.
The RP makes a name to the IDP making an attempt to trade a Code, Client_Id, Redirect_URI, and Shopper Secret for an Entry Token.

Don’t confuse this Redirect_URI with the one utilized in Step 2. This may in all probability not be modifiable because the RP doesn’t ship this request by way of the browser.

If the Shopper Secret and Code are legitimate for the given Client_Id, then the IDP will return an Entry Token to the RP.
Now the RP needs to entry the consumer’s assets. They will merely name the IDP endpoint with the Entry Token as a parameter. That is often completed by way of a customized header.
If the Entry Token is legitimate, the IDP will return that consumer’s assets.

Abstract of Key Gadgets and Permissions
Entry Token
An entry token is a multiple-use string issued by the IDP which might be immediately used to entry the consumer’s assets saved on the IDP.

An Entry Token can be utilized to immediately make requests to the IDP with out going by way of the RP.
The Entry Token ought to by no means be seen by the browser, it’s secret to the RP.

Authorization Code
This code is a single-use string which might be mixed with a legitimate State and Shopper Secret and exchanged on the IDP for an Entry Token. You can not use this code to entry a consumer’s assets on the IDP, it should first be exchanged for an Entry Token.

It’s necessary to level out right here that Code != Entry Token. An authorization code can’t be used to immediately make requests to the IDP and should be exchanged for an entry token by the RP.
The Authorization Code shall be handed from the Browser to the RP, who will trade it with the IDP for an Entry Token.

This Code can’t be used to obtain an Entry Token from the IDP until it’s paired with the RP’s Shopper Secret.

The client_id is exclusive to every RP and permits the RP to establish itself to the IDP.

The Client_Id is public and identifies this RP to the IDP.

Shopper Secret
The Shopper Secret is exclusive to every RP and permits the RP to trade legitimate code and state combos for Entry Tokens on the IDP.

The Shopper Secret should all the time be stored secret! If it ever leaks, attackers can subvert the OAuth circulation by changing codes into tokens. This enables them to entry the assets on the IDP immediately as an alternative of accessing them by way of the RP.

Redirect URI
The Redirect URI is the situation the place the IDP will ship the Browser after finishing the auth dance. When the Browser is directed right here, it is going to include the Authorization Code and the State.

The Redirect URI needs to be registered with the IDP and constrained to a single worth or to a sample match.

The State is non-public and needs to be distinctive per OAuth session. It’s basically a CSRF Token and needs to be protected accordingly.

The RP should validate that the State acquired from the Browser is identical because the State despatched in step 2 for CSRF safety.

Now you perceive how the OAuth 2.Zero Code Grant circulation ought to work underneath ultimate circumstances. Let’s enumerate quite a few take a look at instances, starting from least to most intricate, which might derail the method and supply an attacker with benefits.
Check Instances
Inadequate URI Validation:
That is a simple take a look at merchandise, and infrequently one of the lethal assaults for OAuth. Recall in Step 2. that the Redirect URI needs to be registered to a single worth or in some instances to a sample match. The important thing hazard right here is when the sample match is insufficiently specified and permits the Redirect URI to be wherever throughout the top-level area.
If any location within the area permits an attacker to incorporate materials (a picture hyperlink, href, and so forth.) they will usually steal the Code and the State from the Referer header. Even worse, as a result of the Redirect URI was not the anticipated OAuth endpoint, it’s very doubtless that the code gained’t have been consumed for an Entry Token but.
This implies an attacker can immediately substitute the sufferer’s Code for their very own by way of the RP to be able to manipulate the sufferer’s assets by way of the RP. This difficulty can have an amplified affect if the State worth is reused when requests are invalid, as it is going to enable an attacker to compose a CSRF to substitute attacker assets for the sufferer’s utilizing the legitimate state.
Check Steps:

Choose an OAuth supplier, Begin Intercepting, Press Join Button.
Ahead till you see a request to the IDP equivalent to Step 2. within the above diagram.

It’s attainable that you simply gained’t see a redirect_uri parameter right here. If that is so, it’s doubtless registered to a single URI, however you possibly can add it and take a look at anyway.

Alter the redirect_uri URL parameter and substitute it with the top-level area:

aws.console.amazon.com/myservice → aws.console.amazon.com

Proceed by way of the OAuth circulation, authenticating, and granting entry.
If after the OAuth dance, the Browser is redirected to the top-level area, then the positioning is susceptible to this assault.

Earlier than marking this difficulty as excessive severity, make certain to confirm that the positioning doesn’t trim the Referer header or in any other case strip the URL parameters. In any other case, the Code / State shall be tough to get better and that is simply an open redirect. If an XSS might be discovered wherever within the website, the code / state might be stolen by way of JavaScript which checks the URL parameters.
Referer Header Leaks Code + State:
It is a prerequisite to the earlier assault; be sure that after the IDP’s redirect to the RP, the Referer header is stripped of URL parameters and even eliminated if attainable. This may forestall the assault state of affairs detailed above.
Check Steps:

Choose an OAuth supplier, Begin Intercepting, Press Join Button.
Ahead by way of requests and full the OAuth Movement.
If at any level after the redirect to the RP, you see the code and state within the Referer header, then the positioning is susceptible to this assault.

Entry Token Saved in Browser Historical past:
If the RP makes a GET request which incorporates the Entry Token within the URL parameters, then the delicate OAuth variables could also be saved in browser historical past. That is simple to check for and could be a fast drawback report.
The menace is of medium severity if the entry token is saved, but when solely the code or state is saved, it’s low severity because the attacker would require some type of native entry to the sufferer’s machine. Even then, it’s doubtless that the code has already been redeemed for an entry token, so the one actual assaults would revolve round stealing a reused state variable.
Check Steps:

Choose an OAuth supplier, Press Join Button.
Full an OAuth circulation and authorize the scope.
Open your browser’s historical past and see if any of the Location entries include delicate data.

Different Entry Token Leakage:
If at any level in testing you see a uncooked Entry Token, that’s in all probability a medium severity discovering. Having the ability to convert stolen codes to entry tokens permits an attacker to bypass no matter restricted performance is offered by way of the service and as an alternative immediately hit the IDP with no matter entry was permitted within the scope.
The severity of this difficulty is amplified by the truth that scopes can not (often) be restricted on the IDP stage. It’s solely as much as the consumer to confirm that the scope is right. So an attacker can compose a CSRF assault to alter the scope stage, steal a code / state by way of the above assaults, and convert it to an entry token in their very own browser. This is able to give them full management over the sufferer’s IDP assets.
Shopper Secret Leakage:
If at any level in testing you see the Shopper Secret, that’s a medium to excessive severity discovering. An attacker with the Shopper secret is ready to convert stolen codes to entry tokens, permitting them to bypass no matter restricted performance is offered by way of the service and as an alternative immediately hit the IDP with the entry permitted within the OAuth scope.
Lack of State:
If the RP declines to supply a state variable, which is technically non-obligatory as per the spec, they are going to be putting customers vulnerable to CSRF assaults. Attackers can compose CSRF assaults with modified Redirect URIs and an attacker’s Code to authenticate the sufferer utilizing attacker assets.
If the sufferer doesn’t notice that the authentication code has been swapped, they might place delicate knowledge inside attacker-controlled assets. The explanation this assault works is as a result of the state parameter in step 2 is exclusive to a session. If there isn’t any state supplied at step 2 of the OAuth circulation there may be nothing to confirm the session token in opposition to.
Check Steps:

Choose an OAuth supplier, Begin Intercepting, Press Join Button.
On the preliminary request to the IDP, confirm that the state worth is handed as a URL parameter.
Proceed stepping by way of the OAuth Movement till the Redirect URI is reached.
Make sure that the Redirect URI has the state as a URL parameter.

Make sure that if the service has a number of OAuth Endpoints or bounces after the Redirect URI, that the ultimate hop really passes the state to the backend RP.

Insecure State:
The State variable needs to be handled like a CSRF token. If the worth used for State is predictable or in any other case brute force-ible, then it’s attainable that an attacker might make a number of CSRF assaults in an automatic vogue and brute pressure an authenticate a consumer with attacker assets.
Check Steps:

Choose an OAuth supplier, Begin Intercepting, Press Join Button.
On the preliminary request to the IDP, view the State worth handed as a URL parameter.
Repeat this course of, verifying that the State variable has adequate entropy and isn’t in any other case predictable.

Reused State:
The State variable is used to make sure that an attacker can not carry out CSRF assaults like these detailed above. If the State variable is reused throughout a number of requests, there’s a bigger affect of the state variable being compromised as it could nonetheless be legitimate for future periods.
If an attacker solely has entry to a sufferer’s State, they will compose a CSRF assault and use an attacker code to be able to authenticate the sufferer utilizing attacker OAuth assets. That is often a medium severity difficulty however use your greatest judgment because the severity is tightly linked to the convenience of leaking a state variable.
Check Steps:

Choose an OAuth supplier, Begin Intercepting, Press Join Button.
On the preliminary request to the IDP, view the State worth handed as a URL parameter.
Repeat this course of, verifying that the State variable has been modified between requests.
It’s necessary to check this within the case that OAuth succeeds and within the case the place OAuth fails, both as a result of the consumer rejected the scope, or as a result of the Redirect URI didn’t go to the anticipated RP OAuth Endpoint.

Invalid State Validation:
Generally an RP seems like they’re doing every little thing appropriately, passing the state with adequate entropy, holding it distinctive per OAuth session, however behind the scenes, they simply throw away the state token.
Alternatively, generally an attacker can omit the state variable and the request is handled as right. This take a look at is to make sure that the entire state is validated, and there aren’t any bypasses that may be carried out by merely ignoring the state.
Check Steps:

Choose an OAuth supplier, Begin Intercepting, Press Join Button.
On the preliminary request to the IDP, modify the State parameter handed as a URL parameter by altering it to an invalid worth.
Full the OAuth Movement, and validate that the returned code and invalid state are rejected by the RP.
Repeat steps 1-Three however omit the state variable altogether. Make sure that the RP rejects the response from the IDP.

Reusable Authorization Codes:
Examine to see if an RP will let a consumer redeem the identical authorization code a number of instances. Every code ought to solely be good for a single OAuth session, reusing a code that has already been redeemed ought to end in an error.
Check Steps:

Full a whole OAuth course of. Observe the authorization code supplied by the IDP, save this worth.
Choose the identical OAuth supplier, Begin Intercepting, Press Join Button.
Full the OAuth Movement, and validate that the returned code is completely different from the code acquired in step 1.
Substitute the returned code with the code saved in step 1.
Make sure that the OAuth course of fails, both by way of rejection from the RP or the IDP.

Entry Token Saved in JavaScript:
That is positively price checking on all main net frameworks. Usually net frameworks like Redux, React, and so forth. may have an inner state which is accessible by way of the console or by way of net browser plugins.
Builders will sometimes assume that this data is secret and can retailer the OAuth Entry Token within the framework state. This may be stolen by an attacker and used to transform a sufferer’s authorization code and state right into a usable entry token which is leaked by way of these JavaScript objects. Check steps right here will differ per framework and implementation.
Implicit Grant Coercion:
This assault not often works, however could also be price doing with extra obscure IDPs. The preliminary request from an RP to an IDP in Step 2. has an non-obligatory parameter response_type. This assault makes an attempt to transform the authorization code grant to an implicit grant, which skips the stage involving an authorization Code and instantly returns an Entry Token.
Enjoyable reality: Fb by default permits for the Code workflow in addition to the Implicit (referred to as Token on Fb) grant. Simply one thing to bear in mind.
Check Steps:

Choose an OAuth supplier, Begin Intercepting, Press Join Button.
On the preliminary request to the IDP, modify the response_type worth handed as a URL parameter by setting it equal to: “token”.
Proceed by way of the authorization circulation, forwarding requests till the Redirect URI is reached.
If a uncooked Entry Token is returned right here, then the IDP is susceptible to this assault.

307 Redirect Assault:
Additionally a reasonably obscure assault, however could possibly be price making an attempt with probably insecure IDPs. If in the course of the IDP’s redirect to the Redirect URI, they make the most of a 307 code as an alternative of a 302 code, and the IDP redirects the consumer instantly after they enter their credentials, it’s attainable for an attacker operating a malicious RP to steal the consumer’s credentials.
The 307 standing code may have the consumer’s Browser ship a POST request to the RP containing the entire kind data, together with the consumer’s credentials!
Check Steps:

Choose an OAuth supplier, Begin Intercepting, Press Join Button.
Proceed by way of the authorization circulation till the second when the consumer logs into the IDP.
Discover the request redirecting the Browser to the Redirect URI. If this request makes use of a 307 response code, then the IDP is susceptible to this assault.

OAuth is a posh protocol with an unintuitive specification. As an attacker, this interprets to frequent mis-implementations inside this central authorization protocol. Use this data to repair as many damaged implementations as you possibly can and assist builders launch safe software program.
If this information was useful to you, or when you have feedback about this text, please be happy to achieve out. I need to hear what you suppose! If you wish to learn extra of my content material, view the archive on my private website, subscribe to my e-newsletter, or help me on Ko-Fi (not affiliated with Safety Innovation).
Sources and References:
Sensible Exploitation:
If you wish to examine real-world exploitation of various OAuth bugs listed here are just a few from the knowledgeable in OAuth hacking:


Extra Sources

https://arxiv.org/pdf/1601.01229 — Extremely suggest studying the primary 15 pages of this, very clear and succinct explanations.
https://instruments.ietf.org/id/draft-ietf-oauth-security-topics-05.html — Official safety suggestions from IETF
https://sakurity.com/oauth — Very opinionated, however describes quite a few helpful assaults
https://www.ory.sh/sign-in-with-user-impersonation-oauth2-openid-connect — Very neat trick the place modified usernames can be utilized for account takeover
https://hackerone.com/stories/405100 — Bypassing the filters of the redirect_uri might be very harmful
https://hackerone.com/stories/215381 — Twitter OAuth bug
https://hackerone.com/stories/46485 — Twitter access_token with OAuth can be utilized on a number of customers