A modern, secure-by-design application
The new platform incorporated OWASP controls, strong session handling, and server-side validation throughout. On paper, it met or exceeded best practice. :contentReference[oaicite:1]{index=1}
Financial Exchange Application Compromise
Uncovering hidden trust weaknesses in OAuth2 authentication and securing a mission-critical trading platform.
Overview
A Europe-wide financial services organisation was preparing to launch a new version of its commodities exchange platform. The application, built in Ruby with security baked in from the start, had undergone internal code review and adhered to all known OWASP recommendations. It relied on Google OAuth2 for authentication, permitting users to access the trading platform using corporate Google accounts.
Despite the high level of confidence in the design, Cyber Defence was engaged for a final pre-launch penetration test — a decision that proved critical. What followed demonstrated how even well-engineered authentication mechanisms can be undermined when third-party trust boundaries are not fully understood.
Challenge
Securing the authentication pathway
OAuth2-based login
Users authenticated via Google credentials, delegating trust to Google’s identity provider.
High-stakes environment
The application would soon be used by real traders and held sensitive market data with strict uptime and security requirements.
Our approach
Cyber Defence’s penetration testers began by analysing the data flow between browser and server, focusing on the trust relationship between Google’s OAuth2 identity output and the application’s own logic. All conventional entry points (login forms, business logic, workflows) were found to be robust.
So we targeted the one component developers often assume can be trusted: identity attributes returned from the OAuth provider. :contentReference[oaicite:2]{index=2}
Method
Turning trusted identity into an attack surface
Manipulating identity fields
We modified first and last name values within the OAuth2 identity payload, injecting benign XSS markers followed by SQL syntax to test server-side validation.
Application error leakage
The application returned unusual errors when sanitisation failed, confirming an exploitable SQL injection pathway originating from the trusted Google profile fields. :contentReference[oaicite:3]{index=3}
Escalating the attack
With the injection point confirmed, we crafted SQL payloads targeting user tables and authentication data.
Dumping the admin credentials
By carefully injecting SQL into the first-name field, Cyber Defence extracted the platform’s administrator user table — including usernames and password hashes. This alone represented a significant compromise.
But access to the admin account required secondary two-factor authentication, so our team moved on to the challenge of bypassing it. :contentReference[oaicite:4]{index=4}
Bypassing MFA
Gaining full administrative access
Google 2-Step loophole
Earlier in the year, Google had patched an issue where Application-Specific Passwords could bypass 2-Step Verification entirely — but even after the fix, ASPs still allowed extensive account interaction. :contentReference[oaicite:5]{index=5}
Leveraging MergeSession
Using <code>https://accounts.google.com/MergeSession</code>, we generated a session pivot enabling partial reuse of identity tokens.
Plaintext Chrome refresh token
Chrome stored the OAuth2 refresh token in plaintext under the user’s profile preferences:<br><br><code>"oauth2LoginRefreshToken": {"status": "Successful", "value": "vdb_4dm1n_100212"}</code><br><br>With this token, we successfully sidestepped the second authentication step and logged in as the administrator. :contentReference[oaicite:6]{index=6}
Impact
What this meant for the client
Complete application compromise
From a third-party trust boundary flaw, we achieved full administrative access to the commodities exchange platform.
Severe business risk
Administrators controlled market data, trading workflows, and system configuration — potential for financial harm was significant.
Third-party identity risk
Trust in Google’s OAuth2 identity attributes created a blind spot in server-side input validation.
Remediation & retesting
Cyber Defence provided concrete recommendations, including:
• full server-side validation of all OAuth-supplied identity attributes
• strict separation of authentication source and application trust boundaries
• improved sanitisation routines for names, emails, and user profile data
• monitoring and alerting for identity anomalies
• safer handling of OAuth refresh tokens
The client remediated the issues within one week. A free retest by Cyber Defence confirmed that the vulnerabilities were fully resolved and the application was secure for production launch.
Need an advanced application penetration test?
Cyber Defence specialises in testing complex authentication systems, OAuth/OIDC integrations, mobile application flows, cloud identity boundaries, and business-critical financial platforms.
If your application relies on third-party identity providers, ensure the trust chain is truly secure.