Hacking OAuth Applications

Transcript

1. Hacking OAuth Application BY: TUSHAR VERMA
2. WHOAMI Application Security Engineer(Shaadi.com) Synack Red Team Member Bug Bounty Hunter
3. What is Oauth 2.0 OAuth 2.0, which stands for “Open Authorization”, is a standard designed to allow a website or application to access resources hosted by other web apps on behalf of a user. OAuth 2.0 provides consented access and restricts actions of what the client app can perform on resources on behalf of the user, without ever sharing the user's credentials.
4. Principles of OAuth2.0 OAuth 2.0 is an authorization protocol and NOT an authentication protocol. As such, it is designed primarily as a means of granting access to a set of resources, for example, remote APIs or user’s data. OAuth 2.0 uses Access Tokens. An Access Token is a piece of data that represents the authorization to access resources on behalf of the end-user. OAuth 2.0 doesn’t define a specific format for Access Tokens. However, in some contexts, the JSON Web Token (JWT) format is often used.
5. OAuth 2.0 roles Resource Owner - an entity that can grant access to a protected resource; typically this is the end-user. Resource Server - the server hosting the protected resources; this is the API you want to access. Client - an application requesting access to a protected resource on behalf of the resource owner. Authorization Server - the server that authenticates the resource owner, and issues access tokens after getting proper authorization.
6. OAuth Flows (Grant Types) Authorization code grant (server side flow) Implicit Grant (Client side flow) Resource credentials grant Client credential grant
7. Protocol flow……………
8. OAuth 2.0 endpoints Authorization endpoint Token endpoint
9. Authorization endpoint The authorization endpoint is used to interact with the resource owner and get the authorization to access the protected resource. The request parameters of the authorization endpoint are: •response_type-tells the authorization server which grant to execute. •client_id-the id of the application that asks for authorization. •redirect_uri-holds a URL; a successful response from this endpoint results in a redirect to this URL. •scope-a space-delimited list of permissions that the application requires. •state-is a parameter that allows you to restore the previous state of your application; the state parameter preserves some state object set by the client in the authorization request and makes it available to the client in the response.
10. Token Endpoint The token endpoint is used by the client to obtain an access token by presenting its authorization grant or refresh token
11. OAuth Vulnerabilities Improper implementation of the implicit grant type Flawed CSRF protection Leaking authorization codes and access tokens Flawed scope validation Unverified user registration Host header injection Reusable OAuth access token
12. Practical Time
13. Improper implementation of the implicit grant type Once the OAuth provider sent the access_token to the client application, application has to maintain a session. To achieve this, client application will often submit this data to the server in a POST request and then assign the user a session cookie, effectively logging them in similar to traditional password-based login. However, the server doesn’t have any secrets or password to compare with the data submitted by client application, which means it is implicitly trusted. What we can do?? In this situation, attacker can simply change the parameters sent to the server to impersonate any user as access token is valid.
14. Flawed CSRF protection If the authorization request does not send a state parameter, this is extremely interesting from an attacker's perspective. It means that they can initiate an OAuth flow themselves before tricking a user’s browser into completing it.
15. Open Redirection at redirect_uri parameter When redirect_uri is not checked properly by the OAuth provider, it possible for an attacker to steal authorization codes associated with other users’ accounts. The code or access tokens can be redirected to attacker control website and can be used for further completion of the flow.
16. Bypass the validations Attacker can try @ (https://expected-host@evil-host)and #(https://evil-host#expected-host) characters in the redirect_uri parameter. Attacker might be able to exploit discrepancies between the parsing of the URI by the different components of the OAuth service. For example, you can try techniques such as- https://default-host.com &@foo.evil-user.net#@bar.evil-user.net/ Attacker can try parameter pollution vulnerabilities by submitting duplicate redirect_uri parameters as follows- https://oauth- authorization-server.com/?client_id=123&redirect_uri=client- app.com/callback&redirect_uri=evil-user.net Attacker can try localhost URIs as they’re often used during development. This could allow you to bypass the validation by registering a domain name such as localhost.evil-user.net
17. Flawed scope validation Every time when user login to the authorization server, they will be presented with a list of data that the client application wants to access (Like Email, profile picture). With the authorization code grant type, the user’s data is requested and sent via secure server-to-server communication. For attacker it is impossible to manipulate directly. However attacker can register their own client application with the OAuth service. For the implicit grant type, the access token is sent via the browser. Attackers can steal tokens and use them directly by sending a normal browser-based request to the OAuth endpoint, manually adding a new scope parameter in the process.
18. Unverified user registration Some websites that provide an OAuth service allow users to register an account without verifying all of their details, including their email address in some cases. Attacker can exploit this by registering an account with the OAuth provider using the same details as a target user, such as a known email address and sign in as the victim via this fraudulent account with the OAuth provider.
19. Host header injection If the host is not being validated at the server, there is possibility to redirect the token to malicious host via host header injection. GET /api/twitter/login?csrf=token HTTP/1.1 Host: attacker.com/victim.org Referer: https://www.victim.org/ Cookie:cookie As we changed the host header, it will redirect Oauth authorization link to the attacker’s host and leak the token that is issued
20. Reusable OAuth access token The token should expire from backend once user logs out from the application similar to the traditional session management functionality. If it is not the case it can be considered under bad security practices and can be exploited.
21. Get in touch at Twitter: @e11i0t_4lders0n LinkedIn: /in/tushars25 Instagram: @e11i0t_4lders0n__ Email: tushar.infosec@gmail.com
22. Thank You