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 guage 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 is advisable find out about OAuth from a safety standpoint and supply a transparent checklist 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 stream. After studying this text, it is best to have sufficient context to plan your individual take a look at instances for the remaining authorization flows. Future articles will talk about the remaining authorization flows in additional element.

What’s OAuth?
OAuth is an try and migrate authorization to a 3rd occasion service. It permits a useful resource supplier (RP), to request entry to a person’s assets from an identification supplier (IDP) topic to the person’s approval. The RP is normally the web site in scope for the engagement and the IDP is normally an exterior service like GitHub, Bitbucket, or Fb.
There are a number of totally different grant sorts that change the OAuth stream. Initially, this web page will doc a number of the edge instances which needs to be lined throughout Authorization Code Grant flows.
Observe this stream chart to grasp which Grant the service you might be testing ought to use. The required parameters and risk mannequin modifications relying on the kind of Grant the service makes use of.
The Authorization Code Grant
This diagram succinctly illustrates a typical Authorization Code Grant stream:

Diagram Credit score: https://arxiv.org/abs/1601.01229v4
On this diagram, the RP is the web site you may be testing, and the IDP is the identification supplier who owns the person’s assets. Let’s stroll by means of every step of the diagram with a little bit of hypothetical commentary so the unaltered stream 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 potential I’d advocate opening the picture and these steps side-by-side so you possibly can reference backwards and forwards as wanted.
The steps under correspond to the steps within the diagram above:

The Browser selects a supplier, let’s say GitHub, within the software 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 person to authenticate and to approve the scope of the OAuth request (scope right here which means, repo degree, admin degree…)
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 trying to change a Code, Client_Id, Redirect_URI, and Consumer Secret for an Entry Token.

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

If the Consumer 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 person’s assets. They’ll merely name the IDP endpoint with the Entry Token as a parameter. That is normally carried out by way of a customized header.
If the Entry Token is legitimate, the IDP will return that person’s assets.

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

An Entry Token can be utilized to instantly make requests to the IDP with out going by means 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 sound State and Consumer Secret and exchanged on the IDP for an Entry Token. You can not use this code to entry a person’s assets on the IDP, it should first be exchanged for an Entry Token.

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

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

Client_Id
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.

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

The Consumer Secret should all the time be stored secret! If it ever leaks, attackers can subvert the OAuth stream by changing codes into tokens. This permits them to entry the assets on the IDP instantly as an alternative of accessing them by means of the RP.

Redirect URI
The Redirect URI is the placement the place the IDP will ship the Browser after finishing the auth dance. When the Browser is directed right here, it can 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.

State
The State is personal and needs to be distinctive per OAuth session. It’s primarily a CSRF Token and needs to be protected accordingly.

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

Now you perceive how the OAuth 2.Zero Code Grant stream ought to work underneath excellent circumstances. Let’s enumerate a variety of 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 probably the most 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 anyplace throughout the top-level area.
If any location within the area permits an attacker to incorporate materials (a picture hyperlink, href, and many others.) they’ll typically 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 received’t have been consumed for an Entry Token but.
This implies an attacker can instantly substitute the sufferer’s Code for their very own by means of the RP in an effort to manipulate the sufferer’s assets by means of the RP. This difficulty can have an amplified impression if the State worth is reused when requests are invalid, as it can permit 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 comparable to Step 2. within the above diagram.

It’s potential that you simply received’t see a redirect_uri parameter right here. If so, it’s doubtless registered to a single URI, however you possibly can add it and check out anyway.

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

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

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

Earlier than marking this difficulty as excessive severity, make sure that to confirm that the location doesn’t trim the Referer header or in any other case strip the URL parameters. In any other case, the Code / State will likely be tough to recuperate and that is simply an open redirect. If an XSS might be discovered anyplace within the web site, the code / state might be stolen by means of JavaScript which checks the URL parameters.
Referer Header Leaks Code + State:
It is a prerequisite to the earlier assault; make sure that after the IDP’s redirect to the RP, the Referer header is stripped of URL parameters and even eliminated if potential. This can forestall the assault situation detailed above.
Check Steps:

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

