# Technology / Standard Wise Checklist

### OAUTH

**Oauth Client**

* Account Take Over (Improper Email Verification)- When using ‘Sign in with *OTHER\_APP*’ ensure an un-verified account for that particular email address is not registered within the application. If registered, the password needs to be reset. [Ref1](https://hackerone.com/reports/1074047) [Ref2](https://hackerone.com/reports/922456)
* CSRF - Ensure the State parameter is validated when the authorization code is received.  [Ref](https://hackerone.com/reports/111218)
* In Authorization Code Grant, ensure the request to obtain auth code is happening through server-to-server communication.&#x20;
* Ensure client secret is not disclosed.&#x20;
* Ensure PKCE is used in the case of mobile apps and SPA to prevent client secret from being leaked.&#x20;
* Access Control - Ensure only the required scope is requested.
* Referrer Leakage using HTML Injection
* XSS in Oauth Parameters. [Ref](https://hackerone.com/reports/456333)

**Oauth Authorization Server**

* Open redirection through redirect\_uri leading to Oauth Token Compromise
  * Lack of whitelisted redirect\_uri. [Ref](https://hackerone.com/reports/665651)
  * Improper Implementation of whitelisting – Unicode characters bypass whitelisting, Invalid scope parameter bypasses whitelisting.  [Ref1](https://hackerone.com/reports/861940) [Ref2](https://hackerone.com/reports/3930)
* CSRF on authorization endpoint [Ref](https://hackerone.com/reports/215381)
* Ensure the authorization code cannot be used more than once.
* Race condition provides more than one access\_token for a single authorization code. [Ref](https://hackerone.com/reports/55140)
* Access Control - Ensure only the requested scope is provided to the token. [Ref](https://hackerone.com/reports/434763)
* XSS in Oauth Parameters
* Check for sensitive information disclosure via the endpoint .well-known/openid-configuration
* Check for dynamic registration endpoint /connect/register, /register [Ref](https://portswigger.net/research/hidden-oauth-attack-vectors)
* CVE-2021-26715: SSRF via "logo\_uri" in MITREid Connect [Ref](https://portswigger.net/research/hidden-oauth-attack-vectors)
* "redirect\_uri" Session Poisoning [Ref](https://portswigger.net/research/hidden-oauth-attack-vectors)
* CVE-2021-27582: \[MITREid Connect] "redirect\_uri" bypass via Spring autobinding [Ref](https://portswigger.net/research/hidden-oauth-attack-vectors)
* Check for sensitive information disclosure via the endpoint .well-known/openid-configuration [Ref](https://portswigger.net/research/hidden-oauth-attack-vectors)

### SAML

* Test whether or not the SP accepts an Assertion without a Signature (Signature Exclusion)
* Test whether or not the SP is susceptible to XML Signature Wrapping (XML Signature Wrapping)
* Test whether or not the SP verifies that the Assertion came from a trusted IdP (Certificate Faking)
* Test whether or not the SP creates more than a single session per Assertion (Assertion Replay - may or may not be considered a bug by itself)
* Test whether or not the SP is vulnerable to XXE
* Test whether or not the SP is vulnerable to XSLT
* If the target SP is serviced by an IdP to which you have a legitimate account on a different SP serviced by the same IdP, test whether or not the target SP accepts a valid Assertion meant for the valid SP (Token Recipient Confusion)
* Reference: <https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/>

### JWT - JSON Web Token

**Simple Checks**

* Is the JWT Token required ? Send the request without JWT token to verify this.&#x20;
* Is the JWT Token checked ? Send the JWT by deleting few bytes of signature.&#x20;
* How long is the JWT Valid ? Specific time or until logout, etc.&#x20;
* Check if the JWT is generated from the client side or from the server side.&#x20;
* Is the signature being verified properly or the claims are processed before signature verification? Send the JWT by deleting few bytes of signature.&#x20;
* Bruteforce Weak HMAC Secret.

**Algorithm and Signature Checks**

* 'none' Algorithm&#x20;
* RSA Key Confusion Attack (CVE-2016-5431) (<https://blog.pentesteracademy.com/hacking-jwt-tokens-verification-key-mismanagement-iii-7581805f4d58)&#x20>;
* JSON Web Key Set (JWKS) Injection (CVE-2018-0114) – When the public key is included as a part of the JWT, generate a new key pair. Replace the public key and replace the signature of the JWT with the signature signed with the generated key. (<https://blog.pentesteracademy.com/hacking-jwt-tokens-jws-standard-for-jwt-666810809323)&#x20>;
* null signature (CVE-2020-28042) – Delete the signature.

**Kid Checks**

* Check if Kid is a file location. See if the key file is accessible in the webserver /key/keyfile.pem
* Check if Kid is a file location. Change the kid to a file path that may contain predictable values, also check if SSRF is present&#x20;
* JWKS Spoofing - if the header “jku” contains the url to the key, change it to a user controlled url containing known keys.

**Reference**

* JWT Attacks and Tool Reference:  <https://github.com/ticarpi/jwt_tool/wiki/Attack-Methodology>

### CDN/Caching

* Web Cache Deception
* Web Cache Poisoning
