Steve Zurier | scmagazine.com »
Researchers on Wednesday found a GraphQL authorization vulnerability on an undisclosed FinTech platform.
In a blog post, Salt Labs said the findings were identified by researching the mobile apps and SaaS platform of the FinTech provider. Salt Labs found that the failure to implement authorization checks correctly means that the researchers could submit unauthorized transactions against any customer account and harvest any customer’s sensitive data.
“GraphQL-based APIs have been growing in popularity because of the potential benefits they bring to mobile app and web app designs,” said Michael Isbitski, technical evangelist at Salt Security. “One of these benefits is the ability to group API calls within one API call for client applications to reduce the amount of API calls needed to provide app functionality. Unfortunately, the byproduct of this design characteristic is that it increases the complexity between front-end and back-end API calls, and in turn, the potential risk of security gaps. Common API flaws such as those described in the OWASP API Security Top 10 are still just as prevalent with GraphQL if not more so, particularly authorization flaws as Salt Labs found with this FinTech provider’s APIs.”
GraphQL operates as an alternative to and many feel an improvement on REST API calls, explained Garret Grajek, CEO of YouAttest. He said they create a layer that takes all API calls and then disseminates the request to multiple and various data resources. While there are many benefits, Grajek added that the vulnerabilities are fairly obvious, as well.
“Attackers have been known to use this single point of API contact as a mechanism to Denial-of-Service (DoS) the company,” Grajek said. “Many forget that the triad of security is CIA: confidentiality, integrity and availability. The DoS attack on GraphQL attacks the availability of the resources. To mitigate these DOS attacks on GraphQL, there are throttling and source identification techniques that can be used to ensure that no resource over-consumes the component. And, of course, one must be aware of which identities are manipulating the resource, as attackers are always trying to obtain the admin privileges to manipulate resources like GraphQL control.”
Ron Bradley, vice president at Shared Assessments, added that in the good old days when businesses wanted to exchange goods or services, they would walk into a warehouse, take out a paper-based shopping list, and hopefully purchase only what was on the list. When analog ruled the day and businesses wanted to exchange information or services, Bradley said data would be complied into batch files (let’s call them shopping lists) and exchanged and processed in bulk, via antiquated and insecure protocols, leaving B2B transactions vulnerable.
“Fast forward to today,” Bradley said. “In today’s fast moving parallel computing environment, the use of APIs is a must for B2B transactions. As such, the request and response of those API calls are far more complex, which is a double-edged sword. Lots of information can be processed almost instantly, but checking to make sure everything contained within an API call is valid and secure can be a daunting task. Evidence of a lack of testing can be found in the recent reports of the GraphQL Authorization flaws in the FinTech platform. One tenet in today’s computing environment will always hold true: If you don’t thoroughly and regularly test your code, someone will most definitely test it for you, and they may not be so friendly.”
Saryu Nayyar, CEO at Gurucul, said that APIs are going to only increase as an attack vector. Nayyar said estimates are the total number of public and private APIs in use is approaching 200 million, giving attackers a fertile field for breaches.
“Once an attacker has breached an API, it can have access to at least all of its services,” Nayyar said. “Commercial APIs have to check on authentication before they can be used, because there’s typically a charge associated with it. In the GraphQL case, authorization is messed up when queries are nested within code segments. The vulnerability enables attackers to access unauthorized API services against any API customer account. This lets attackers use services they aren’t entitled to, and have them charged against random customers. There also seem to be some edge cases where no authorization at all is required, letting attackers into the services (and corresponding code and potentially network) freely from the internet.”
John Bambenek, principal threat hunter at Netenrich, said when mobile app developers make applications and API services, they wrongly believe that since the phone itself doesn’t provide visibility, that an attacker could not misuse this information.
“This attack worked by reverse engineering the web calls made by the application and then issuing requests, without authorization, to see if they work… and they did,” Bambenek said. “It’s tempting to believe that mobile apps create an obscurity layer that’s hard for attackers to crack, but decades of experience show that security through obscurity just doesn’t get the job done. Organizations need to make sure every transaction requires authorization and every step of a transaction gets checked to make sure the permissions are appropriate for what’s being attempted.”