# Flawed Signature Verfication

> Servers don't store any JWT-related information, thus, they don't know anything about its contents.&#x20;

## Accepting Arbitrary Signatures

JWT libraries usually provide 2 methods, one for verification and one for decoding. For example, Node.js's `jsonwebtoken` library has the `verify()` and `decode()` methods. If a developer only use the latter the application won't verify the signature at all.

### LAB: JWT Authentication Bypass via Unverified Signature

> **Goal**: Modify your session token to gain access `/admin` and then delete the user `carlos`.

<figure><img src="https://3960676229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmjLkek16kB60c2WFd5lf%2Fuploads%2FkpKBYUxsRXTL106cxeia%2Fjwt_unverified_signature.png?alt=media&#x26;token=92189210-c1df-431e-9094-b1be17d8e6ea" alt=""><figcaption></figcaption></figure>

## Accepting Tokens Without Signature

The JWT header contains an `alg` parameter which tells the server which algorithm was used to sign the token, i.e., which alogirthm it needs to use when veryfing the signature. This is inherently flawed as it is user-controlled. JWTs can be also left unsigned using `"alg":"none"`, aka *unsecure JWT*. Servers usually reject this tokens, but since this relies on string parsing, it can be obfuscated.

> Even if the token is unsigned, the payload part must end with a trailing dot.

### LAB: JWT Authentication Bypass via Flawed Signature Verification

> **Goal**: Modify your session token to gain access `/admin` and then delete the user `carlos`.

<figure><img src="https://3960676229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmjLkek16kB60c2WFd5lf%2Fuploads%2FxRDMdD7KHo5XDdDbRd6z%2Fjwt_flawed_signature_verification.png?alt=media&#x26;token=fb0451a9-72fa-449b-a3cb-f38132963a48" alt=""><figcaption></figcaption></figure>
