The "Sudo-Mode" Illusion
Many modern platforms use what we call "Sudo-mode" — a security feature that asks you to re-enter your password before accessing sensitive areas like profile settings or payment methods. It's a great safety net; even if you leave your laptop open at a coffee shop, a stranger shouldn't be able to change your account details.
However, while recently poking around LG.com (India), I discovered that this safety net was more of a suggestion than a rule.
The Discovery: Security by Sequentiality
The vulnerability I found is a classic logic flaw. Usually, when you click "Edit Profile" on LG's dashboard, the site takes you here: https://www.lg.com/in/my-account/check-password/
The application expects you to enter your password. Once you do, it grants you passage to the actual editing page: https://www.lg.com/in/my-account/profile/edit-profile/
The flaw is that the server assumes the only way a user could reach the second URL is by passing through the first. It relies on a sequential flow rather than state verification.
The "Aha!" Moment (The PoC)
The exploit is almost embarrassingly simple.
- Log in to your LG account.
- Navigate to the Account Settings.
- Click Edit Profile. When the password prompt appears, ignore it.
- Directly edit the URL in your browser's address bar, changing
/check-password/to/profile/edit-profile/. - Hit Enter.
The site immediately loads the profile editing page, PII (Personally Identifiable Information) and all, completely skipping the password gate.
The Technical Root Cause
The issue is Insecure Access Control.
The server is failing to check for a "verification flag" in the user's session. A secure implementation would require that the /edit-profile/ endpoint verifies a server-side session variable (e.g., is_verified: true) which is only toggled after the password POST request is validated. Without that check, the URL is just a door with a "Please Knock" sign that isn't actually locked.
Final Thoughts
Every sensitive endpoint must independently verify that the user has the correct authorization level to see that specific data, regardless of how they arrived at the URL.
Key Takeaway for Devs: Never trust the sequence of a user's navigation. If a page is sensitive, lock the door — don't just hide the path.
Youtube Video PoC:
If you have any doubts or clarifications, please comment in the above YouTube video! Thanks!