Burp Suite’s Sequencer tool doesn’t just check if tokens are random; it actively hunts for predictable patterns that attackers can exploit to guess them.
Let’s see it in action. Imagine you’re testing a web application that uses a session token in its URL, like https://example.com/app?sessionid=a3f7b1d9c2e8a1b0d3c7e9f2a4b1c0d5. You’ve intercepted a few of these requests with Burp Proxy and sent them to the Sequencer.
Here’s what you’d see in Burp’s Sequencer tab. You’d load your captured tokens into the "Live capture" or "Load from file" section. Burp will then present a series of statistics and plots. The most critical initial check is the "Length analysis." If the token length varies significantly, it’s a good sign. If it’s consistently the same, that’s a minor weakness, but not fatal.
Next, the "Character distribution" is key. It shows you how often each possible character appears in your tokens. For a truly random token, you’d expect a fairly even distribution across all allowed characters (e.g., if it’s hexadecimal, roughly 1/16th of tokens should start with '0', 1/16th with '1', and so on). A skewed distribution, where certain characters appear far more or less often than expected, is a major red flag, indicating a non-uniform generation process.
Burp’s core strength here is the "Prediction analysis." This is where it runs a battery of statistical tests to see if it can predict the next token based on previous ones. You’ll see metrics like "Gaps," "Runs," and "Ranks." A low "Gaps" or "Runs" count, and a high "Ranks" value, suggest strong randomness. Conversely, if Burp can predict a significant percentage of your tokens (indicated by a high "Prediction likelihood" percentage), your token generation is fundamentally flawed.
The "Frequency analysis" within prediction analysis is particularly telling. If Burp can identify a pattern in how often specific characters or character pairs appear, it means the token generator isn’t truly independent. For instance, if after seeing a3f, Burp can predict that the next character is statistically likely to be 7, that’s a direct vulnerability.
To build a mental model, think of token generation like rolling dice. A fair die has an equal chance of landing on any face. A biased die will favor certain numbers. Burp’s Sequencer is like a super-powered observer who rolls your application’s "dice" thousands of times and meticulously records the results, looking for any hint of bias or predictability. It doesn’t just check if the numbers look random; it checks if they behave randomly under statistical scrutiny.
The "Entropy" calculation is also vital. Entropy measures the amount of randomness or unpredictability in your token. Higher entropy is better. If your tokens have low entropy, it means there are fewer possible combinations than there should be for their length, making them easier to brute-force.
The levers you control are in the application’s token generation logic. Are you using a cryptographically secure pseudo-random number generator (CSPRNG)? Are you seeding it properly, ideally with a strong source of entropy like /dev/urandom on Linux, rather than something predictable like the system time? Is the token length sufficient? Is the character set appropriate and used uniformly?
Most people focus on the overall length and character set, assuming that if they’re "good enough," the token is secure. They often overlook the subtle correlations and sequential dependencies that Burp’s advanced statistical tests can uncover. For example, a token might appear to have a good character distribution and length, but if the algorithm uses a weak seeding mechanism, the sequence of tokens generated might still exhibit discernible patterns when analyzed over time.
The next step after analyzing token randomness is to investigate how these tokens are transmitted and handled by the server, looking for issues like token leakage or insecure storage.