Fix Kyle's typo lol

squ1rrel-ctf · Sep 10, 2024 · 545a04f · 545a04f
1 parent bcc0cd0
commit 545a04f
Showing 1 changed file with 1 addition and 1 deletion.
diff --git a/_posts/2024-09-09-csaw-lost-pyramid.md b/_posts/2024-09-09-csaw-lost-pyramid.md
@@ -27,7 +27,7 @@ Lovely. There are a few other rooms, the most notable of which allows you to pro
 
 ## My Approach
 
-Approaching this problem, I was thinking about 1 think and 1 thing only: JWTs, or JSON Web Tokens. JWTs are a way to securely send information from one place to another. A JWT contains a header (containing metadata about the token), a payload (containing the information that needs to be sent), and a signature (the result of signing the base64-encoded header and payload with a secret key and an algorithm specificed in the header). All this is cool and all, but how can we find a vulnerability here? Akash pointed out that the version of PyJWT specified in the `requirements.txt`, `2.3.0`, has a known vulnerability, described [here](https://github.com/jpadilla/pyjwt/security/advisories/GHSA-ffqj-6fqr-9h24). 
+Approaching this problem, I was thinking about 1 thing and 1 thing only: JWTs, or JSON Web Tokens. JWTs are a way to securely send information from one place to another. A JWT contains a header (containing metadata about the token), a payload (containing the information that needs to be sent), and a signature (the result of signing the base64-encoded header and payload with a secret key and an algorithm specificed in the header). All this is cool and all, but how can we find a vulnerability here? Akash pointed out that the version of PyJWT specified in the `requirements.txt`, `2.3.0`, has a known vulnerability, described [here](https://github.com/jpadilla/pyjwt/security/advisories/GHSA-ffqj-6fqr-9h24). 
 
 
 In Lost Pyramid, we have a private key and a public key for signing and verifying JWT tokens. The private key is, surprisingly, private, and is used to sign the token; the public key is used to verify that the private key was used to sign the token and therefore verify that the token was sent by someone we trust. What if, and hear me out, we trick the JWT decoder into thinking we are using a symmetric algorithm, which only requires one key? Then, we could sign the token with the public key, and it will be decoded also with the public key. This would be bad, since the public key is, well, public. That's where the vulnerability comes in.