Welcome to the Authentication Lab, a place to play with some common, and some not so common, authentication and authorisation vulnerabilities.
I intend to grow the collection below as I come across new vulnerabilities while on client tests and as new ones are reported in the news. If you have something you would like to see added, let me know and I'll see what I can do. The more information you can give me the better but I'll look at anything that seems interesting.
Each lab is stand alone and none of them, so far, require any special tools to complete the challenge. If you get stuck, or want more information, check out my Authentication Lab Walkthroughs post.
Find the deliberate IP based authentication bypass.
Sometimes even the best login system can leak information through side-channels.
Never trust anything coming from the user, especially authentication.
See how easy it is to leak information in a JWT.
Sometimes all it takes is a little information disclosure to break an authentication system.
Most JWT libraries allow you to choose either RSA or HMAC for signature verification however the spec allows for "None" to be specified meaning there is no signature in use.
Most clients that talk to web apps will send a user agent string, unfortunately, some apps rely on this as a way to differentiate different type of user and allocate permissions based on it.
jwt-go before 4.0.0-preview1 allows attackers to bypass intended access restrictions in situations with []string{} for m["aud"] (which is allowed by the specification). Because the type assertion fails, "" is the value of aud. This is a security problem if the JWT token is presented to a service that lacks its own audience check. Taken from NIST CVE description
The JSON Web Signature (JWS) standard allows tokens to carry their own cryptographic verification key directly within the jwk header parameter. In this challenge, explore how an application that blindly trusts this header without validating against an authoritative public key store lets an attacker embed their own public key, sign an elevated payload, and achieve total authentication bypass.
Exploit an unvalidated jku header to make the server fetch public keys from an attacker-controlled JWKS endpoint.
Take advantage of algorithm confusion by using a published public key as a symmetric key to sign the JWT using HS256 rather then RS256.
Lab created by Robin Wood - DigiNinja