InfoSec and Compliance – With 20 years of blogging experience, DISC InfoSec blog is dedicated to providing trusted insights and practical solutions for professionals and organizations navigating the evolving cybersecurity landscape. From cutting-edge threats to compliance strategies, this blog is your reliable resource for staying informed and secure. Dive into the content, connect with the community, and elevate your InfoSec expertise!
In today’s digital landscape, APIs are crucial for connecting applications and sharing data, but they can also introduce significant security risks if not properly safeguarded. DISC InfoSec offers specialized API penetration testing services to identify and mitigate vulnerabilities, ensuring your APIs remain secure and resilient against cyber threats.
Our approach includes a thorough analysis of API functionalities, focusing on authentication, data exchange, and business logic. We meticulously examine API documentation, requests, headers, and parameters to uncover potential weaknesses that could be exploited by attackers.
By simulating real-world attack scenarios tailored to your industry and infrastructure, we provide a comprehensive assessment of your APIs. This process helps you understand the potential impact of vulnerabilities on your systems, including risks to confidentiality, integrity, and availability.
Once the testing is complete, we deliver a detailed report highlighting the findings and providing actionable recommendations for remediation. To ensure vulnerabilities are effectively addressed, DISC InfoSec offers complimentary retesting within six months of the project’s completion.
Partnering with DISC InfoSec for API penetration testing enables your organization to proactively secure its applications, protect sensitive data, and maintain user trust. Regular testing and updates are essential for staying ahead of evolving threats and ensuring a strong cybersecurity posture.
Feel free to reach out to DISC InfoSec with any questions about the API penetration testing process.
API security presents several challenges for AppSec teams, including limited visibility of API endpoints, difficulty in automating and scaling tests, and maintaining consistent processes and compliance. As API estates grow with AI, keeping track of exposed endpoints becomes harder, emphasizing the need for automation tools.
Additionally, knowledge gaps in teams and limitations in current testing tools hinder effective API security. Addressing these gaps with automated testing, enhanced tools, and training can significantly improve outcomes.
Resource and time constraints make it challenging to thoroughly test APIs. Automating tests helps reduce this burden and free up resources for deeper security measures.
API security challenges are broken down into six core areas. These include the complexity of gaining visibility into API endpoints, the difficulty in automating and scaling security tests, and ensuring consistency in processes and compliance. Other concerns involve knowledge gaps among security teams and the inadequacy of current tools for effective API testing. Finally, limited resources and time constraints make comprehensive API security testing difficult, underscoring the importance of automation to alleviate these challenges and enhance protection.
The article discusses security challenges associated with large language models (LLMs) and APIs, focusing on issues like prompt injection, data leakage, and model theft. It highlights vulnerabilities identified by OWASP, including insecure output handling and denial-of-service attacks. API flaws can expose sensitive data or allow unauthorized access. To mitigate these risks, it recommends implementing robust access controls, API rate limits, and runtime monitoring, while noting the need for better protections against AI-based attacks.
The post discusses defense strategies against attacks targeting large language models (LLMs). Providers are red-teaming systems to identify vulnerabilities, but this alone isn’t enough. It emphasizes the importance of monitoring API activity to prevent data exposure and defend against business logic abuse. Model theft (LLMjacking) is highlighted as a growing concern, where attackers exploit cloud-hosted LLMs for profit. Organizations must act swiftly to secure LLMs and avoid relying solely on third-party tools for protection.
Beyond the devices that use them, Wi-Fi hubs themselves can leak interesting data, thanks to some quirks in Apple’s geolocation system.
SOURCE: FRANTIC VIA ALAMY STOCK PHOTO
Apple’s Wi-Fi Positioning System (WPS) can be used to map and track Wi-Fi access points (APs) around the globe. But in a presentation at Black Hat 2024, University of Maryland researcher Erik Rye will demonstrate how he mapped hundreds of millions of APs in a matter of days, without even needing an Apple device or any kind of permissions along the way.
How Apple Exposes Global APs
Have you ever wondered how your phone knows where it is in the world?
The Global Positioning System (GPS) is one tool it uses, of course, but it’s not a perfect one. It becomes less effective when the device loses a clear line to the sky, and it consumes a good deal of power, which isn’t ideal for such a persistent task.
That’s where the Wi-Fi Positioning System comes in. WPS works a bit like GPS, if you substitute the satellites with Wi-Fi access points (APs).
Today, DDoS attacks stand out as the most widespread cyber threat, extending their impact to APIs.
When successfully executed, these attacks can cripple a system, presenting a more severe consequence than DDoS incidents targeting web applications.
The increased risk amplifies the potential for reputational damage to the company associated with the affected APIs.
How Does DDoS Affect Your APIs?
A DDoS attack on an API involves overwhelming the targeted API with a flood of traffic from multiple sources, disrupting its normal functioning and causing it to become unavailable to legitimate users.
This attack can be particularly damaging as APIs play a crucial role in enabling communication between different software applications, and disruption can impact the overall functionality of interconnected systems.
The impact of DDoS attacks is particularly severe for businesses and organizations that depend on their APIs to deliver essential services to customers. These attacks, employing methods such as UDP floods, SYN floods, HTTP floods, and others, pose a significant threat.
Typically orchestrated through botnets—networks of compromised devices under the control of a single attacker—DDoS attacks can cripple a target’s functionality.
DDoS attacks on APIs focus on the server and each part of your API service. But how do attackers manage to exploit DDoS attacks on APIs?
This Webinar on API attack simulation shows an example of a DDoS attack on APIs and how WAAP can protect the API endpoints.
Several factors can make APIs vulnerable to DDoS attacks:
Absence or insufficient Rate-Limiting: If an API lacks robust rate-limiting mechanisms, attackers can exploit this weakness by sending a massive volume of requests in a short period, overwhelming the system’s capacity to handle them.
Inadequate Authentication and Authorization: Weak or compromised authentication measures can allow malicious actors to gain unauthorized access to an API. Once inside, they may misuse the API by flooding it with requests, leading to a DDoS scenario.
Insufficient Monitoring and Anomaly Detection: Ineffective monitoring and anomaly detection systems can make identifying abnormal traffic patterns associated with a DDoS attack challenging. Prompt detection is crucial for implementing mitigation measures.
Scalability Issues: APIs that cannot scale dynamically in response to increased traffic may become targets for DDoS attacks. A sudden surge in requests can overload the system if it cannot scale its resources efficiently.
How Do WAAP Solutions Protect Against DDoS Attacks on API?
Web Application and API Protection (WAAP) platform offers in-line blocking capabilities for all layer seven traffic, comprehensively securing web applications and APIs.
To guarantee robust security, WAFs incorporated into WAAP solutions provide immediate defense by filtering, monitoring, detecting, and automatically blocking malicious traffic, thereby preventing its access to the server.
Active monitoring of traffic on an API endpoint enables the identification of abnormal traffic patterns commonly linked to DDoS attacks. Instances of sudden spikes in traffic volume serve as red flags for potential attacks, and a proficient monitoring system can promptly detect and address such increases.
In addition, WAAP enforces rate limits by assessing the number of requests from an IP address. API rate limiting is critical in mitigating DDoS damage and reducing calls, data volume, and types. Setting limits aligned with API capacity and user needs enhances security and improves the user experience.
To avoid impacting genuine users, find solutions that use behavioral analysis technologies to establish a baseline for rate limiting.
AppTrana WAAP’s DDoS mitigation employs adaptive behavioral analysis for comprehensive defense, detecting and mitigating various DDoS attacks with a layered approach. It distinguishes between “flash crowds” and real DDoS attacks, using real-time behavioral analysis for precise mitigation. This enhances accuracy compared to static rate limit-based systems.
APIs power the digital world—our phones, smartwatches, banking systems and shopping sites all rely on APIs to communicate. They can help ecommerce sites accept payments, enable healthcare systems to securely share patient data, and even give taxis and public transportation access to real-time traffic data.
Nearly every business today now uses them to build and provide better sites, apps and services to consumers. However, if unmanaged or unsecured, APIs present a goldmine for threat actors to exfiltrate potentially sensitive information.
“APIs are central to how applications and websites work, which makes them a rich, and relatively new, target for hackers,” said Matthew Prince, CEO at Cloudflare. “It’s vital that companies identify and protect all their APIs to prevent data breaches and secure their businesses.”
APIs popularity boosts attack volume
The seamless integrations that APIs allow for have driven organizations across industries to increasingly leverage them – some more quickly than others. The IoT, rail, bus and taxi, legal services, multimedia and games, and logistics and supply chain industries saw the highest share of API traffic in 2023.
APIs dominate dynamic Internet traffic around the globe (57%), with each region that Cloudflare protects seeing an increase in usage over the past year. However, the top regions that explosively adopted APIs and witnessed the highest traffic share in 2023 were Africa and Asia.
As with any popular business critical function that houses sensitive data, threat actors attempt to exploit any means necessary to gain access. The rise in popularity of APIs has also caused a rise in attack volume, with HTTP Anomaly, Injection attacks and file inclusion being the top three most commonly used attack types mitigated by Cloudflare.
Shadow APIs provide a defenseless path for threat actors
Organizations struggle to protect what they cannot see. Nearly 31% more API REST endpoints (when an API connects with the software program) were discovered through machine learning versus customer-provided identifiers – e.g., organizations lack a full inventory of their APIs.
Regardless if an organization has full visibility of all their APIs, DDoS mitigation solutions can help block potential threats. 33% of all mitigations applied to API threats were blocked by DDoS protections already in place.
“APIs are powerful tools for developers to create full-featured, complex applications to serve their customers, partners, and employees, but each API is a potential attack surface that needs to be secured,” said Melinda Marks, Practice Director, Cybersecurity, for Enterprise Strategy Group. “As this new report shows, organizations need more effective ways to address API security, including better visibility of APIs, ways to ensure secure authentication and authorization between connections, and better ways to protect their applications from attacks.”
The OWASP Foundation’s Top Ten lists have consistently aided defenders in directing their attention towards particular technologies, and the OWASP API (Application Programming Interface) Security Top 10 2023 is no different. Originally formulated five years ago and recently revised, its goal is to tackle evolving attack techniques.
However, the OWASP API Security Project leaders had their work cut out when deciding how to group and prioritize the threats. The list is put together based upon industry input and must reflect compliance concerns, so it was never going to completely satisfy all people. The question is, does it go far enough to be of value to those in the thick of it when it comes to API development and defense?
What has changed and what has stayed the same?
By comparing the old and the new list, we can see that the top two threats – API1 Broken Object Level Authorization (BOLA) and API2 Broken User Authentication – have remained unchanged. API1 denotes the manipulation of the identification of an object that is sent within a request to the API while API2 marks the abuse of authentication mechanisms through attacks such as credential stuffing, including forgotten/rest password functions. They provide the quickest wins for attackers, and it’s easy to see why these continue to the top the list.
API3 replaced Excessive Data Exposure with Broken Object Property Level Authorization. Does this mean we have solved the problem of sensitive data exposure? Alas, no, it continues to be a huge problem. What this change signifies is the next stage an attacker would take when exploiting sensitive data exposure, i.e., break through the property level authorization. So why has the Project decided to make the change? Probably for the sake of clarity, because sensitive data exposure is an issue that spans the rest of the list. But some, including myself, would argue that this isn’t the right way to present the issue, because it declasses what is a very serious issue.
Similarly, API6 was Mass Assignment in 2019 and is now Unrestricted Access to Sensitive Business Flows. Are they different? Not really. Both are talking about taking advantage of objects and their properties within the application flow, with the examples listed on the project page referring to a ride share app where functionality is exploited in the backend. There is, however, something subtle about the naming that makes the 2023 version seem like something that needs to be fixed, rather than being nebulous and confusing, so in that respect it is an improvement.
Bring bots into the mix
API6 also plays to how an API that isn’t functioning properly can swiftly end up with attack automation being utilized against it in the form of bot attacks. This is important because there’s always been an artificial distinction made between API and bot attacks, with the security sector offering different solutions for each when the reality is that automated attacks can and are launched against APIs. So, it no longer makes sense to monitor for API attacks and bot attacks separately: bot mitigation has to become part of API security. This is apparent in our recent report, which revealed that automated attacks dwarfed other TTPs in the analysis of traffic during the last quarter of 2022.
Overall, the new list largely redefines many of the previous tactics, techniques and procedures (TTPs) in a bid to be more inclusive. API4, for instance, has moved from Lack of Resources and Rate Limiting to become Unrestricted Resource Consumption, reflecting the fact that rate limiting extends beyond the issue of network capacity. Other resources that can be abused if limits are not set include CPU, memory and storage, for example, but just as importantly, service providers can find service resources maxed out by API requests. They may provide emails, texts or phone calls and a repeat API request can see that service provider rack up huge service costs.
However, there are some changes in the order and new concepts in there towards the end. API7 Security Misconfiguration drops a place to API8 as there has been progress made in this area.
API7 is now Server Side Request Forgery (SSRF). APIs are a prime target for SSRF attacks because they routinely channel outbound traffic from an application. Developers often access external resources, such as web hooks, file fetching from URLs or custom SSO and URL previews – states the Project – or cloud or container providers expose management and control channels to compromise via HTTP. And the old API8, Injection attacks? That’s no longer a separately categorized threat again because it’s typically adopted in many of the other attack types.
Significant changes
API9 sees another subtle but important change in the wording: from Improper Assets Management to Improper Inventory Management. This reflects the heightened number of shadow APIs that are out there which once deployed are no longer monitored and effectively fall off the security team’s radar. Unmanaged, unknown and unprotected, these APIs are then sitting ducks for attackers who now actively search for them. In fact, we found that 45 billion search attempts were made for shadow APIs during the second half of 2022, compared to five billion during the first six months. A runtime API inventory that continuously monitors production APIs is therefore vital to ensure all APIs that go live are protected yet it’s one of the key failings in organisations today.
Finally, API10 has changed from Insufficient Logging and Monitoring, now largely covered by API9, to Unsafe Consumption of APIs. This reflects the extension we’ve seen of the API software chain, with APIs now often being integrated with other APIs. The problem that has arisen is that developers tend to inherently trust interactions with these external APIs, particularly from well-known companies, even though they may be flawed and/or be leaking data.
Clearly a great deal of thought has gone into adjusting the OWASP API Top Ten to more accurately address the TTPs that attackers are now using. The result sees both minor and some major changes to the list all of which are justified. Indeed, it’s not the descriptors but the list itself that is problematic. It’s an arbitrary concept that’s designed to attract attention to and heighten the profile of API security but does it do anything to further how we defend against these attacks?
How it holds up under an attack scenario
If we use breach analysis, we can compare a typical breach to the categories in the list to see how the concept stacks up. Many breaches start out with an API that the victim organization was unaware they had ( API9 in the 2023 list). This API is then found to return some kind of data about a user that isn’t the attacker (API1). Now the attacker is going to create attack automation using a bot to try to exploit this as quickly and as completely as possible (API6), completing the attack chain and giving the attacker access to data hidden in the victim organization’s systems.
It’s evident that such an attack would cross at least three of the attack categories so prioritizing them becomes immaterial. Indeed, such trinity attacks are gaining ground, with 100 million detected during the first half of 2022.
What’s more, as well as seeing attackers pivot during an attack and utilize known TTPs, we are also seeing them come up with unique TTPs to attempt to subvert the API. These grew more than fivefold between June and November (from 2,000 to 11,000). Most of those attacks were geared towards achieving account takeover (ATO), scraping to perform reconnaissance or to exfiltrate data, and hunting for business logic flaws within the API to commit fraud.
Keeping up with such diverse attacks requires the security team to focus not just on its defense but methods of detection and mitigation. Whether it is knowing where APIs are, testing them for flaws or stopping bots attacking unknown flows, API security needs to become more comprehensive, tracking and protecting the API throughout its entire lifecycle.
A sound summary of TTPs
The new OWASP API Top 10 may not be perfect, but it does cover the bases and provides a great starting point from which to address the topic. It now recognizes that some attack methods such as sensitive data and exposure and injection attacks span multiple TTPs and so do not require a separate category. It also amplifies the need for bot mitigation as part of API security, and the complex nature of API ecosystems that are seeing them integrated with one another, for instance.
But its structure is not conducive to showing how these attacks are being used in the wild. It still compartmentalizes these attacks when threat actors are becoming much more versatile and combining them.
Realistically, the only way of keeping pace with this rapidly evolving threat landscape is to monitor and manage those APIs. Creating a runtime inventory, conducting API threat surface assessments, carrying out specification anomaly detection and putting in place real-time automated bot detection and mitigation are all now essential to protect the API footprint of the business.
Applied Programming Interfaces (API) are an essential component of most modern programs and applications. In fact, cloud applications and mobile applications now rely heavily on APIs because they are designed to control various elements. Many large companies have hundreds or even thousands of APIs built into their infrastructure. The number of API interfaces will only increase over time.
It’s important to keep your website or web applications foolproof against malicious activities. What you need to do is to use some security testing tools to identify and measure the extent of security issues with your web application(s).
The primary function of security testing is to perform functional testing of a web application under observance and find as many security issues as possible that could potentially lead to hacking. All of this is done without the need to access the source code. To prevent API vulnerabilities and weaknesses, security testing is critical. API security testing ensures APIs work as designed and can only do what they are intended to. A particular tool might be the best choice for one company but not another, depending on their respective needs. Below is the list of open source API testing tools. As per cyber security course experts, although open source tools, as a rule, do not have the same support as commercial platforms, experienced developers can easily deploy them, often even for free, to increase the security level of their APIs
TAURUS
Taurus makes it possible to turn autonomous API testing programs into an ongoing testing process. At first look, the tool is easy to use. The user installs it, creates a configuration file and allows the tool to do its job. There are additional functions: the ability to create interactive reports, more complex scripts for testing their APIs, configure failure criteria to immediately begin to eliminate the problems detected.
APACHE JMETER
Apache JMeter (it is not surprising that it was written in Java) was originally made to test the load on web applications, but recently expanded its capabilities – now it is suitable for testing the operation of any application, program or API. Its functionality allows you to test performance on both static and dynamic resources. The tool can generate a large simulated (but realistic) load of traffic so that developers can understand how their APIs will cope during load testing. Apache JMeter does not require programming skills. It can handle many different types of applications, servers and protocols, and it supports request chaining. Tests can use CSV files to generate heavy loads of realistic traffic that put APIs under pressure.
CRAPI
At the tool craPI is not the most nice name (“crap” – “sucks”), but it efficiently performs its API testing functions. This is one of the few tools that can connect to the target system and use a basic set of tests with a whole set of additional functions to study root client. As per cyber security course experts, the program can do this without the need to create any new connections. Advanced API developers will be able to save a lot of time with cRAPI .
ASTRA
Astra mainly focuses on the transfer of a representative state (REST) of the API, which can be extremely hard because they are constantly changing. Given that the REST architecture stresses scalability when interacting between components, it can be difficult to ensure the security of the REST API over time. Astra helps solve this problem by offering integration with CI / CD-Pipeline, and by checking that the most common vulnerabilities no longer appear in the supposedly safe REST API . Astra can be used by security engineers or developers as an integral part of their process, so they can detect and patch vulnerabilities early during the development cycle.
KARATE
Karate is an open source framework that combines automated API testing, performance testing and mocking into a single framework. While it is implemented in Java, it doesn’t require users to have advanced programming skills. As per cyber security course experts, test definitions can also serve as the functional documentation for the API itself. Karate can be integrated with CI/CD tools. Additionally, tests can double as performance tests with the addition of Gatling, which verifies if server responses are as expected under load. Karate has extensive documentation, a wide range of test examples and an active user community.
API security is an undervalued but crucial aspect of information security. Some of the most common cyber attacks exploit APIs and web applications, and if organisations are to stay secure, they must test their systems to identify and eradicate weaknesses.
Organisations can achieve this with API penetration tests. An ethical hacker (or ‘penetration tester’) will examine your applications using the same techniques that a cyber criminal would use. This gives you a real-world insight into the way someone might compromise your systems.
Web application and API tests look specifically at security vulnerabilities introduced during the development or implementation of software or websites. There is no single checklist of how exactly the test should be conducted, but there are general guidelines.
Benefits of API penetration testing
The primary purpose of an API penetration test is to protect your organisation from data breaches. This is crucial given the increased risk of cyber attacks in recent years; according to a UK government report, 39% of surveyed organisations said they suffered a security breach in the past year.
By conducting an API penetration test, you will gain a real-world overview of one of the biggest security threats that organisations face. The tester will use their experience to provide guidance on specific risks and advise you on how to address them.
But penetration tests aren’t only about closing security vulnerabilities. Mitigating the risk of security incidents has several other benefits. For instance, you protect brand loyalty and corporate image by reducing the likelihood of a costly and potentially embarrassing incident.
Penetration testing also helps you demonstrate to clients and potential partners that you take cyber security seriously. This gives you a competitive advantage and could help you land higher-value contracts.
Perhaps most notably, penetration testing is a requirement for several laws and regulations. Article 32 of the GDPR (General Data Protection Regulation), for example, mandates that organisations regularly test and evaluate the effectiveness of their technical and organisational measures employed to protect personal data.
Likewise, if your organisation is subject to the PCI DSS (Payment Card Industry Data Security Standard), you must conduct external penetration tests at least once per year and after any significant changes are made to your systems.
API penetration testing checklist
IT Governance has its own proprietary checklist when conducting API and web application penetration tests.
The system is modelled on the OSSTMM (Open Source Security Testing Methodology Manual) and the OWASP (Open Web Application Security Project) methodologies.
A high-level overview of our process is outlined below, with a brief description of what is assessed during each section.
1. Authentication
The penetration tester ensures that appropriate mechanisms are in place to confirm a user’s identity. They then review how the authentication process works, using that information to circumvent the authentication mechanism.
2. Authorisation
The tester verifies that access to resources is provided only to those permitted to use them.
Once roles and privileges are understood, the tester attempts to bypass the authorisation schema, finding path-traversal vulnerabilities and ways to escalate the privileges assigned to the tester’s user role.
3. Session management
The tester ensures that effective session management configurations are implemented. This broadly covers anything from how user authentication is performed to what happens when logging out.
4. Input validation and sanitisation
The tester checks that the application appropriately validates and sanitises all input from the user or the environment before using it.
This includes checking common input validation vulnerabilities such as cross-site scripting and SQL injection, as well as other checks such as file uploads, antivirus detection and file download weaknesses.
5. Server configuration
The tester analyses the deployed configuration of the server that hosts the web application. They then verify that the application server has gone through an appropriate hardening process.
6. Encryption
The tester assesses encryption security around the transmission of communication. This includes checking for common weaknesses in SSL/TLS configurations and verifying that all sensitive data is being securely transferred.
7. Information leakage
The tester reviews the application configuration to ensure that information is not being leaked.
This is assessed by reviewing configurations and examining how the application communicates to discover any information disclosure that could cause a security risk.
8. Application workflow
The tester determines whether the application processes and workflows can be bypassed.
Tests are conducted to ensure that application workflows cannot be bypassed by either tampering with the parameters or forcefully browsing. This ensures the integrity of the data.
9. Application logic
The tester analyses how the application uses, stores and maintains data. They do this by checking the underlying technology and any mitigating controls that may affect the risk to the application.
10. Report
The tester documents their findings. Their reports contains an executive summary, which provides a high-level, non-technical summary of any identified vulnerabilities, alongside a summary of the organisation’s business risks and an overall risk rating.
It also contains a comprehensive review of testing details, such as the scope of the assessment, descriptions of the vulnerabilities identified and their impact, plus proofs of concept that support the findings.
Finally, the report provides the tester’s commentary, where they discuss the issues identified and how the vulnerabilities could be linked within an attack chain. This is supplemented with remediation advice and supporting references.
A recent report reveals that the number of attacks on financial service APIs and web applications worldwide increased by 257%.
There are more APIs in use than ever, and the average FinTech company takes advantage of hundreds if not thousands of connections in their daily operations.
APIs have become a critical component of fintech but also open new vulnerabilities. 48% of financial service company states that API security remains the top concern of their API utilization.
So, what are the top FinTech API security challenges?
Impacts Of API Attacks on Fintech
API attacks on fintech companies can severely affect the financial industry and the customers who rely on these services. These attacks are becoming increasingly frequent as fintech companies grow in popularity and usage.
API attacks can have serious consequences, including financial loss and damage to a company’s reputation. These attacks can steal sensitive information like login credentials or financial data. This data can be used for identity theft, financial fraud, and other criminal activities, causing significant financial losses for the affected customers.
They can also be used to disrupt services or conduct fraudulent transactions. Additionally, service disruptions can lead to lost business, damage to reputation, and loss of customer trust.
API attacks can also have a ripple effect throughout the financial industry. If a major fintech company is compromised, it can cause mistrust and uncertainty among other financial institutions. This can lead to increased scrutiny and regulations for the entire industry.
Fintech companies must take proactive measures to secure their APIs and protect their customers’ data. This includes implementing robust authentication and authorization mechanisms, encryption for sensitive data, and regularly testing and updating security measures.
Additionally, having an incident response plan to address and mitigate potential breaches quickly is crucial in preserving customer trust and minimizing damage to the company’s reputation.
OWASP Top 10 API Security Risks
OWASP API Top 10 isn’t necessarily FinTech-specific. But with API usage exploding in every industry, it’s worth taking some time to understand the risks they’ve identified. After all, many modern companies would not exist without APIs.
Broken object-level authorization
Broken user authentication
Excessive data exposure
Lack of resources to rate limiting
Broken function-level authorization
Mass assignment
Security misconfiguration
Injection
Improper assets management
Insufficient logging and monitoring
What are the Challenges of Protecting APIs?
Explosive increase in API utilization
There has been a significant increase in the use of APIs in fintech in recent years. APIs allow fintech companies to easily integrate with other systems and services, such as banking platforms, payment processors, and data providers. This enables fintech companies to build new products and services quickly and easily and offer their customers a more comprehensive range of features.
As many APIs are integrated into third-party systems, it can be challenging to monitor for potential vulnerabilities.
Connections Create New Vulnerabilities & Risks
Most applications are made up of multiple services connected through APIs. This interconnectivity can inadvertently create new risks and vulnerabilities.
As interconnected services increase, the complexity of securing API connections also increases. Each connection represents a potential vulnerability that malicious actors could exploit. Additionally, as more services are connected, the attack surface for potential vulnerabilities also increases.
Data Exposure
FinTech companies handle sensitive financial information, making them prime targets for cyber attacks.
Tracking and monitoring for potential security threats can make it more difficult as more data is exposed through APIs. It can be difficult to track exactly,
What needs to be protected and how?
Where are APIs exposing data?
Is the exposure necessary?
The larger the amount of data and the more diverse the sources, the harder it can be to identify and respond to security incidents.
Furthermore, the increased use of cloud and third-party services can complicate tracking, as it can be challenging to determine where data is being stored and how it is being used.
Data exposure can also be a moving target based on API updates. For maximum security, you must always remain mindful of changes.
Rapid Development
An API in FinTech is perfect for rapid innovation and development. New updates, features, and functionality can be rolled out quickly and smoothly.
APIs are constantly changing. And because of that, app developers need to roll out multiple updates yearly.
This creates a challenge for the security team because they need to be able to keep pace with changes and know what security structures need to include.
Developers Can’t Catch Everything
It’s difficult, if not impossible, to catch all possible vulnerabilities before deployment. Despite the care taken during the development process, it’s unrealistic to think that developers would be aware of everything that could go wrong.
Developers also need to move quickly. Because there are always new features to add and innovations to make, security can be an afterthought for better or worse.
Traditional Security Isn’t Enough
Most FinTech companies have sophisticated runtime security stacks already. These feature multiple layers of security tools. But these solutions simply aren’t enough when it comes to API vulnerabilities.
Traditional approaches to FinTech API security, such as basic authentication, do not provide adequate protection. Because they rely on static, easily compromised credentials and do not consider the dynamic nature of API usage.
Traditional approaches often rely on static rules and signatures, which can be easily bypassed by attackers who know how to evade them.
Additionally, these approaches do not provide visibility into API activity, making detecting and responding to threats difficult.
For API security, it is necessary to use more modern security techniques specifically designed for this purpose.
Lack of skills
Appdome says lack of skills was one of the top two challenges in an organization’s API strategy. Many organizations do not specialize in app security. And there are many factors to consider: development framework, OS, security features, and more.
API security should be a top priority for fintech. They could be turbulent if you don’t know how to navigate the waters ahead. Your best bet is to find a partner to assist you in setting up the necessary security infrastructures. The peace of mind with it will be well worth the investment.
API Protection with AppTrana
AppTrana API protection is a comprehensive security solution that provides advanced protection for your APIs.
One of its key features is API discovery, which allows you to automatically identify all the APIs within your organization and track their usage. This helps you to understand how your APIs are being used and identify any potential security risks.
Another important feature of AppTrana is its positive security model, which allows only known and trusted traffic to access your APIs.
AppTrana also includes rate limiting, a technique used to control the number of requests that can be made to an API within a certain period. This helps prevent malicious actors from overwhelming your APIs with many requests, which can cause them to become unresponsive or crash.
In addition to these features, AppTrana provides real-time monitoring and reporting, so you can quickly identify and respond to any security incidents. This includes detailed logs of all API activity and alerts for suspicious activity, such as excessive rate limiting or bot fingerprinting.
JWT is short for JSON Web Token, where JSON itself is short for JavaScript Object Notation.
JSON is a modernish way of representing structured data; its format is a bit like XML, and can often be used instead, but without all the opening-and-closing angle brackets to get in the way of legibility.
For example, data that might be recorded like this in XML…
Whether the JSON really is easier to read than the XML is an open question, but the big idea of JSON is that because the data is encoded as legal JavaScript source, albeit without any directly or indirectly executable code in it, you can parse and process it using your existing JavaScript engine, like this:
The output string undefined above merely reflects the fact that console.log() is a procedure – a function that does some work but doesn’t return a value. The word Sophos is printed out as a side-effect of calling the function, while undefined denotes what the function calculated and sent back: nothing.
The popularity of JavaScript for both in-browser and server-side programming, plus the visual familiarity of JSON to JavaScript coders, means that JSON is widely used these days, especially when exchanging structured data between web clients and servers.
And one popular use of JSON is the JWT system, which isn’t (officially, at any rate) read aloud as juh-witt, as it is written, but peculiarly pronounced jot, an English word that is sometimes used to refer the little dot we write above above an i or j, and that refers to a tiny but potentially important detail.
Authenticate strongly, then get a temporary token
Loosely speaking, a JWT is a blob of encoded data that is used by many cloud servers as a service access token.
The idea is that you start by proving your identity to the service, for example by providing a username, password and 2FA code, and you get back a JWT.
The JWT sent back to you is a blob of base64-encoded (actually, URL64-encoded) data that includes three fields:
Which crytographic algorithm was used in constructing the JWT.
What sort of access the JWT grants, and for how long.
A keyed cryptographic hash of the first two fields, using a secret key known only to your service provider.
Once you’ve authenticated up front, you can make subsequent requests to the online service, for example to check a product price or to look up an email address in a database, simply by including the JWT in each request, using it as a sort-of temporary access card.
Clearly, if someone steals your JWT after it’s been issued, they can play it back to the relevant server, which will typically give them access instead of you…
…but JWTs don’t need to be saved to disk, usually have a limited lifetime, and are sent and received over HTTPS connections, so that they can’t (in theory at least) easily be sniffed out or stolen.
When JWTs expire, or if they are cancelled for security reasons by the server, you need to go through the full-blown authentication process again in order to re-establish your right to access the service.
But for as long they’re valid, JWTs improve performance because they avoid the need to reauthenticate fully for every online request you want to make – rather like session cookies that are set in your browser while you’re logged into a social network or a news site.
Security validation as infiltration
Well, cybersecurity news today is full of a revelation by researchers at Palo Alto that we’ve variously seen described as a “high-severity flaw” or a “critical security flaw” in a popular JWT implementation.
In theory, at least, this bug could be exploited by cybercriminals for attacks ranging from implanting unauthorised files onto a JWT server, thus maliciously modifying its configuration or modifying the code it might later use, to direct and immediate code execution inside a victim’s network.
Simply put, the act of presenting a JWT to a back-end server for validation – something that typically happens at every API call (jargon for making a service request) – could lead malware being implanted.
But here’s the good news:
The flaw isn’t intrinsic to the JWT protocol. It applies to a specific implementation of JWT called jsonwebtoken from a group called Auth0.
The bug was patched three weeks ago. If you’ve updated your version of jsonwebtoken from 8.5.1 or earlier to version 9.0.0, which came out on 2022-12-21, you’re now protected from this particular vulnerability.
Cybercriminals can’t directly exploit the bug simply by logging in and making API calls. As far as we can see, although an attacker could subsequently trigger the vulnerability by making remote API requests, the bug needs to be “primed” first by deliberately writing a booby-trapped secret key into your authentication server’s key-store.
According to the researchers, the bug existed in the part of Auth0’s code that validated incoming JWTs against the secret key stored centrally for that user.
As mentioned above, the JWT itself consists of two fields of data denoting your access privileges, and a third field consisting of the first two fields hashed using a secret key known only to the service you’re calling.
To validate the token, the server needs to recalculate the keyed hash of those first two JWT fields, and to confirm the hash that you presented matches the hash it just calculated.
Given that you don’t know the secret key, but you can present a hash that was computed recently using that key…
…the server can infer that you must have acquired the hash from the authentication server in the first place, by proving your identity up front in some suitable way.
Data type confusion
It turns out that the hash validation code in jsonwebtoken assumes (or, until recently, assumed) that the secret key for your account in the server’s own authentication key-store really was a cryptographic secret key, encoded in a standard text-based format such as PEM (short for privacy enhanced mail, but mainly used for non-email purposes these days).
If you could somehow corrupt a user’s secret key by replacing it with data that wasn’t in PEM format, but that was, in fact, some other more complex sort of JavaScript data object…
…then you could booby-trap the secret-key-based hash validation calculation by tricking the authentication server into running some JavaScript code of your choice from that infiltrated “fake key”.
Simply put, the server would try to decode a secret key that it assumed was in a format it could handle safely, even if the key wasn’t in a safe format and the server couldn’t deal with it securely.
Note, however, that you’d pretty much need to hack into the secret key-store database first, before any sort of truly remote code execution trigger would be possible.
And if attackers are already able to wander around your network to the point that they can not only poke their noses into but also modify your JWT secret-key database, you’ve probably got bigger problems than CVE-2022-23539, as this bug has been designated.
What to do?
If you’re using an affected version of jsonwebtoken, update to version 9.0.0 to leave this bug behind.
However, if you’ve now patched but you think crooks might realistically have been able to pull off this sort of JWT attack on your network, patching alone isn’t enough.
In other words, if you think you might have been at risk here, don’t just patch and move on.
Use threat detection and response techniques to look for holes by which cybercriminals could get far enough to attack your network more generally…
…and make sure you don’t have crooks in your network anyway, even after applying the patch.
The majority of major automobile manufacturers have addressed vulnerability issues that would have given hackers access to their vehicles to perform the following activities remotely:-
Lock the car
Unlock the car
Start the engine
Press the horn
Flas the headlights
Open the trunk of certain cars made after 2012
Locate the car
Flaw in SiriusXM
SiriusXM, one of the most widely used connected vehicle platforms available on the market, has a critical bug in its platform that affects all major vehicle brands.
There is a particular interest among security researchers in the area of connected cars, like Yuga Labs’ Sam Curry. In fact, he’s the one who was responsible for discovering a security hole in the connected cars of major car manufacturers during his routine research.
More car hacking!
Earlier this year, we were able to remotely unlock, start, locate, flash, and honk any remotely connected Honda, Nissan, Infiniti, and Acura vehicles, completely unauthorized, knowing only the VIN number of the car.
There are a number of car manufacturers who use Sirius XM telematics and infotainment systems as a part of their vehicle technology.
Affected Car Brands
Here below we have mentioned the brands’ names that are affected due to this critical bug in SiriusXM:-
Acura
BMW
Honda
Hyundai
Infiniti
Jaguar
Land Rover
Lexus
Nissan
Subaru
Toyota
Vulnerability Analysis
During the process of analyzing the data, it was found that there is a domain (http://telematics(.)net) that is used during the vehicle enrollment process for the remote management of Sirius XM.
The flaw is associated with the enrollment process for SiriusXM’s remote management functionality which results in the vehicle being tampered with.
There is not yet any technical information available about the findings of the researchers at the present time, since they haven’t shared anything in detail.
Upon further analysis of the domain, it becomes apparent that the Nissan Car Connected App is one of the most plentiful and frequently referenced apps in this domain.
In order for the data exchanged through the telematics platform to be authorized, the vehicle identification number (VIN) only needs to be used. The VIN of the vehicle can therefore be used to carry out a variety of commands by anyone who knows the number.
The next step would be to log in to the application later on, and then the experts examined the HTTPS traffic that came from a Nissan car owner.
Since exploiting this involved many steps, we took all of the requests necessary to exploit this and put it into a python script which only needed the victim's email address. After inputting this, you could then execute all commands on the vehicle and takeover the actual account. pic.twitter.com/Bz5G5ZvHro
Researchers discovered one HTTP request during the scan in which they conducted a deep analysis.
It is possible to obtain a bearer token return and a “200 OK” response by passing a VPN prefixed ID through as a customerID in the following way:-
Using the Authorization bearer in an HTTP request, researchers attempted to obtain information about the user profile of the victim and, as a result, they successfully retrieved the following information:-
Name
Phone number
Address
Car details
In addition to this, the API calls used by SiriusXM for its telematics services worked even if the user did not have an active subscription with SiriusXM.
As long as the developers or owners are not involved in the process of securing a vulnerable app, it is impossible to guarantee the security of that app. This is why they should be the only ones who can issue security updates and patches.
Recommendations
Here below we have mentioned the recommendations made by the security analysts:-
Ensure that you do not share the VIN number of your car with unreliable third parties.
In order to protect your vehicle from thieves, it is imperative to use unique passwords for each app connected to the vehicle.
Keep your passwords up-to-date by changing them on a regular basis.
Keeping your system up-to-date should be a priority for users.
APIs are a powerful tool for organizations to build innovative products and services. Research has shown that over 90% of developers use APIs and 56% have reported that APIs help them to develop better products. However, this increase in demand means there is also an increase in risk.
API security is not a new problem. It’s something that organizations have been trying to tackle for years. But as cloud computing becomes ubiquitous, we are seeing an explosion in demand for secure APIs that provide reliable access to information from different sources over different networks (and even in real time). This means that there are many more potential points of entry for malicious actors looking to exploit vulnerabilities in your infrastructure or steal sensitive data through unconventional methods.
This article highlights and expands on 7 API security related statistics you should be aware of: 41% of organizations suffered API security incidents in the past year
91% of IT professionals believe API security should be considered a priority – This report shows that 91% of IT experts believe that API security should be prioritized especially because over 70% of corporate firms are expected to employ more than 50 APIs. 8 out of 10 IT administrators desire more authority over the APIs used by their company
If you’re into web API security testing, then you know that API hacking books are a valuable resource. They can teach you new things, introduce you to new concepts around breaking web application programming and help you stay up-to-date on the latest trends in your field. That’s why I’ve put together this list of 5 essential books for any API hacker!
API security and you
So before I go through the list of book recommendations, I want to preface that if you are a security researcher who wants to conduct web API security testing, the reality is it’s just as important to focus on the web applications themselves.
As such, a crash course in web hacking fundamentals never hurts. So some of my recommendations may seem more focused on that than on breaking web application programming interfaces.
You may also notice that I also recommend a few books that focus on bounty programs and make it possible to make a living as you break APIs.
The point is, regardless of where you are in your API hacking career, these books can help. I have organized them in such a way that if you can’t afford to buy them all just yet, start from the top and work your way down.
Book #1 : Hacking APIs: Breaking Web Application Programming Interfaces
This is one of the few books that is actually dedicated to API hacking.
This book is a great resource for anyone who wants to learn more about API security and how to hack into web applications. It provides in-depth information on how to break through various types of APIs, as well as tips on how to stay ahead of the curve in this rapidly changing field. Corey also shares his own personal experiences with API hacking, which makes the content even more valuable. If you’re interested in learning more about API security and want to start from the basics, then this is the perfect book for you!
Book #2 : The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws
This book is a tomb of information. It’s the oldest book on the list and by far the largest.
The Web Application Hacker’s Handbook is an essential read for anyone looking to understand how web application vulnerabilities are discovered and exploited. The book is filled with in-depth technical information and real-world examples that will help you understand the inner workings of web applications and how to protect them from potential attacks.
One of the best features of this book is the “Hands-On” sections, which provide you with step-by-step instructions on how to find and exploit various vulnerabilities. This makes it an ideal resource for both beginner and experienced hackers alike.
If you’re looking to beef up your skills in web application security, then The Web Application Hacker’s Handbook is a must-read!
Book #3 : Web Application Security: Exploitation and Countermeasures for Modern Web Applications
Sometimes before focusing on offense, we have to know defensive tactics.
This book provides in-depth coverage of all the major areas of web application security, from vulnerabilities and exploits to countermeasures and defense strategies. Written by security expert Andrew Hoffman, this book is packed with real-world examples and step-by-step instructions that will help you understand how developers protect their web applications from potential attacks.
If you’re serious about web application security, then this is the perfect book for you!
Book #4 : Bug Bounty Bootcamp: The Guide to Finding and Reporting Web Vulnerabilities
If you are looking at being an independent security researcher focused on web API security testing, finding high payout API bugs may be important.
Bug Bounty Bootcamp is a guide to becoming a bug bounty hunter. The book covers the basics of hunting for bugs, including how to find and report them. It also includes a number of case studies of successful bug bounty hunting, detailing methods and strategies.
In chapter 24 of the Expert Techniques section, Vicki goes deeper into discussing multiple API attack techniques.
Overall, Bug Bounty Bootcamp is an informative and well-written guide that should be of interest to anyone considering a career in API hacking through bug bounty hunting.
Book #5 : Real-World Bug Hunting: A Field Guide to Web Hacking
“Real-World Bug Hunting” is a brilliant resource for anyone who aspires to be a professional bug hunter. The book is written by Peter Yaworski, who is himself a professional bug hunter.
He begins by delving into the mindset of a bug hunter – what drives them to find vulnerabilities in software and systems? He then provides an overview of the bug hunting process, from identifying potential targets to writing up a report. The bulk of the book is devoted to teaching readers how to find and exploit common web application vulnerabilities.
Yaworski provides clear and concise explanations of each vulnerability, along with examples of real-world exploits. He also offers advice on how to avoid getting caught by security teams and how to maximize the value of your findings. “Real-World Bug Hunting” is an essential read for anyone who wants to make a career out of finding bugs.
Conclusion
These five books are essential readings for anyone interested in hacking APIs. They provide detailed information on how to find and exploit vulnerabilities, as well as defensive tactics and strategies. If you want to be a successful API bug bounty hunter, then these books will also give you the tools and techniques you need to get started.
APIs are prevalent in SaaS models and modern applications across the board. API security refers to best practices applied to aspects of these APIs to ensure they’re protected from cybercriminals.
Web API security includes access control and privacy, as well as the detection of attacks via reverse engineering and exploitation of vulnerabilities. Since APIs enable the easy development of client-side applications, security measures are applied to applications aimed at employees, consumers, partners and others via mobile or web apps.
Why API Security Should Be a Top Priority
Attacking APIs requires first learning about a company’s APIs. To do so, bad actors perform extensive, drawn-out reconnaissance. That activity flies under the radar of existing technology such as API gateways and web application firewalls (WAFs). APIs make a very lucrative target for bad actors since they are a pipeline to valuable data and they’re poorly defended. Since data is the lifeblood of an organization, protecting it – and end-users – is paramount to avoiding breaches and the financial and reputational harm that comes with them.
In 2017, Gartner predicted API attacks would be the greatest threat to organizations in 2022. The year has arrived, and this foresight has proved accurate. Cyberattacks on APIs have exposed vulnerabilities and cost businesses a lot of time, money and heartache to recover from these breaches.
Major organizations like Peloton and LinkedIn have recently fallen victim to API-driven attacks, proving that even enterprise-class businesses (with enterprise-class budgets) are no match for cybercriminals. API attacks grew an astounding 681% in 2021, showing that businesses cannot afford to be complacent about this threat.
API Security Checklist for Development and Implementation
As with any security objective, it’s crucial to implement best practices and ensure you close all gaps in your API security strategy. While it can be overwhelming, an organized approach will help break your plan into manageable pieces. Start with scope and prioritization:
Perform penetration tests for your APIs, and know that to get a clear picture of the security status, you’ll need runtime protection
Assess the entirety of your environments, including your digital supply chain and APIs that fall outside of your API management suite
If you need to start small, prioritize runtime protection to protect from attackers while your application and API teams delve further into the comprehensive security strategy
Design and Development
Building a robust API security strategy is crucial, but that doesn’t mean you need to start from scratch. Great supportive resources, including the OWASP Application Security Verification Standard (ASVS), are available to help you design your approach.
Ensure you draft your organization’s build and integration security requirements, include business logic when performing design reviews and implement practices for coding and configuration relevant to your security stack.
Documentation
Ensure that you keep comprehensive documentation for application and integration teams. Documentation should cover security testing, design reviews, operations and protection. By documenting the stages of your process, you will ensure continuity in your testing and protection approaches.
Discovery and Cataloging
Ideally, your documentation process will be thorough and consistent. In reality, however, sometimes things are missed. Therefore, organizations must implement automated discovery of API endpoints, data types and parameters. You will benefit from this approach to create an API inventory to serve IT needs throughout your organization.
Ensure you use automation to detect and track APIs across all environments, not limiting the focus to production. Be sure to include third-party APIs and dependencies. Tag and label your microservices and APIs—this is a DevOps best practice.
Security Testing
Traditional security testing tools will help verify elements of your APIs, including vulnerabilities and misconfigurations. Bear in mind that while helpful, these tools do have their limitations. They cannot fully parse business logic, leaving organizations vulnerable to API abuse. Use tools to supplement your security strategy, and do not rely on them as a be-all-end-all view of the state of your APIs.
Security at the Front-End
For a multi-layered approach, ensure you implement a front-end security strategy for your API clients that depend on back-end APIs. Client-side behavior analytics can embellish privacy concerns while protecting the front end. It is recommended to draft security requirements for your front-end code and to store minimal data client-side to reduce the risk of reverse engineering attacks. Ensure you have secured your back-end APIs as well, as this is not an either/or approach.
Network and Data Security
In a zero-trust architecture framework, network access is dynamically restricted. It is still possible for API attacks to occur due to the connectivity required for API functionality, meaning trusted channels can still create security threats. Ensure your data is encrypted during API transport, and use API allow and deny lists if your user list is short.
Many organizations are unclear on which APIs transmit sensitive data, exposing them to the risk of regulatory penalties and large-scale data security breaches. For data security, transport encryption is suitable in most use cases.
Authentication, Authorization, and Runtime Protection
Accounting for authentication and authorization for both users and machines is crucial to a comprehensive API security approach. Avoid using API keys as a primary means of authentication, and continuously authorize and authenticate users for a higher level of security. Modern authentication tools such as 0Auth2 will increase security fortitude.
Organizations should deploy runtime protection. Make sure your runtime protection can identify configuration issues in API infrastructure. It should also detect behavior anomalies such as credential stuffing, brute forcing, or scraping attempts. DoS and DDoS attacks are on the rise, and you should be sure that mitigation plays a role in your API security strategy.
API Security is Fundamental in Today’s World
The use of APIs is a fundamental element of life in the modern era. As such, organizations have a responsibility to ensure end users, networks and data are kept safe from intruders who may expose API vulnerabilities. By following these key aspects of API security, you will be able to successfully mitigate risk.
A web API is an efficient way to communicate with an application or service. However, this convenience opens your systems to new security risks. API Security in Action gives you the skills to build strong, safe APIs you can confidently expose to the world.
