Dynamic Analysis
Investigate the following JWT vulnerabilities while performing dynamic analysis:
• Token Storage on the client:
– The token storage location should be verified for mobile apps that use JWT.
• Cracking the signing key:
– Token signatures are created via a private key on the server. After you obtain a JWT, choose a tool forbrute forcing the secret key offline.
• Information Disclosure:
– Decode the Base64Url-encoded JWT and find out what kind of data it transmits and whether that data is encrypted.
• Tampering with the Hashing Algorithm:
– Usage of asymmetric algorithms. JWT offers several asymmetric algorithms as RSA or ECDSA. When these algorithms are used, tokens are signed with the private key and the public key is used for verification. If a server is expecting a token to be signed with an asymmetric algorithm and receives a token signed with HMAC, it will treat the public key as an HMAC secret key. The public key can then be misused, employed as an HMAC secret key to sign the tokens.
– Modify thealgattribute in the token header, then deleteHS256, set it tonone, and use an empty signature (e.g., signature = ”“). Use this token and replay it in a request. Some libraries treat tokens signed with the none algorithm as a valid token with a verified signature. This allows attackers to create their own”signed” tokens.
There are two different Burp Plugins that can help you for testing the vulnerabilities listed above:
• JSON Web Token Attacker
• JSON Web Tokens
Also, make sure to check out theOWASP JWT Cheat Sheetfor additional information.
• Resource Owner: the account owner
• Client: the application that wants to access the user’s account with the access tokens
• Resource Server: hosts the user accounts
• Authorization Server: verifies user identity and issues access tokens to the application Note: The API fulfills both the Resource Owner and Authorization Server roles. Therefore, we will refer to both as the API.
Here is a moredetailed explanationof the steps in the diagram:
1. The application requests user authorization to access service resources.
2. If the user authorizes the request, the application receives an authorization grant. The au- thorization grant may take several forms (explicit, implicit, etc.).
3. The application requests an access token from the authorization server (API) by presenting authentication of its own identity along with the authorization grant.
4. If the application identity is authenticated and the authorization grant is valid, the autho- rization server (API) issues an access token to the application, completing the authorization process. The access token may have a companion refresh token.
5. The application requests the resource from the resource server (API) and presents the access token for authentication. The access token may be used in several ways (e.g., as a bearer token).
6. If the access token is valid, the resource server (API) serves the resource to the application.
OAUTH 2.0 Best Practices
Verify that the following best practices are followed:
User agent:
• The user should have a way to visually verify trust (e.g., Transport Layer Security (TLS) con- firmation, website mechanisms).
• To prevent man-in-the-middle attacks, the client should validate the server’s fully qualified domain name with the public key the server presented when the connection was established.
Type of grant:
• On native apps, code grant should be used instead of implicit grant.
• When using code grant, PKCE (Proof Key for Code Exchange) should be implemented to protect the code grant. Make sure that the server also implements it.
• The auth “code” should be short-lived and used immediately after it is received. Verify that auth codes only reside on transient memory and aren’t stored or logged.
Client secrets:
• Shared secrets should not be used to prove the client’s identity because the client could be impersonated (“client_id” already serves as proof). If they do use client secrets, be sure that they are stored in secure local storage.
End-User credentials:
• Secure the transmission of end-user credentials with a transport-layer method, such as TLS.
Tokens:
• Keep access tokens in transient memory.
• Access tokens must be transmitted over an encrypted connection.
• Reduce the scope and duration of access tokens when end-to-end confidentiality can’t be guaranteed or the token provides access to sensitive information or transactions.
• Remember that an attacker who has stolen tokens can access their scope and all resources associated with them if the app uses access tokens as bearer tokens with no other way to identify the client.
• Store refresh tokens in secure local storage; they are long-term credentials.
External User Agent vs. Embedded User Agent
OAuth2 authentication can be performed either through an external user agent (e.g. Chrome or Safari) or in the app itself (e.g. through a WebView embedded into the app or an authentication library). None of the two modes is intrinsically “better” - instead, what mode to choose depends on the context.
Using an external user agent is the method of choice for apps that need to interact with social media accounts (Facebook, Twitter, etc.). Advantages of this method include:
• The user’s credentials are never directly exposed to the app. This guarantees that the app cannot obtain the credentials during the login process (“credential phishing”).
• Almost no authentication logic must be added to the app itself, preventing coding errors.
On the negative side, there is no way to control the behavior of the browser (e.g. to activate certificate pinning).
For apps that operate within a closed ecosystem, embedded authenticationis the better choice.
For example, consider a banking app that uses OAuth2 to retrieve an access token from the bank’s authentication server, which is then used to access a number of micro services. In that case, credential phishing is not a viable scenario. It is likely preferable to keep the authentication process in the (hopefully) carefully secured banking app, instead of placing trust on external
Other OAuth2 Best Practices
For additional best practices and detailed information please refer to the following source docu- ments:
• RFC6749 - The OAuth 2.0 Authorization Framework (October 2012)
• RFC8252 - OAuth 2.0 for Native Apps (October 2017)
• RFC6819 - OAuth 2.0 Threat Model and Security Considerations (January 2013)