Hey Hackers, I am Parth Narula. A penetration tester, bug hunter, red teamer and overall a security researcher. I live for those moments where a bit of out-of-the-box thinking cracks open a critical vulnerability.

This time I was testing a web application where I found a broken authentication issue between two subdomains.

It started when I was crawling danacita.co.id and found two subdomains: app.danacita.co.id and partners.danacita.co.id.

The app subdomain had a registration page at https://app.danacita.co.id/register. The form asked for an email address, phone number, institution, password, and confirm password.

Everything looked normal from the front end. I filled in the details and clicked continue (Email & Phone). The application redirected me to an OTP verification page.

But here is the interesting part :)

The OTP was sent only to the phone number, not to the email I had entered. The phone field was also restricted to Indonesian numbers only, so I could not receive the code and got stuck on that screen.

At this point I wanted to see whether the email actually mattered in the authentication flow or whether it was just a ghost field.

So I went back and checked the login page at https://app.danacita.co.id/login. It only asked for a phone number and password. No email field at all.

That meant the email collected during registration was never used for login, never verified, and never part of the actual authentication process. The entire account creation depended on the phone OTP, while the email just sat in the database untouched.

Then I looked at the partners portal at https://partners.danacita.co.id/login. That page used email and password for authentication, and the forgot password flow only required an email address.

There was no registration page on the partners side. There was a forgot password page where the user could enter an email address and receive a password reset link.

That was interesting. The app subdomain was using phone number for login. The partners subdomain was using email for login.

So I started thinking that maybe both subdomains are connected with the same database.

At this point I wanted to see whether the email entered during incomplete registration on the app subdomain was stored in the database or not.

I was having two scenarios in my mind.

What if I entered the email and password in partners login, which I earlier added in app registration page (the registration was incomplete and I got stuck on OTP screen).

What if I entered the email in partners password reset page, that I earlier entered in app registration page.

The first case failed, but second case worked and I received a password reset link on my email for this partners subdomain, in which I not even created account and also my email was not even used in app subdomain for login.

This is a weak validation flaw. The application collects an email but does not verify it, while another part of the same platform relies on it for authentication and account recovery.

I reset the password (basically set the new password) and it was successful.

Now, I visit to partners login page https://partners.danacita.co.id/login and now again tried to enter the email and password and got logged into the application this time.

That confirmed the issue.

The email was already stored in the database even though the registration was not completed. The account was not fully verified through OTP, but the partners subdomain was still treating that email as a valid existing user.

Using the password reset link, I was able to set a new password. After setting the password, I logged in to the partners portal and I got access.

The account was never fully created from the app side.

But still, the forgot password flow on the partners side allowed me to activate and access it.

Lesson learned

• Always verify identifiers that are collected during registration. An unverified email is just as dangerous as a missing one.
• Do not trust data that was never validated. If the app does not verify the email, the partners portal should not treat it as a trusted identity.
• Check consistency across subdomains. When one portal uses phone-based auth and another uses email-based auth, mismatched validation creates broken authentication paths.

I hope you learn something new. Follow for more amazing articles and give claps if you like this one :)

Need expert pentesting services? visit https://scriptjacker.in or let's collaborate on your next project! 🤝

Want to learn from my experiences? Check out my articles on https://blogs.scriptjacker.in