A Fintech App Like Swiss Cheese: Filled with Vulnerabilities

This was a gray-box mobile and web assessment of a fintech application serving approximately 5,000 customers and managing nearly BRL 200 million in assets. Given the nature of the platform, the testing focused primarily on scenarios involving the theft of personal and financial data, as well as fraudulent transactions. The engagement was limited exclusively to the application's front and backend services.

Onboarding

The first issue surfaced during the account creation process. The initial onboarding request returned the unique identifier associated with the onboarding workflow. Every subsequent step, where additional user information was submitted, relied solely on this identifier. Because no proper authorization checks were enforced, the endpoints were vulnerable to an Insecure Direct Object Reference (IDOR). By manipulating the onboarding ID, it was possible to access the information of every customer who had completed the onboarding process, retrieve documents uploaded during registration, and modify the stored data.

The same functionality also exposed additional weaknesses. HTTP methods could be manipulated in ways that were never intended by the application, resulting in a Verb Tampering vulnerability. Since object-level authorization was entirely absent, the issue also qualified as a Broken Object Level Authorization (BOLA) vulnerability. Furthermore, the file upload mechanism trusted only the MIME type supplied in the request and performed no meaningful server-side validation afterward, allowing unrestricted file uploads.

Credit Card Functionality

Another feature affected by an IDOR vulnerability was the credit card management section. When a user opened the page displaying their registered credit cards, the application issued a POST request containing the user's identifier, which the backend used to retrieve and render the associated cards.

Obtaining valid user identifiers was straightforward. One approach relied on the previously identified onboarding vulnerability, where records belonging to users with approved accounts exposed their platform user IDs. A second approach was available through the money transfer feature. When initiating a transfer to another customer of the same bank, the server's response included the recipient's user ID.

With a valid identifier in hand, exploiting the vulnerability required nothing more than replacing the user ID in the request responsible for loading the credit card information. The backend returned the cards associated with the supplied identifier, allowing an attacker to view the credit card data of other customers without authorization.

Account take over

Further endpoint enumeration through fuzzing and analysis of the application's JavaScript revealed an endpoint responsible for returning the authenticated user's profile information. Among other attributes, the response included the user's internal identifier. The endpoint was affected by a Verb Tampering vulnerability that allowed the HTTP method to be changed from its intended implementation to a POST request. Once modified, the request accepted an arbitrary user ID supplied by the client. After replacing the identifier with that of another customer and reloading the application, the session was populated with the target user's data and corresponding functionality. The required user IDs were obtained using the same techniques described in the previous sections.

Final Thoughts

The issues described here represent only a portion of the vulnerabilities identified during the assessment of this production banking application. The overall security posture was considerably weaker than expected for a financial platform, making it fortunate that no significant compromise occurred before the findings were disclosed and remediated.

One of the most valuable lessons from this engagement is that vulnerabilities should rarely be evaluated in isolation. Individual findings that appear to have limited impact can become significantly more severe when combined with other weaknesses. In this assessment, the ability to enumerate user identifiers, manipulate object references, and bypass authorization controls transformed seemingly moderate flaws into practical attack paths capable of exposing highly sensitive customer information.

The table below summarizes the complete set of vulnerabilities identified throughout the assessment.