# 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. 
* Ensure client secret is not disclosed. 
* Ensure PKCE is used in the case of mobile apps and SPA to prevent client secret from being leaked. 
* 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


---

# 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://hak2learn.gitbook.io/hak2learn/webapp/technology-standard-wise-checklist.md?ask=<question>
```

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.