Brief

Define Cookies attributes

WSTG - Stable | OWASP Foundation

Restrict access to cookies

• Secure

  • Only sent to the server with an encrypted request over HTTPS, never sent with HTTP.

• HTTPOnly

  • Inacessible to Javascript document.cookie API; only sent to the server, helps mitigate XSS attacks.

• Path

  • Limits the scope of a cookie to a specific path on the server and can therefore be used to prevent unauthorized access to it from other applications on the same host.

Define where cookies are sent

• SameSite

  • The SameSite attribute lets servers specify whether/when cookies are sent with cross-site requests (where Site is defined by the registrable domain). This provides some protection against cross-site request forgery attacks (CSRF).

  • It takes three possible values: Strict, Lax, and None.

Cookies prefixes

Using HTTP cookies - HTTP | MDN

Brief

JSON web tokens (JWTs) are a standardized format for sending cryptographically signed JSON data between systems. They can theoretically contain any kind of data, but are most commonly used to send information ("claims") about users as part of authentication, session handling, and access control mechanisms.

Unlike with classic session tokens, all of the data that a server needs is stored client-side within the JWT itself. This makes JWTs a popular choice for highly distributed websites where users need to interact seamlessly with multiple back-end servers.

A JWT consists of 3 parts: a header, a payload, and a signature. These are each separated by a dot, as shown in the following example:

The header and payload parts of a JWT are just base64url-encoded JSON objects. The header contains metadata about the token itself, while the payload contains the actual "claims" about the user. For example, you can decode the payload from the token above to reveal the following claims:

{
    "iss": "portswigger",
    "exp": 1648037164,
    "name": "Carlos Montoya",
    "sub": "carlos",
    "role": "blog_author",
    "email": "carlos@carlos-montoya.net",
    "iat": 1516239022
}

In most cases, this data can be easily read or modified by anyone with access to the token. Therefore, the security of any JWT-based mechanism is heavily reliant on the cryptographic signature.

Signature part

The server that issues the token typically generates the signature by hashing the header and payload. In some cases, they also encrypt the resulting hash. Either way, this process involves a secret signing key. This mechanism provides a way for servers to verify that none of the data within the token has been tampered with since it was issued:

• As the signature is directly derived from the rest of the token, changing a single byte of the header or payload results in a mismatched signature.

• Without knowing the server's secret signing key, it shouldn't be possible to generate the correct signature for a given header or payload.

Particularities

In other words, a JWT is usually either a JWS or JWE token. When people use the term "JWT", they almost always mean a JWS token. JWEs are very similar, except that the actual contents of the token are encrypted rather than just encoded.

Aim

JWT attacks involve a user sending modified JWTs to the server in order to achieve a malicious goal. Typically, this goal is to bypass authentication and access controls by impersonating another user who has already been authenticated.

The impact of JWT attacks is usually severe. If an attacker is able to create their own valid tokens with arbitrary values, they may be able to escalate their own privileges or impersonate other users, taking full control of their accounts.

Flawed Signature Verification

For example, consider a JWT containing the following claims:

{
    "username": "carlos",
    "isAdmin": false
}

Changing the parameter "isAdmin" to true : Privilege Escalation.

JWT libraries typically provide one method for verifying tokens and another that just decodes them. For example, the Node.js library jsonwebtoken has verify() and decode(). Occasionally, developers confuse these two methods and only pass incoming tokens to the decode() method. This effectively means that the application doesn't verify the signature at all.

Accepting Tokens with No Signature

{
    "alg": "HS256",
    "typ": "JWT"
}

Change the "alg" value to "none". Remove the signature part but leave the trailing dot ".".

Even if the token is unsigned, the payload part must still be terminated with a trailing dot.

Brute-forcing Secret Keys

Some signing algorithms, such as HS256 (HMAC + SHA-256), use an arbitrary, standalone string as the secret key. Just like a password, it's crucial that this secret can't be easily guessed or brute-forced by an attacker. Otherwise, they may be able to create JWTs with any header and payload values they like, then use the key to re-sign the token with a valid signature.

When implementing JWT applications, developers sometimes make mistakes like forgetting to change default or placeholder secrets. They may even copy and paste code snippets they find online, then forget to change a hardcoded secret that's provided as an example. In this case, it can be trivial for an attacker to brute-force a server's secret using a wordlist of well-known secrets.

JWT Wordlist : https://github.com/wallarm/jwt-secrets/blob/master/jwt.secrets.list$

If the server uses an extremely weak secret, it may even be possible to brute-force this character-by-character rather than using a wordlist.

How to

hashcat -a 0 -m 16500 $JWT $wordlist
# --show to output the result if you already run it

Then : Generate another key using JWT Editor Keys on BurpSuite, change the "k" parameter to the base64-encoded secret. Start accessing admin panels.

Tools

JWT Toolkit V2

GitHub - ticarpi/jwt_tool: A toolkit for testing, tweaking and cracking JSON Web TokensGitHub

git clone https://github.com/ticarpi/jwt_tool
cd jwt_tool/
python3 -m pip install termcolor cprint pycryptodomex requests
python3 jwt_tool.py $JWT