Introduction

In the current landscape of mobile application security and API-based services, protecting user flows is a critical point of failure. Modern applications, by depending on application programming interfaces (APIs) for data management and business logic, expose a considerable attack surface. This analysis focuses on examining the implementation of registration, authentication, and credential recovery functionality of an Android mobile application for a health bracelet by intercepting network traffic using tools such as Frida and a web proxy.

Analysis

1. User enumeration and weak registration flows

The analysis begins with opening the application and intercepting network communications. A business flow is observed that allows the user to choose between creating an account or utilizing the application without registration.

A critical vulnerability is detected in the route used to verify the existence of an account. Through an HTTP request, it is possible to determine if an email address is already registered in the system, allowing for complete enumeration of existing users in the database.

:method: POST
:path: /api/users/CheckUserName?username=<EMAIL_ADDRESS>
:authority: backend.application.tld
:scheme: https
user-agent: okhttp/4.12.0

The registration process is limited to requesting only an email address and a password. The application presents an interface that allows passwords of 6 to 20 characters without imposing complexity requirements. However, server analysis reveals even greater laxity: the server accepts single-character passwords.

:method: POST
:path: /api/users/register
:authority: backend.application.tld
:scheme: https
content-type: application/json; charset=UTF-8
user-agent: okhttp/4.12.0

{"username":"<EMAIL_ADDRESS>","password":"<PASSWORD>"}

2. Absence of possession verification and weak authentication

After registration, the application allows continuing the process without confirming account ownership through a link or a one-time code. This allows any unregistered email to be used to create an account.

The subsequent session is established via the verification route, which sends data such as device model, operating system version, and application type. Although an attempt is made to send the IMEI code, in recent versions of Android, it is detected that the application does not possess the necessary permissions to access this identifier.

:method: POST
:path: /api/users/verify
:authority: backend.application.tld
:scheme: https
content-type: application/json; charset=UTF-8
user-agent: okhttp/4.12.0

{"phoneband":"<PHONE_MODEL>","ImeiCode":"no permission","username":"<EMAIL_ADDRESS>","SysType":"android-sport","password":"<PASSWORD>","SysVersion":"16"}

It is noted that this path lacks any protection mechanism against brute force attacks. It is possible to perform a minimum of 100 session attempts without any rate limiting or restriction being applied, which significantly increases the probability of an automated brute force attack.

{  
    "UserId": "<USER_ID>",  
    "ExpiresIn": "2026...",  
    "AccessToken": "<SESSION_ACCESS_TOKEN>",  
    "RefreshToken": "<SESSION_REFRESH_TOKEN>",  
    "CreatedDate": "2026..."  
}

Access and refresh tokens have a duration of one month from the creation date. Subsequent requests are authenticated using the HTTP header Authorization: token <SESSION_ACCESS_TOKEN>.

3. Exposure of sensitive data

When making a request to the path /api/users/profile to obtain the data of the newly created account, a critical security flaw is evident: the password is returned unencrypted. This confirms that the data is being stored in the database without the application of a robust encryption mechanism, exposing the credential in case of a database breach.

{  
    "UserId": "<USER_ID>",  
    "Nickname": "<EMAIL_ADDRESS>",  

    "Email": "<EMAIL_ADDRESS>",  

    "HXUserName": "<USER_ID>",  
    "HXUserPassword": "<PASSWORD>",  

}

4. Vulnerabilities in the password recovery flow

The analysis proceeds to verify the forgotten password recovery mechanism. The first step involves entering the email address, which again activates the enumeration path. If the account exists, a request is triggered to send the verification code.

:method: POST
:path: /api/send/SendMailCode
:authority: backend.application.tld
:scheme: https
content-type: application/json; charset=UTF-8
user-agent: okhttp/4.12.0

{"vericode":"<VERIFICATION_CODE>","subject":"Application","language":"es","type":"android-sport","useremail":"<EMAIL_ADDRESS>","displayName":"Application Verification Code"}

Several irregularities are observed in this process. Firstly, the single-use code for verification is generated locally on the device using a four-digit numeric string, and not on the server. More concerning is that this route is used to trigger the sending of emails regardless of whether the email address is registered. The fields vericode, subject and displayName are customizable. This is an example of a received email.

From: "Application Verification Code" <system@application.tld>
To: <EMAIL_ADDRESS>
Subject: Application

Dear Application Verification Code users :
Greetings!
Your verification code is: <VERIFICATION_CODE>
For the security of your account, please enter the verification code within 1 hour
If not operated by yourself, please ignore this email
send by system automatically, please do not reply

It has been verified that if the email client receives the message in HTML format instead of plain text, it is possible to inject HTML or JavaScript code into the field displayName (example: displayName": "<script>alert('Verification Code')</script>"). The use of sequences like <!-- allows hiding the remaining content of the email. Email clients without filtering are vulnerable to Cross-Site Scripting (XSS) attacks via email. Additionally, the manipulation of parameters subject and the email body allows this route to be used to send malicious emails to any email address, facilitating phishing campaigns.

Finally, the recovery process culminates with the request to change the password.

:method: POST
:path: /api/users/findpassword
:authority: backend.application.tld
:scheme: https
content-type: application/json; charset=UTF-8
user-agent: okhttp/4.12.0

{"username":"<EMAIL_ADDRESS>","NewPassword":"<PASSWORD>"}

It is observed that this route allows modifying a user’s password without requiring the presentation of any previously sent verification code. This represents a critical-level Account Takeover vulnerability, allowing an attacker to change any user’s password simply by knowing their email address. After this change, the original user receives no notification whatsoever, leaving their account compromised without their knowledge.

Conclusion

The application analysis reveals a set of security vulnerabilities of critical risk and high impact. The current architecture presents multiple points of failure that, when combined, allow an attacker to perform a complete and unrestrained account takeover, with the capacity to operate at automated scale.