Sessionless is a Burp Suite extension for editing, signing, verifying and attacking signed tokens: Django TimestampSigner, ItsDangerous Signer, Express cookie-session middleware, OAuth2 Proxy and Tornado’s signed cookies. It provides automatic detection and in-line editing of token within HTTP requests/responses and WebSocket messages, signing of tokens and automation of brute force attacks against signed tokens implementations. It was inspired by Fraser Winterborn and Dolph Flynn JWT Token extension. The original source code can be found here and here. If you would like to test it, source code can be found at the Github repository


If you haven’t already, please take a look at previous research, it will give you more information about the vulnerabilities. Here we will talk only about the technology that can be used to simplify the process of exploitation of unknown signed tokens. At the first part of the article we will explain different key derivations techniques used by those libraries. Second part of the article will cover common attack strategies.

Key derivations

A simple signing algorithm can be presented with the following code:

public byte[] get_signature_bytes(byte[] value) {
    try {
        byte[] key = derive_key();
        SecretKeySpec signingKey = new SecretKeySpec(key, algorithm);
        Mac mac = Mac.getInstance(algorithm);
        return mac.doFinal(value);
    } catch (Exception e) {
        return new byte[] {};

The length of the signature provides the attacker with information about the potentially used HMAC algorithm; for instance, HmacSHA1 has a signature length of 20 bytes. Unfortunately, obtaining details about the utilized derive_key function is not straightforward. In certain implementations, like Tornado’s signed cookies, no derive_key function is employed. However, others do utilize it. The ItsDangerous’s derive_key function states: This method is called to derive the key. The default key derivation choices can be overridden here. Key derivation is not intended to be used as a security method to make a complex key out of a short password. Instead you should use large random secret keys.This function supports four key derivation methods: concat, django, hmac and none. The first method simply combines the salt and password for key generation. The second method, borrowed from the Django Signer function, concatenates the salt with the string constant signer and then appends the password for key generation. HAMC and None perform their intended functions precisely. In summary, if the goal is to brute force the password used for key generation, one should iterate through all the supported HMAC algorithms and then utilize different key derivation methods. As an additional step, PBKDF1 and PBKDF2 key derivation functions can used. However, it’s important to note that they may negatively impact performance, so caution is advised. The Unknown tab can be utilized to automate the process:

Brute force attack with Unknown tab

Successful attack on OAuth2 signed token

Brute force

The Sessionless extension supports a number of signed tokens: Django, Dangerous, Flask, Express, OAuth2 and Tornado. It allows modification of the signed tokens at Burp Suite’s HTTP Request/Response view in the Proxy, History and Repeater tools. Brute force button will attempt to find secret key that was used for signature generation. Extension allows to import secrets and salts files. Extension has own prebuild dictionary lists. Most secrets are taken from jwt-secrets. As an option, Flask-Unsign-Wordlist can be used. Extension supports JSON strings format for special chars, to use it quot the secret string with "

Brute force attack

The Brute force option implements three types of attacks against signed tokens Signatures:


A potentially vulnerable token should store the session or sensitive data on the client within a cookie or a parameter. The Sessionless extension Attack option implements eight well-known authorization attacks against signed tokens:

All of these attacks can be used together. Please bear in mind that extension doesn’t support token payload modification at Attack mode, so your payload will be replaced with new one. These options are described in more detail below.

User claims

OpenID connect ID token format usually used by signing libraries to store information about authenticated user. Extension will generate placeholder for admin user ID token.

Wrapped user claims

Same as User claims attack but will put it into user JSON attribute.

Username and password claims

Another common way to store user details is username and password JSON attributes. Extension will generate placeholder for admin user.

Flask claims

Flask authenticated user session information if stored at client side should include id and _id and user_id or _user_id JSON attribute. Extension will generate session for the first user, usually admin.

Express claims

Express framework uses passport JSON attribute to store user details. Extension will generate placeholder for admin user.

Account user claims

Some frameworks may use account wrapper to store information about authenticated user. For exploitation, it might be required to use Authenticated claims too.

Authenticated claims

The Authenticated claims implements 12 well-known authorization flags.

User access_token

The User access_token option generated JWT OpenID connect ID token signed with the same key and same hashing algorithm without any key derivation preformed.




The Sessionless provides a convenient way to edit, sign and attack of the signed tokens at Burp Suite’s HTTP Request/Response. However, there is a number of impoovements that can be done: