How improper OTP implementation could lead to Account Take Over (Part 4)
OTP which acts as a second layer of authentication must be applied in all systems that serves same resources in this context for e.g mobile and web application.
This case has been found at a redacted.id which runs online ticketing business for transportation through their website and mobile application. Going through the experience in the android app, there is no fault common finding that discussed in the last three article.
OTP is well exercised after first authentication happen during login and inside API body response for getOTP there is no explicit token mentioned.
But not with the webpage, it has only a single step of login.
1. Resetting password through web version for administrator account take over
Let’s observe new password setup process for an authenticated user
According to above picture, a legitimate user is able to update credential with 303 http header response at /profile/updatepass API. What if we attempt to change password for an administrator account which is found on the website information admin@redacted.id.
According to same 303 response like the legitimate one, let’s test that out on login API with admin account and adminpassword credential.
2. Login with administrator account
BOOM !!! It can be seen that administrator account is now being taken over, this is one of the impact applying OTP is partially implemented at this case on mobile version only but not with the web page one.
With this administrator account, booking a ticket is possible without any actual payment which might jeopardize the business.
In summary, improvement point can be taken so far :
- OTP must be exercised on all business channels which serves same resources or functionality
- Reset password is only applicable and allowable for the authenticated user
In case you might have another input / feedback in terms of improvement point please kindly comment.
