# Client ## Intro The OAuth ecosystem is complex. As a developer, you should follow the OAuth core specification as best as you can. Additionally, some tutorials from the OAuth community may be helpful to get into the topic. If you are particularly keen on security, there is the "OAuth 2.0 Threat Model and Security Considerations specification" ([RFC 6819](https://datatracker.ietf.org/doc/html/rfc6819)). That is a useful resource to improve your knowledge and understanding of how you can properly carry on attacks or defend OAuth entities. ## Account Takeover The typical scenario for this attack requires that the target website allows logging in either via email registration or via OAuth through multiple providers. It is even possible to face another scenario where the end-user can link his account to a third-party account in his profile page (i.e. Facebook, Linkedin, Google and so on) once he's already signed up. *1° Scenario* : Register a new account with the victim's email on the target website. From this time, you own the credentials but still not the account takeover, because an email verification will be probably required. When the victim registers himself/herself by using OAuth (with Facebook or Google, for example), this authorization will bypass the verification required and you will have another way to log in with the victim's account. | Functional Requirements | | ------------------------------- | | Multiple Authentication Methods | *2° Scenario* : First of all, this scenario depends on how the website manages the linking process. It might use IDs parameters, xxx or yyy. What I can suggest, it's to see the workflow and try to find out if the process is flawed. For example, if IDs are used to tie the third-party profile to the account, try changing them with the victim's id, thus the victim will have his account tied to the attacker's account. | Functional Requirements | | ---------------------------------------------- | | Link a third-party Account in the profile page | *3° Scenario* : Register a new account on the Resource Server with the victim’s email (even if email verification is required), then log in to the target website via OAuth with the account just created (with the victim’s email) and see what the target website does. Obviously, the victim must have already a registered account on the website and signed up via email. If you’re lucky, it logs you in the victim's account. | Functional Requirements | | ---------------------------------- | | The victim signed up by email | | The victim didn't sign up by OAuth | ### Defence **1° and 2°Scenario**: Require that the email verification is completed before logging in to the user. Otherwise, either don't let the user enter with OAuth when there's already another account created with the same email or let the user enter, but let him know someone else has already created an account and if it was him or not then ask him to change the password. **3° Scenario**: This problem should not be fixed client-side but server-side. In fact, the RS should not allow using OAuth with an account not verified. But we trust no one, so to implement remediation, follow the previous one. **Reference** * 1° Scenario: * 2° Scenario: ## CSRF Sed ipsum felis, fringilla ut mattis non, sodales nec lectus. Morbi volutpat tortor at leo euismod, id lobortis ligula sodales. ### Defense test ## OAuth Misconfigurations Sed ipsum felis, fringilla ut mattis non, sodales nec lectus. Morbi volutpat tortor at leo euismod, id lobortis ligula sodales. ### Client Credentials Sed ipsum felis, fringilla ut mattis non, sodales nec lectus. Morbi volutpat tortor at leo euismod, id lobortis ligula sodales. #### Defence test ### Redirect URI Sed ipsum felis, fringilla ut mattis non, sodales nec lectus. Morbi volutpat tortor at leo euismod, id lobortis ligula sodales. #### Defence test ### OAuth Flow Misconfigurations Sed ipsum felis, fringilla ut mattis non, sodales nec lectus. Morbi volutpat tortor at leo euismod, id lobortis ligula sodales. #### Flow Change Sed ipsum felis, fringilla ut mattis non, sodales nec lectus. Morbi volutpat tortor at leo euismod, id lobortis ligula sodales. #### Defence test #### Improper Impletation Implicit Flow Sed ipsum felis, fringilla ut mattis non, sodales nec lectus. Morbi volutpat tortor at leo euismod, id lobortis ligula sodales. #### Defence test ## Tokens ### Token Stealing Vectors Sed ipsum felis, fringilla ut mattis non, sodales nec lectus. Morbi volutpat tortor at leo euismod, id lobortis ligula sodales. #### Defence test ### Token Hijacking | Limitation | | ---------- | \| Only tested for Facebook | | Need to have access to the token | From Facebook Documentation: > To understand how this happens, imagine a native iOS app that wants to make API calls, but instead of doing it directly, communicates with a server owned by the same app and passes that server a token generated using the iOS SDK. The server would then use the token to make API calls. The endpoint that the server uses to receive the token could be compromised and others could pass access tokens for completely different apps to it. This would be obviously insecure It's only possible to verify this vulnerability if you can control and have access to the ***access\_token***. Check if the client is validating the token issued by the AS (precisely the Token endpoint), examining if it was issued for ONLY the client itself. If not, an attacker can use a victim’s access token issued for other clients to log in as the victim himself. To do so, replace the access\_token with another one issued by another application (client). #### Defence Access tokens should never be assumed to be from the app that is using them. The client must check which client the token has been issued for. **Reference** * ### Token Leakage If you can check in the client side, the token should never be sent via GET method . #### Defence Send the token in the request body ### Lack Of Refresh Token Sed ipsum felis, fringilla ut mattis non, sodales nec lectus. Morbi volutpat tortor at leo euismod, id lobortis ligula sodales. #### Defence test --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://oauth.oia.ovh/master.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.