Website Security Flaws Exposed｜How Combined Vulnerabilities Compromise Protection
Discover how multiple merged vulnerabilities create critical website security risks and learn effective strategies to identify and mitigate these threats, enhancing your site's defense against attacks.
点击这里查看本文章简体中文版本。
點擊這裡查看本文章正體中文版本。
This post was translated with AI assistance — let me know if anything sounds off!
Revealing a Clever Website Vulnerability Discovered Years Ago
Website Security Issues Caused by Multiple Combined Vulnerabilities
{:target="_blank"}](/assets/142244e5f07a/1*EQPani1J-PTO-ccp588gBg.webp)
Photo by Tarik Haiga
Introduction
A few years ago, while still supporting web development, I was assigned to organize a CTF competition for the company’s internal engineering team. Initially, the plan was to divide teams based on company products for offense and defense challenges. However, as the organizer, I first conducted penetration tests on the company’s products to assess the security level. I wanted to see how many vulnerabilities I could find to ensure the event would run smoothly.
However, due to limited competition time and significant differences in engineering fields, the final questions focused on common engineering fundamentals and interesting topics. Interested readers can refer to my previous article “How to Create a Fun Engineering CTF Competition,” which contains many creative challenges!
Found Vulnerabilities
A total of four vulnerabilities were found across three products. In addition to the issues discussed in this article, I also discovered the following three common website vulnerabilities:
Never Trust The Client!
The problem is basic: the frontend sends the ID directly to the backend, and the backend accepts it without verification. This should be changed to validate a Token instead.Password Reset Design Flaw
I actually forgot the details, only remember there was a programming flaw; it allowed bypassing email verification during the password reset process.XSS Issue
Vulnerabilities Introduced in This Article
All searches are conducted as black-box testing. The only product in which I found XSS issues is one I participated in developing; for the others, I neither participated nor have seen the code.
Current Vulnerability Status
As a white-hat hacker, all identified issues were reported to the engineering team and fixed immediately; now, two years have passed, and it’s time to disclose them. However, out of respect for my former company, this article will not mention which product had the vulnerability. Please just refer to the discovery process and causes of this vulnerability!
Consequences of the Vulnerability
This vulnerability allows attackers to change the target user’s password at will and log in to the target account with the new password, stealing personal information and conducting illegal activities.
Main Cause of the Vulnerability
As stated in the title, this vulnerability is triggered by a combination of multiple factors, including the following:
Account login does not support two-factor authentication or device binding
Reset password verification uses serial number
Website data encryption feature has a decryption vulnerability
Abuse of encryption and decryption functions
Token validation design error
Backend does not re-verify field correctness
User email addresses on the platform are public information
How to Reproduce the Vulnerability
Since user email addresses are public information on the platform, we first browse the target account on the platform; after identifying the email, we proceed to the password reset page.
First, enter your email to reset your password.
Enter the email of the account you want to hack, then proceed with the password reset process as usual.
Both operations will send a password reset verification email.
Go to your inbox and find the password reset verification email sent to you.
Change the password link to the following URL format:
1
https://zhgchg.li/resetPassword.php?auth=PvrrbQWBGDQ3LeSBByd
PvrrbQWBGDQ3LeSBByd is the verification token for this password reset operation.
But when I observed the captcha image on the website, I found that the captcha image link format is also similar:
1
https://zhgchg.li/captchaImage.php?auth=6EqfSZLqDc
6EqfSZLqDc displays 5136.
What if we put our password reset token in? Who cares! Let’s try it!
Bingo!
But the captcha image is too small to get complete information.
Let’s continue to find usable points…
The website, to prevent crawler interference, displays users’ public email addresses as images, keyword: images! images! images!
Open it right away and take a look:
Personal Profile Page
Webpage Source Code Section
We also obtained similar URL format results:
1
https://zhgchg.li/mailImage.php?mail=V3sDblZgDGdUOOBlBjpRblMTDGwMbwFmUT10bFN6DDlVbAVt
V3sDblZgDGdUOOBlBjpRblMTDGwMbwFmUT10bFN6DDlVbAVt displays zhgchgli@gmail.com
Just ignore it! Fill it up!
Bingo!🥳🥳🥳
PvrrbQWBGDQ3LeSBByd=2395656
After reverse engineering the password reset token, it was found to be numeric
I thought it might be a serial number…
So I entered the email again to request a password reset, extracted the Token from the new email, and got 2395657 … what the fxck… it really is.
Once you know it’s a sequential process, handling it becomes easier. That’s why the initial step is to request a password reset email for your own account first, then request it for the target account; this is because you can already predict the ID for the next password reset request.
Next, you just need to find a way to convert
2395657back into a Token!
What a coincidence, I found another issue
The website only validates the email format on the frontend during data editing; the backend does not re-validate the format for correctness…
After bypassing the front-end validation, change the email to the next target.
Fire in the hole!
We get:
1
https://zhgchg.li/mailImage.php?mail=UTVRZwZuDjMNPLZhBGI
At this point, reset the password token and return to the password reset page:
Successful intrusion! Bypassed verification to reset someone else’s password!
Finally, because there was no two-factor authentication or device binding feature, once the password was overwritten, the account could be accessed and impersonated directly.
The Cause
Reorganize the entire process.
At the beginning, we needed to reset the password but found that the reset password token was actually a serial number, not a truly unique identifier token.
The website abuses encryption and decryption functions without distinguishing their uses; almost the entire site uses the same set.
The website has an online encryption and decryption portal (equivalent to key compromise).
Backend does not re-verify user input
No two-factor authentication or device binding features
Fix Method
The fundamental point is that the password reset token should be a randomly generated unique identifier token.
For website encryption and decryption, different keys should be used based on the function.
Prevent external parties from arbitrarily manipulating data encryption and decryption.
The backend should validate user input.
Enable two-factor authentication and device binding for added security just in case.
Summary
The entire process of discovering the vulnerability surprised me because many were basic design issues. Although the features seemed functional and the small flaws appeared relatively safe on their own, combining multiple holes created a major vulnerability. Developers really need to be careful and cautious.
Further Reading
The app uses HTTPS for transmission, but data was still stolen
Security Issues of SMS Verification Code Strength in Password Recovery
If you have any questions or feedback, feel free to contact me.
This post was originally published on Medium (View original post), and automatically converted and synced by ZMediumToMarkdown.