Entry Token Saved in Browser Historical past:
If the RP makes a GET request which accommodates 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 risk 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 stream 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 means of the service and as an alternative instantly 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’t (normally) be restricted on the IDP degree. It’s solely as much as the person to confirm that the scope is appropriate. So an attacker can compose a CSRF assault to vary the scope degree, steal a code / state by means of the above assaults, and convert it to an entry token in their very own browser. This could give them full management over the sufferer’s IDP assets.
Consumer Secret Leakage:
If at any level in testing you see the Consumer Secret, that’s a medium to excessive severity discovering. An attacker with the Consumer secret is ready to convert stolen codes to entry tokens, permitting them to bypass no matter restricted performance is offered by means of the service and as an alternative instantly 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-compulsory as per the spec, they are going to be putting customers liable 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 information inside attacker-controlled assets. The rationale 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 stream 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 means of the OAuth Stream till the Redirect URI is reached.
Be sure that the Redirect URI has the state as a URL parameter.

Be 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 potential that an attacker might make a number of CSRF assaults in an automatic style and brute pressure an authenticate a person 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’t carry out CSRF assaults like these detailed above. If the State variable is reused throughout a number of requests, there’s a bigger impression of the state variable being compromised as it could nonetheless be legitimate for future classes.
If an attacker solely has entry to a sufferer’s State, they’ll compose a CSRF assault and use an attacker code in an effort to authenticate the sufferer utilizing attacker OAuth assets. That is normally 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 vital to check this within the case that OAuth succeeds and within the case the place OAuth fails, both as a result of the person 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 only throw away the state token.
Alternatively, generally an attacker can omit the state variable and the request is handled as appropriate. This take a look at is to make sure that all the state is validated, and there are not 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 Stream, and validate that the returned code and invalid state are rejected by the RP.
Repeat steps 1-Three however omit the state variable altogether. Be sure that the RP rejects the response from the IDP.
 

Reusable Authorization Codes:
Test to see if an RP will let a person 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 lead to 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 Stream, and validate that the returned code is totally different from the code acquired in step 1.
Substitute the returned code with the code saved in step 1.
Be 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 value checking on all main net frameworks. Typically net frameworks like Redux, React, and many others. could have an inner state which is accessible by means of the console or by means of net browser plugins.
Builders will often 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 means of these JavaScript objects. Check steps right here will differ per framework and implementation.
Implicit Grant Coercion:
This assault hardly ever works, however could also be value doing with extra obscure IDPs. The preliminary request from an RP to an IDP in Step 2. has an non-compulsory 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 remember.
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 means of the authorization stream, 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 fairly obscure assault, however could possibly be value making an attempt with doubtlessly insecure IDPs. If throughout 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 person instantly after they enter their credentials, it’s potential for an attacker working a malicious RP to steal the person’s credentials.
The 307 standing code could have the person’s Browser ship a POST request to the RP containing all the kind data, together with the person’s credentials!
Check Steps:

Choose an OAuth supplier, Begin Intercepting, Press Join Button.
Proceed by means of the authorization stream till the second when the person 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.
 

Afterword
OAuth is a fancy protocol with an unintuitive specification. As an attacker, this interprets to widespread 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’ve got feedback about this text, please be at liberty to achieve out. I wish to hear what you assume! If you wish to learn extra of my content material, view the archive on my private web site, subscribe to my publication, or assist me on Ko-Fi (not affiliated with Safety Innovation).
Assets and References:
Sensible Exploitation:
If you wish to examine real-world exploitation of various OAuth bugs listed here are just a few from the professional in OAuth hacking:

http://weblog.intothesymmetry.com/2016/11/all-your-paypal-tokens-belong-to-me.html
http://weblog.intothesymmetry.com/2015/06/on-oauth-token-hijacks-for-fun-and.html
http://weblog.intothesymmetry.com/2015/10/on-oauth-token-hijacks-for-fun-and.html
http://weblog.intothesymmetry.com/2014/04/oauth-2-how-i-have-hacked-facebook.html
http://weblog.intothesymmetry.com/2014/04/oauth-2-how-i-have-hacked-facebook.html

Further Assets

https://arxiv.org/pdf/1601.01229 — Extremely advocate 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 a variety of helpful assaults
https://dhavalkapil.com/blogs/Attacking-the-OAuth-Protocol/
https://homakov.blogspot.com/2014/02/how-i-hacked-github-again.html
https://gist.github.com/mziwisky/10079157
https://www.manning.com/books/oauth-2-in-action
http://homakov.blogspot.com/2012/08/oauth2-one-accesstoken-to-rule-them-all.html
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