Insecure Design
Brute-forcing Password Reset Token with BurpSuite
Many web applications implement password reset functionality using short numeric tokens sent to a user's email address. If the reset workflow is not designed with protections such as rate limiting, expiration controls, or attempt restrictions, attackers can repeatedly guess the token until the correct value is found.
In this lab, you will access a user profile containing basic account information such as username, email, and password reset functionality. Using Burp Suite Intruder, you will intercept the password reset verification request and automate thousands of guesses against a 6-digit reset token. Because the application allows unlimited attempts, the attacker can eventually discover the correct code and change the user's password — demonstrating how missing abuse protections can lead to full account takeover.
To begin, click the button below to access the demo user's profile page. The objective is to brute-force the reset token and modify the account password without having access to the user's email inbox.
Insecure Design Explained
Cryptographic Failures occur when an application improperly implements encryption, hashing, or signing, resulting in exposure or manipulation of sensitive data. One common example is the use of weak or exposed signing keys, which allow attackers to forge trusted values such as authentication cookies, password reset tokens, or API parameters
Applications often rely on cryptographic signing to ensure that client-side data has not been tampered with. However, if the signing key becomes exposed through source code repositories, configuration files, version control history, or backup files, attackers can generate valid signatures for modified data. Because the server trusts correctly signed values, this can lead to authentication bypass or privilege escalation
Attackers may exploit exposed signing keys to:
- modify authentication cookies
- impersonate other users
- escalate privileges
- bypass access control checks
- forge password reset tokens
- tamper with API requests parameters
Common causes of cryptographic failures include:
- hard-coded secrets in source code
- exposed .env and configuration files
- commiting keys to Git repositories
- weak or predictable secret keys
- reusing development keys in production
- misunderstanding the difference between signing and encryption.
Signing protects integrity but does not hide the data. If sensitive values are stored client-side without encryption, attackers may be able to read or manipulate them
Secure Approach
Secure implementations protect cryptographic secrets using environment variables or secret managers and avoid storing sensitive authorization data in client-controlled locationsSecure implementations protect cryptographic secrets using environment variables or secret managers and avoid storing sensitive authorization data in client-controlled locations.
Key takeaway: Cryptography only works if secrets remain secret. Protect signing keys, rotate compromised secrets, and never trust client-side data for authorization decisions without proper server-side validation.