Day 40/100 Hack and Improvement

1 minute read

Day 40 comes with JWT attacks and XSS based on POST request!

KID manipulation in JWT

From Rajesh Ranjan. According to Stackoverflow The kid (key ID) Header Parameter is a hint indicating which key was used to secure the JWS. This parameter allows originators to explicitly signal a change of key to recipients. The structure of the kid value is unspecified. Its value MUST be a case-sensitive string. Use of this Header Parameter is OPTIONAL

if in the web application, the kid is used without proper escaping to retrieve the key. This lack of escaping could lead to multiple types of vulnerabilities like

  • Sql injection
  • Directory Traversal

A normal KID looks like

{
"alg" : "HS256",
 "typ" : "JWT",
 "kid" : "1"       // use key number 1 to verify the token 
}
  • Directory traversal Since the KID is often used to retrieve a key file from the file system, if it is not sanitized before use, it can lead to a directory traversal attack. When this is the case, the attacker would be able to specify any file in the file system as the key to be used to verify the token.
    “kid”: “../../public/css/main.css” 
    // use the publicly available file main.css to verify the token
    
  • SQL Injection

The KID could also be used to retrieve the key from a database. In this case, it might be possible to utilize SQL injection to bypass JWT signing. If SQL injection is possible on the KID parameter, the attacker can use this injection to return any value she wants

“kid”: "aaaaaaa' UNION SELECT 'key';--"
// use the string "key" to verify the token

For example, this above injection will cause the application to return the string “key” (since the key named “aaaaaaa” doesn’t exist in the database). The token will then be verified with the string “key” as the secret key.

Source: https://medium.com/swlh/hacking-json-web-tokens-jwts-9122efe91e4a There is an exercise on Pentesterlab, related to this kid. check that out here

Post-Based XSSI

From Sam (CoffeeJunkie). One of the private programs where I am currently participating has a lot of input places. Therefore, one of my persuing for the week would be XSS if possible and other vulnerabilities. Therefore I wanted to be deep in XSS material in order to have a successful journey during hunting.

From the resource. It explains that client-side attacks are dying due to new browser features and configurations. Saying that XSS will not be satisfied in GET request, therefore will be pretty amazing to expand to POST requests.

The idea of doing this is to intercept the request, modify the send no-cors POST request. Then, things to look here is look for vulnerable endpoints that will return valid Javascript content.

Leave a comment