Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

I Forgot Your Password

I'm now going into my second year in application security, and as I learn more and more, my favorite attacks are still some of the things I learned when I first began here in SpiderLabs. For example, using an application's "forgot password" functionality to hijack user accounts and be very rewarding and oftentimes yields critical information.

So let's dive in. Here's an example of how I might retrieve your password when I've "forgotten" it.

This is by far the most common mistake I see.


On the surface, this looks pretty good. You're not sending the user their password in plaintext. They have to use the forgot password form to generate an e-mail with a tokenized link. Using an invalid token will render the page useless, and maybe it even only has a 30-minute time limit before the token expires.

My general approach is to self-register an account as User1, and then send myself a forgot password e-mail. However, while the token must be valid, what is oftentimes overlooked is whether or not the token has been specifically tied to my user. Let's say I copy the URL and make a slight modification:


And here we are, it now asks me to set a new password for User2. I change the password to 'password1', submit, and proceed to login to my new account.

Another variation of this is even more interesting. Let's say after modifying the URL, I receive this page:


While this big, scary error message may deter some, I've seen instances where the application recognizes that something is amiss, but still allows an attacker to continue.

8848_3d310496-11f9-4345-becc-50c72d05cc3aThis looks bad. But if I try my new password…


There are a few steps we could take to remediate this vulnerability. First, the developers can tie the token to the user account. The error message implied that the developers started to do that, but didn't enforce it properly. The developers should also remove the username from the process altogether, by sending a link that only includes a token and matches it to the correct username on the server-side. Lastly, while error messages can serve many purposes, security should not be one of them. Double-check your code to make sure that it's not only verifying that the two parameters match, but that the process is stopped if they do not. Any good attacker, or pentester, will follow the process through regardless of what the application tells him or her, just to see what happens.

One of my favorite things about hijacking user accounts is that vulnerabilities present in user-management portions of the application suddenly become critical issues. If your application doesn't mask a user's credit card number or SSN on a "My Account" page, it's bad practice. If I can log into your account, it becomes a serious vulnerability. Even if information is masked properly, if the application allows you store your billing information, I don't need it in order to buy myself something nice. A wealth of other information is also suddenly opened up to an attacker if they can hijack user accounts. Your customer's names, addresses, phone numbers, purchase histories, and possibly even medical information, are suddenly available for the curious and malicious alike.

Latest SpiderLabs Blogs

Hunting For Integer Overflows In Web Servers

Allow me to set the scene and start proceedings off with a definition of an integer overflow, according to Wikipedia:

Read More

Welcome to Adventures in Cybersecurity: The Defender Series

I’m happy to say I’m done chasing Microsoft certifications (AZ104/AZ500/SC100), and as a result, I’ve had the time to put some effort into a blog series that hopefully will entertain and inform you...

Read More

Trustwave SpiderLabs: Insights and Solutions to Defend Educational Institutions Against Cyber Threats

Security teams responsible for defending educational institutions at higher education and primary school levels often find themselves facing harsh lessons from threat actors who exploit the numerous...

Read More