API Threat Research: GraphQL Authorization Flaws in Financial Technology Platform
Incident Synopsis
Salt Labs researchers investigated a large business-to-business (B2B) financial technology (FinTech) platform that offers financial services in the form of API-based mobile applications (apps) and software as a service (SaaS) to small and medium-sized businesses (SMB) and commercial brands. As a result of API vulnerabilities that our researchers identified, they were able to launch attacks where :
- Any user could submit unauthorized transactions against other customers
- Any user could harvest sensitive data about customers
The organization employed GraphQL in its technology stack to power the account activities of customers using mobile apps. The organization also leveraged a third-party API to retrieve records of prior customer account transactions. The implementation failed to properly authenticate and authorize customers. As a result, Salt Labs researchers were able to submit unauthorized transactions against other customers of the financial services provider, correlate user account activity, and retrieve PII about customers. As with many flawed API implementations, a number of the issues that make it possible to exploit the services map to the OWASP API Security Top 10, including:
- Broken object level authorization (BOLA)
- Broken authentication
- Excessive data exposure
The services in question come from a FinTech division of a large consumer brand that offers a combination of B2B and B2C offerings. Maintaining the anonymity of this service provider is essential, so we have sanitized any technical details that could identify the organization. Upon identifying the vulnerability, we reviewed our findings and provided recommended mitigation to the organization. As part of the broader Salt Labs mission, we are sharing the findings here to increase awareness around API vulnerabilities, including explaining the attack pattern, detailing the steps to propagating the attack, and highlighting mitigation techniques.
Research motivation
Salt Labs conducts threat research to help customers and prospects identify vulnerabilities in their own APIs. The lab also investigates public platforms to uncover application logic flaws, following responsible disclosure practices and working with the appropriate organizations to resolve issues with the APIs. We publish this information — anonymized when need be — to help practitioners learn from others’ mistakes and avoid a resulting incident.
In this case, Salt Labs researchers investigated the online financial technology platform because the company was concerned about potential API security gaps and reached out to Salt Security for assistance. The implementation made use of GraphQL services, which have grown in popularity. Several aspects of GraphQL API structure can create security risks that can be more difficult to assess. Security awareness around GraphQL is still relatively low, and the vulnerability details of this organization’s API implementation provide additional educational value for industry.
The potential business impacts of the API security gap we found
A prevalent vulnerability related to GraphQL is that developers must implement authorization on every layer of a multi-layer GraphQL query to prevent attacks. This side effect increases the burden on development and operations teams, and it can extend delivery timelines for applications with many API endpoints. It also can create a situation that is more vulnerable to human error. Some endpoints may be forgotten or not properly dealt with, causing its own set of issues down the road. In contrast, REST APIs include inherent authentication and authorization controls, provided mechanisms such as OpenID connect (OIDC) and OAuth2 are implemented properly.
On average, mobile apps include a significantly higher number of vulnerabilities than web-based apps. Authentication and authorization are often weak, broken, or absent in mobile app designs since developers are focused primarily on mobility and usability. Mobile channels are also often less secure than web channels. Alternatively, codebases may be maintained by separate teams, which leads to discrepancies in API security posture. Attackers know this reality and will flip between front-end clients and back-end services to find the weakest link when targeting functionality or data. Web API communications are often encrypted with SSL or TLS, which gives organizations a false sense of security about an application’s or API’s resistance to attack. In this case, Salt Labs researchers were able to isolate the API calls, request data through a standard web browser, and receive sensitive identifiers that enabled attacks against the authorization mechanism used by the application.
Attack: Submit unauthorized account transactions against customers
Organizations must service multiple application front-end types, typically web and mobile applications, that in turn interface with many back-end services. Application flows typically invoke a number of internal and external API calls to provide functionality or data, and these flows can vary per user type or the associated client application. Ensuring that an authenticated entity is authorized to access a given resource throughout a session is easier said than done, particularly as most organizations also work with other partners to enable functionality as part of a larger digital supply chain. Once an attacker has obtained an authenticated session with even basic permission levels, they can abuse authorization to access other data or functionality as provided by APIs and as part of the larger application design.
In our research, we were able to alter account numbers of API calls and perform unauthorized funds transfers. Account numbers are a form of PII, but they are also useful for perpetuating fraud, since an attacker can use the information to perform actions on other accounts if an API is not properly enforcing authorization. In this incident, one of the account numbers was a unique, government-issued identifier, and the other was a financial account identifier. Account numbers could be harvested and correlated through a third-party API endpoint, which is covered in the next section of this threat report.
Attack: De-anonymize and correlate account activity
Organizations regularly outsource work, including systems engineering and operations. This business practice is particularly common with applications and APIs, since development work and code artifacts may be sourced partially or entirely to third parties. Unfortunately, one by-product of outsourcing is often a lack of knowledge about a complete architecture and end-to-end application flows. Quirks in user experience are often a best-case scenario. Worst case, significant security gaps arise where infrastructure may be misconfigured or code exhibits weaknesses. These missteps can lead to sensitive data exposure, abusable business logic, and exploitable vulnerabilities for organizations.
In our research, we discovered an integrated third-party API that inadvertently exposed sensitive data that de-anonymizes customers and enables attackers to correlate account activity. PII including names, addresses, and account numbers were exposed by this third-party API endpoint. The only data that was required to call this API and obtain the PII was a record identifier of a prior transaction. Sensitive data such as what was discovered here are subject to many forms of national and regional regulations that govern business activity and user privacy. Such data exposure can trigger regulatory penalties and fines.
The technical details of this API security gap
Our researchers analyzed the mobile app and back-end APIs through a combination of methods that included:
- Postman repository analysis
- Mobile app reverse engineering
Using a Postman repository provided by the customer, our researchers examined the structure of the API used by mobile app clients. The researchers began to understand what types of requests would elicit useful data that could be exploited. In tandem, our researchers also reverse-engineered the mobile app and cross-correlated their findings regarding API calls with the Postman repository records. Our researchers found and altered the SSL/TLS certificate embedded within the mobile app that was used for certificate pinning and encrypting API communications. This circumvention of a client-side control enabled our researchers to inspect and manipulate API traffic originating from the mobile app.
Via the mobile app, an attacker could view the receiver of a money transfer. Exercising the API via Postman also exposed PII data related to the sender and the receiver. In addition, the API calls included valuable data our researchers could use to correlate customer activity and manipulate API calls such that they could take action on an account. Our researchers validated this attack pattern by choosing a user, attempting an account funds transfer, and viewing the transaction in the mobile app.
Researchers also discovered calls to an unauthenticated, third-party API endpoint that responded with a PDF of a receipt of a given transaction when supplied with a unique transaction identifier. The third-party API endpoint also returned other PII including names, addresses, dollar amounts, and account identifiers that were useful in verifying whether malicious transaction attempts were successful.
These security vulnerabilities were located on a GraphQL API endpoint, an API type that has grown in popularity over REST APIs for mobile app designs. The organization was not authenticating or authorizing requests by cross-checking the identity of the sender during funds transfer requests. Similar attack techniques work for both GraphQL and REST API designs. The complexity of GraphQL, such as nested queries, often exacerbates the challenges of authorization, since a single API call can consolidate multiple queries and API endpoints.
Any user could submit unauthorized transactions against other customers
OWASP defines authorization issues as broken object level authorization (BOLA). Attackers exploit BOLA flaws to escalate privileges and gain access to data for which they are unauthorized. In this case, Salt Labs researchers were able to manipulate GraphQL queries to alter targets for funds transfers and automatically authorize those same transactions.
Salt researchers found that a GraphQL API endpoint allowed for client-controlled query parameters in the message body of the API request. The API endpoint looked like the following:
“/BFF/graphql/mutation/doPayment”
In this BOLA attack, the API call sequence consisted of the following steps:
1. An attacker calls the endpoint using the victim’s unique identifier (UID) that deposits funds from one bank account to a digital wallet. There is no limit on the amount of money that can be transferred, but in this case, a funds transfer of $100 was attempted as a test.
2. The server responds with a 200 OK status message that the transaction is submitted successfully. Within the payload, the variable “status” also indicates that the transaction is awaiting confirmation. The app design includes no notification to the victim of this transfer. The owner of that original account would be unaware that money transferred out of his or her account unless s/he were monitoring the account activity closely. The value TID is the transaction identifier that can be used to look up a record of the transaction on a separate, third-party API endpoint.
The value UID here is a unique, national identifier. If that value is unknown to the attacker, they can obtain the information by calling a separate, third-party API endpoint as described in the next section. When hitting that third-party API with a transaction identifier, a receipt of a given transaction is presented to the attacker in either HTML or PDF format. That transaction receipt includes the victim’s account number, digital wallet ID, address, the amount of money, and other examples of PII data. With that gained PII data, the attacker can initiate transfers to any other account or user.
Any user could harvest sensitive data about customers
During the threat research, Salt Labs researchers also discovered a third-party API endpoint that required no authentication and also exposed sensitive data. The first of these issues maps to OWASP API2: Broken User Authentication. The second issue maps to OWASP API3: Excessive Data Exposure.
Salt researchers uncovered a function within the GraphQL API endpoint that in turn called the vulnerable third-party API endpoint. The GraphQL API endpoint looked like the following:
“/BFF/graphql/mutation/receiptUrl”
In this data harvesting attack, the API call sequence consisted of the following steps:
1. After a user submits a successful transaction in the mobile app, which in turn calls the GraphQL endpoint for the doPayment function, the mobile app then makes another call to the GraphQL endpoint to provide a record of the transaction. The request contains the user identifier, UID, and the transaction identifier, TID. That request appeared similar to the following:
2. The response to that GraphQL API call contains a nested REST API call that is in turn invoked by the mobile application to return a record of the transaction in PDF format. That response looks similar to the following:
3. That nested URL can be called directly with a basic HTTP GET request or simply launching the URL in a browser. Only the transaction identifier, TID, was necessary as a parameter, and no authenticated session was required to fetch the data. The third-party API responds with a full record of the transaction in PDF format. That PDF receipt includes the victim’s account, digital wallet ID, name, address, dollar amounts, and other examples of PII data.
The third-party API endpoint was useful in validating that the BOLA attack worked as expected. The third-party API also exposed too much sensitive data, and making the calls outside of the mobile app without any authenticated context validated that access controls were not being enforced. This data is useful in perpetuating other types of fraud in the platform, and the data can also be used to de-anonymize customers and correlate account activity. The API endpoint also appeared to lack any resource or rate limit controls, which would have made further enumeration of transaction identifiers and mass scraping possible.
Methods to mitigate this API security gap
Exploiting the flaws in this business-to-business (B2B) online financial services platform would require correlation of data served by third-party APIs and unique manipulation of the business logic involved in the GraphQL API used by mobile app front ends. Appropriate remediation and mitigation techniques also must be unique.
Mitigating authorization flaws that allows an attacker to submit and automatically authorize transactions
A secure API should require consistent verification that the user requesting data or functionality is authorized to access that data or functionality. The system should continuously validate authorization for every session and on each data access request. This continuous authorization approach is fundamental to the security practice of least privilege, which in turn is a crucial premise of zero-trust architecture.
Organizations should apply the following countermeasures to mitigate the authorization weaknesses that Salt Labs identified:
- Continuously authorize - the API and the integrated back-end services should employ continuous validation to ensure that the authenticated user is authorized to access the requested data or function.
- Return precise HTTP error codes - If an authenticated user attempts to access another user’s records, the server should respond with a “401 Unauthorized” or “403 Forbidden” HTTP status code, and/or redirect the unauthenticated user to a login page that displays a 30X HTTP status code.
- Invalidate abusive request sessions - Design the platform so that it monitors for and invalidates sessions where users are making excessive requests, enumerating records, or making repeated attempts to access unauthorized data.
- Avoid default or simple naming - Use unique names and indexes that attackers cannot easily guess, brute force, or enumerate through.
- Use rate limits - Enforce rate limits on API endpoints to prevent enumeration, while taking into account the fact that attackers will throttle their request rates to evade detection.
- Ensure that authentication and authorization are consistent between web and mobile channels - Platforms should be designed so they implement authorization and authentication on these vulnerable endpoints and when users switch between channels or front-ends. SSL and TLS helps encrypt API communications, but such transport protection can be bypassed by attackers.
Mitigating the risk of de-anonymization and correlation
Many API implementations are expansive ecosystems or digital supply chains, where one organization is integrating with any number of third-party APIs and services to facilitate business. Such was the case for this particular financial organization, as one of the third-party API endpoints was returning account identifiers that became useful in perpetuating the authorization attack. That third-party API endpoint also required no authentication, let alone authorization.
Apply the following countermeasures to mitigate the de-anonymization and correlation weaknesses that Salt Labs identified:
- Always authenticate and continuously authorize — Any API that serves sensitive data should require authentication and continuously validate whether that authenticated user is authorized to access the requested resource.
- Use rate limits — Enforce rate limits on API endpoints to prevent basic forms of enumeration and to mitigate the risk of scraping en masse. Know that attackers will also throttle their request rates to evade detection or trigger a rate limit.
- Use sufficient entropy — Ensure that any identifiers are sufficiently lengthy, complex, and random to limit effectiveness of enumeration and brute forcing attack techniques. This countermeasure can also help maintain pseudonymization by making it more difficult for attackers to correlate accounts and data.
- Avoid use of static identifiers as an authentication factor — Record identifiers should be sufficiently complex and random. Additionally, if such identifiers are used as an authentication factor, they should be dynamic and expiring. Given enough time and contingent on rate limiting countermeasures, attackers can brute force these values used in API calls. This type of API flaw is similar to reliance on API keys as a sole means of authentication for API callers. Such data can and will be harvested or brute forced by attackers.
- Avoid exposing too much data in responses — Don’t send data to clients that isn’t necessary to complete a given function. Also account for any regulations that impact sensitive data transmission and retention, particularly as they pertain to privacy.
- Validate security of third-party services where possible — Partners and suppliers must also provide a level of guarantee regarding API security, data security, and user privacy. Some third-party security elements can be validated by the first-party organization, such as validating that API endpoints require TLS and authentication. You may also need to seek attestation from suppliers since not all code or configuration will be visible to the first-party organization.
Lessons learned
The top three issues within the OWASP API Security Top 10 issues were all present in this application architecture: broken authorization, broken authentication, and excessive data exposure. The organization was making use of newer technology in the form of GraphQL, which brings added complexity and higher risk of authorization issues. GraphQL is gaining adoption as an enabler of the back end for front ends (BFF) design pattern. Many organizations are actively pursuing GraphQL initiatives where they need to provide a number of services to large user bases where even the slightest potential latency for front-end systems like mobile apps is of concern. Practitioners should be aware, though, that GraphQL implementations are susceptible to many of the same API attack patterns as REST. Potential security risks can also be compounded and exacerbated with GraphQL, particularly with application-level DoS and broken authorization flaws.
Attackers use techniques that work universally for both GraphQL and REST APIs. One of GraphQL’s greatest features, the ability to consolidate queries and endpoints, also elevates the security risk. Implementing adequate authorization becomes a complex endeavor when factoring in all the ways a given front end might exercise a GraphQL API, which in turn calls other back-end APIs. GraphQL brings some other potential security risks that organizations should be aware of as they adopt this newer technology. “Security through obscurity” is never a strong strategy. Organizations should operate with the mindset that attackers will regularly reverse engineer applications and API calls, which includes all forms of mobile app binaries and API protocols.
A recurring theme within API security is that architecture matters. This principle holds true for your own API designs, what you seek in solutions, and how you approach security strategy. Organizations often expend a lot of manpower testing at length, sometimes automatically as part of build pipelines, but always with a goal of trying to identify as many code-level issues and misconfigurations as possible prior to production release. Unfortunately, testing all application flows and API call sequences is easier said than done with traditional security testing tooling. Plus, scanning code prior to its production release has its limits, — indeed,most cases of abusable business logic can be found only by analyzing behaviors in runtime. The problem only worsens with outsourced development and operations. A fully integrated application and all its services is a complex spider web of internal and external services as well as partner connections that can best be described as a digital supply chain.
Salt Labs has detailed the GraphQL vulnerabilities, the steps an attacker could follow, and the preventative actions organizations can take to mitigate these kinds of attacks. It’s critical that any API that serves sensitive data, regardless of protocol, requires authentication and authorization. Access control and activity monitoring should be continuous throughout all sessions to ensure that API callers are not requesting data or functionality for which they’re unauthorized. Such an approach is fundamental to API security as well as other security principles including least privilege and zero trust architecture.
Salt Labs publishes API threat research and mitigation recommendations to help bring awareness to the API security space and educate practitioners. All organizations are building or integrating APIs in some capacity. Many are also working with partners and suppliers to power their business and provide services to customers. All organizations can benefit from a full lifecycle approach to API security, and many should seek dedicated API security tooling so they can find and address the full set of potential API security issues.
If you’re interested in seeing the Salt Security API Protection Platform in action, contact us for a customized demo today!
