Technology / Standard Wise Checklist
A curated and comprehensive technology / standard wise checklist for Web Application Penetration Testing.
OAUTH
Oauth Client
CSRF - Ensure the State parameter is validated when the authorization code is received. Ref
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
Oauth Authorization Server
CSRF on authorization endpoint Ref
Ensure the authorization code cannot be used more than once.
Race condition provides more than one access_token for a single authorization code. Ref
Access Control - Ensure only the requested scope is provided to the token. Ref
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
CVE-2021-26715: SSRF via "logo_uri" in MITREid Connect Ref
"redirect_uri" Session Poisoning Ref
CVE-2021-27582: [MITREid Connect] "redirect_uri" bypass via Spring autobinding Ref
Check for sensitive information disclosure via the endpoint .well-known/openid-configuration Ref
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)
JWT - JSON Web Token
Simple Checks
Is the JWT Token required ? Send the request without JWT token to verify this.
Is the JWT Token checked ? Send the JWT by deleting few bytes of signature.
How long is the JWT Valid ? Specific time or until logout, etc.
Check if the JWT is generated from the client side or from the server side.
Is the signature being verified properly or the claims are processed before signature verification? Send the JWT by deleting few bytes of signature.
Bruteforce Weak HMAC Secret.
Algorithm and Signature Checks
'none' Algorithm
RSA Key Confusion Attack (CVE-2016-5431) (https://blog.pentesteracademy.com/hacking-jwt-tokens-verification-key-mismanagement-iii-7581805f4d58)
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)
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
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
Last updated