Security Write-Up: Authentication Bypass via Response Manipulation on Email Change Feature

Hey everyone! 👋

My name is Yousef Abdullah, and I'm a cybersecurity researcher. Welcome to my write-up! Today, I want to share a story about a cool logic vulnerability I recently discovered during a security assessment on hollisterco.com.

If you're interested in web security, bug bounties, or just curious about how authentication and verification flows can break, this article is for you! So grab your favorite drink ☕, and let's dive right in.

💡 Understanding the Concept: What is an Email Change Bypass?

Imagine you want to update your registered email address on an online platform. To protect your account, the system requires you to enter a one-time password (OTP) sent to your new email to prove ownership.

Now, what if the application decides whether your code is correct based solely on a simple flag sent back in the HTTP response (like "success": false), and the front-end code blindly trusts whatever the response says? If an attacker enters a completely random or wrong code, intercepts that response packet, and flips the flag to "success": true, the application says, "Ah, looks good!" and updates the email without verifying anything.

This is a classic client-side logic flaw / authentication bypass (CWE-288 / CWE-602) where security controls are improperly enforced on the client side rather than securely validated on the server.

🔍 The Discovery: How I Found the Vulnerability

While testing hollisterco.com, I decided to inspect the account settings and the email update feature closely using Burp Suite. I wanted to see how the application handles OTP verification during sensitive account changes.

Here is how the vulnerability panned out:

1. Initiate Email Update: I navigated to Account Settings on hollisterco.com and triggered an email update action.
2. Enter an Invalid OTP: When prompted for the verification code, I entered a completely arbitrary or incorrect code (like 000000) and submitted it.
3. Intercept the Response: Using Burp Suite, I intercepted the GraphQL request targeting the mutation validateOtpForAccountChange.
4. Observe the Failure: The server responded with a failure status:

{
  "errors": [
    {
      "message": "INVALID_OTP",
      "extensions": { "code": "UNAUTHENTICATED" }
    }
  ],
  "data": {
    "validateOtpForAccountChange": {
      "success": false,
      "errors": ["Invalid OTP code"]
    }
  }
}

{
  "errors": [
    {
      "message": "INVALID_OTP",
      "extensions": { "code": "UNAUTHENTICATED" }
    }
  ],
  "data": {
    "validateOtpForAccountChange": {
      "success": false,
      "errors": ["Invalid OTP code"]
    }
  }
}

5. The Magic Trick (Response Manipulation): Instead of letting the failure pass, I modified the response payload in Burp Suite to force a success state:

{
  "data": {
    "validateOtpForAccountChange": {
      "success": true,
      "errors": null,
      "__typename": "APIResponse"
    }
  }
}

{
  "data": {
    "validateOtpForAccountChange": {
      "success": true,
      "errors": null,
      "__typename": "APIResponse"
    }
  }
}

6. Bypass Successful: I forwarded the modified response to the client browser, and boom! The application accepted the invalid OTP and successfully bypassed the verification step.

⚠️ The Impact

Why is this type of vulnerability dangerous?

• Bypassing Security Controls: It completely defeats the multi-factor/OTP verification mechanisms intended to protect sensitive user actions.
• Unauthorized Account Modification: An attacker can manipulate verification flows on account modification endpoints to alter critical settings without proper validation.
• Logic Flaw Exploitation: It highlights how dangerous it is when backend systems or front-end applications rely on client-side trust models for security decisions.

🛠️ How to Fix It (Remediation)

If you are a developer or security engineer building modern web apps, here is how you can protect your application against this:

• Enforce Strict Server-Side Validation: Never rely on client-side state or boolean flags returned in HTTP responses to determine whether an operation succeeded.
• Cryptographic Verification: Ensure that critical state updates (such as email changes) are executed only upon secure server-side validation of OTP tokens.
• Secure API Design: Treat all client inputs and responses as untrusted, and ensure that authorization and verification logic live securely on the backend.

🎯 Conclusion

Logical vulnerabilities and response manipulation bugs are often missed by automated scanners because they require human creativity and a deep understanding of application workflows. Always remember to test how applications handle errors, responses, and state changes!

Thank you so much for reading! I hope you learned something new today. If you have any questions or feedback, feel free to connect with me!

Author: Yousef Abdullah

Security Researcher