Introduction

Recently, while performing security testing on two EdTech platforms — LearningWay and LearningRanking, I discovered several serious vulnerabilities in their authentication and authorization mechanisms.

During the assessment, I noticed something interesting:

Both applications appeared to be running on the same backend infrastructure.

After deeper testing, it became clear that:

  • Both platforms share identical APIs
  • Same authentication system
  • Same UI structure
  • Same SSO mechanism
  • Same backend domain
Learningway.com

This meant a vulnerability in one platform would impact both applications simultaneously.

The most critical issue I discovered was an Insecure Direct Object Reference (IDOR) vulnerability that could allow an attacker to take over any user account.

Let's walk through the discovery process.

Understanding the Application Architecture

Before testing any application, understanding the architecture is important.

While exploring the platform, I noticed the following behavior:

  1. Users could log in using mobile number + OTP
  2. Profile settings allowed modification of user information
  3. The application communicated with backend APIs hosted on:
LearningWay.com

Both domains:

  • LearningTesting.com
  • LearningWay.com

were communicating with the same backend APIs.

Additionally, Single Sign-On (SSO) was implemented through LearningWay, meaning a user authenticated on one platform could access the other platform automatically.

This indicated a shared codebase and authentication infrastructure.

Vulnerability #1 — Critical IDOR in User Profile Update API

Severity: Critical Impact: Full Account Takeover

While testing the profile update functionality, I intercepted the request using Burp Suite.

The application sent the following API request when updating profile information:

POST /admin/api/update-user
Host: LearningWay.hranker.com
Content-Type: application/json
Example request body:
{
"name":"Pdfdfr",
"mobile":"6353560018",
"email":"test@example.com",
"user_id":4340963,
"state_id":"2",
"city_id":"722",
"customer_id":561,
"cropped_img":""
}
The parameter that immediately caught my attention was:
"user_id"
This parameter was fully controlled by the client.

Exploiting the Vulnerability

To verify whether proper authorization checks were implemented, I modified the user_id parameter.

Original request:

"user_id":4340963
Modified request:
"user_id":4340964

After forwarding the request from Burp Repeater, the server responded with a success message.

The profile of another user was updated successfully.

This confirmed that the server was not validating whether the authenticated user actually owned the account being modified.

Why This Vulnerability Is Dangerous

This vulnerability becomes extremely dangerous because of the platform's OTP-based authentication system.

An attacker could:

  1. Modify the victim's mobile number
  2. Request OTP login
  3. Receive OTP on the attacker-controlled phone
  4. Log in to the victim's account

This results in complete account takeover.

Vulnerability #2 — Restricted Parameter Manipulation

Severity: High

While testing the profile editing feature, I noticed that the user interface does not allow modification of certain fields, including:

  • Email address
  • Mobile number

However, this restriction existed only on the client side.

By intercepting the request using Burp Suite and modifying the parameters manually, I was able to change both fields.

Modified request example:

{
"name":"Test User",
"mobile":"6353560018",
"email":"attacker@gmail.com",
"user_id":4340963
}

The server accepted the request without validation.

This confirmed that the backend trusted client input without proper validation.

Vulnerability #3 — OTP Brute Force Vulnerability

Severity: High

The OTP verification endpoint was also vulnerable to brute-force attacks.

Endpoint:

GET /admin/api/verifyOtp/{otp}/{mobile}/{type}

Example request:

GET /admin/api/verifyOtp/0000/6353560019/0

The problem here was the lack of security protections.

The application did not implement:

  • Rate limiting
  • Maximum attempt restrictions
  • Temporary account lockouts
  • CAPTCHA protection

Using Burp Intruder, it was possible to automate OTP guessing with payloads like:

0000
0001
0002
...
9

Since the OTP was only 4 digits, the total keyspace was:

10,000 combinations

Without protection mechanisms, brute forcing becomes trivial.

Vulnerability #4 — Weak Password Reset Mechanism

Severity: High

During further testing, I discovered that the password reset functionality generated a 4-digit password.

Example:

Password: 4832

The problem is that this creates a very small password space:

0000 — 9999

Only 10,000 possible combinations.

This allows attackers to automatically brute-force passwords using scripts or tools.

Combined Attack Scenario

When these vulnerabilities are combined, the impact becomes even more severe.

An attacker could:

  1. Exploit IDOR to modify victim profile
  2. Change victim mobile number
  3. Use OTP brute force
  4. Or guess the 4-digit password

Result:

Full compromise of any user account on the platform.

Since both platforms share the same infrastructure, this attack could affect users across both domains.

Security Recommendations

To mitigate these vulnerabilities, the following security improvements should be implemented:

Proper Authorization Checks

The server must validate that the authenticated user is authorized to modify the requested account.

Developers should:

  • Remove user_id from client-controlled parameters
  • Identify users using session-based authentication
  • Implement strict access control validation

Server-Side Validation

Sensitive fields such as:

  • Email
  • Mobile number

should only be modifiable through secure workflows with proper verification.

Secure OTP Implementation

The OTP system should include:

  • Maximum OTP attempt limit (3–5 attempts)
  • Rate limiting
  • Temporary account lockouts
  • CAPTCHA verification

Strong Password Reset Mechanism

Instead of generating weak passwords:

  • Use cryptographically secure reset tokens
  • Send password reset links
  • Require users to create strong passwords
  • Implement login attempt restrictions

Responsible Disclosure

These vulnerabilities were discovered during security research and responsible testing.

No user data was intentionally accessed or misused.

The findings were shared with the platform owners to help improve their security posture and protect users.

Final Thoughts

This research highlights an important lesson in web security:

Client-side restrictions are not security controls.

Security must always be implemented on the server side.

Even a simple oversight such as trusting a user-controlled parameter like user_id can lead to critical account takeover vulnerabilities affecting thousands of users.

If you're interested in web application security, bug bounty hunting, and vulnerability research, always remember:

  • Observe how APIs work
  • Intercept requests
  • Test authorization boundaries

Sometimes a single parameter change can uncover a critical vulnerability.