Opening Banking Without Opening Vulnerabilities

Open banking has driven the pervasive use of application programming interfaces (API) across banking, permitting third-party developers to design apps around the financial institution. But are they designed safely with information security in mind or are they unleashing vulnerabilities that allow unauthorized transactions and customer PIN code changes?

APIs are now pervasive across industries. Around the world, open banking programs have driven API-based service offerings and other data-driven customer-facing products delivered by third party providers. In addition, digital transformation initiatives are top priorities as financial services organizations look to expand the customer digital experience. The effort to attract new and keep existing customers by delivering additional value has resulted in more application services and supporting APIs.

In mid-2020, ProgrammableWeb charted over 24,000 public APIs, including over 4,000 in financial services alone. The potential attack surface has developed considerably as many banks, credit unions and fintechs have various APIs handling a variety of personally identifiable information (PII), user credentials, payment data, and social security numbers tied to internal and external facing services. Add in quickly implemented cloud migration, and all industries are using dangerous levels of vulnerable apps and APIs.

This increased adoption of API use has resulted in a dramatic increase in the attack surface they represent. Gartner predicts that this year, API attacks will become the most-frequent attack vector, causing data breaches for enterprise web applications. Already, many well-publicized API security vulnerabilities affect a wide range of organizations. Nearly 40% of organizations surveyed in Radware’s 2020-2021 “State of Web Application Security Report” reported the exposure of more than half of their applications to the internet or third-party services via APIs.

Open Web Should Not Mean Unlocked Access

At Money 20/20, Noname Security, and Alissa Knight, partner at Knight Ink and a recovering hacker, announced new research, “Scorched Earth: Hacking Bank APIs,” which unveiled a number of vulnerabilities in the banking and fintech industries. Knight revealed she was able to access 55 financial institutions through their APIs, giving her the ability to change customers' PIN codes and transfer funds in and out of customer accounts. Vulnerable targets ranged from companies with 25,000 to 68 million customers and $2.3 million to $7.7 trillion in assets.

Among the key research findings:

• Fifty-four out of 55 mobile apps that were reverse engineered contained hardcoded API keys and tokens including usernames and passwords to third-party services
• All 55 apps tested were vulnerable to interception and decryption of the encrypted traffic between the mobile apps and backend APIs.
• All APIs tested were susceptible to broken object level authorization (BOLA) vulnerabilities, which happen when applications do not correctly confirm that the user performing the request has the required privileges.
• All APIs tested were susceptible to broken authentication vulnerabilities, which refers to multiple weaknesses that attackers misuse to impersonate genuine users online.
• One of the financial institutions tested, outsourced coding to a developer, who reused that same vulnerable code across hundreds of other financial institutions thus exposed them to attacks as well.

Improving Open API Security

The Open Web Application Security Project (OWASP). a nonprofit foundation that works to improve the security of software warned, “By nature, APIs expose application logic and sensitive data such as personally identifiable information (PII) and because of this have increasingly become a target for attackers. Without secure APIs, rapid innovation would be impossible.”

OWASP also provided some typical API vulnerabilities to consider:

• Broken object level authorization. APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface level access control issue. Consider authorization checks in every function that accesses a data source using user input.
• Broken user authentication. Authentication mechanisms often implemented incorrectly allow attackers to compromise authentication tokens or exploit implementation flaws and assume other users’ identities temporarily or permanently.
• Excessive data exposure. Developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
• Lack of resources and rate limiting. Often, APIs do not impose any restrictions on the size or number of resources requested by the client/user. This can impact the API server performance, leading to denial-of-service (DoS) or authentication attacks.
• Broken function level authorization. Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, leading to authorization flaws.
• Mass assignment. Binding client provided data to data models, without proper properties filtering based on an allow list, usually leads to mass assignment. This could allow attackers to modify object properties.
• Security misconfiguration. Commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive cross-origin resource sharing (CORS), and verbose error messages containing sensitive information.
• Improper assets management. APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important.
• Insufficient logging and monitoring. Coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data.

How to Protect API Exchanges

Many traditional financial services are hurrying to deploy new technologies to compete with neobanks and fintech companies that empower consumers with frictionless digital experiences. By not developing their own apps these financial service organizations instead outsource API and mobile app development to third-parties. But how do they ensure these apps and APIs do not make their data more vulnerable to attacks?

NXTsoft’s OmniConnect Platform provides secure open APIs for the digital infrastructure needed to build and scale any fintech application in banking, savings, wealth, financial wellness, and insurance. The business functionality offered by NXTsoft in tandem with the enterprise capabilities allow financial institutions to securely accelerate their API banking transformation from almost a year to a few days.

The OmniConnect Platform provides a ready to go API Framework, letting financial institutions engage with fintech innovators, shape banking-as-a-service proficiencies and collect a fintech products and services, especially in the digital environment. The platform includes the base functionality to authenticate, onboard clients and accounts, and store and process data, which all other APIs in the OmniPlatform can utilize.