Platform: HackerOne
Status: Duplicate
Overview
I was testing a target belonging to a large online fashion platform, focusing on how the application handled response manipulation within its OTP verification flow.
During my assessment, I analyzed the client-server interaction to determine whether the OTP validation logic was enforced strictly on the backend or could be influenced through modified responses.
OTP-based authentication flows are a common area of interest in my testing, as improper validation can lead to account takeover or unauthorized actions when not implemented securely.
The application has a feature where you could authorize an email change. But to change the email, it requires an otp to be sent to the current email address. So this where the real attack begins.
When I clicked on the change button to update the email address, the application sent an OTP to the current email linked to the user account.
I turned on interception in Burp Suite and entered an invalid OTP to capture the request and response flow.
Next, I enabled Intercept Response to observe and manipulate the server’s response.
At this point, I recalled a valid 200 OK response I had seen earlier while testing another endpoint. That gave me an idea of what a successful response should look like.
While interception was still active, I copied the success message format and replaced the error message from the OTP response with it.
After replacing the error message with the success message, I forwarded the modified response.
The application accepted the modified response and treated the OTP as valid. This allowed me to proceed to the next step, where I could input a new email address under my control and request an OTP to it.
An OTP was successfully sent to the new email address.
I then used the OTP from the new email to complete the process and successfully changed the account’s email address.
This could lead to an account takeover if an attacker already has your password but no access to your email.