OWASP API Security Top 10 2023
If you want to learn more, you can check the link below
Understanding API Security and Implications
InfoSec tools | InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory
Sep 04 2023
Is the new OWASP API Top 10 helpful to defenders?
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.
InfoSec tools | InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory
Mar 30 2023
API Security Checklist
Mar 06 2023
5 BEST FREE API SECURITY TESTING TOOLS. PROTECTING YOUR CLOUD CI/CD PIPELINE
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.
Previous posts on API Security
5 Books Every API Hacker Should Read
API Security: A Complete Guide
InfoSec Threats | InfoSec books | InfoSec tools | InfoSec services
Feb 09 2023
API Penetration Testing Checklist
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.
Jan 25 2023
Top FinTech API Security Challenges
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.
Checkout our previous posts on API Security
InfoSec books | InfoSec tools | InfoSec services
Jan 13 2023
Popular JWT cloud security library patches “remote” code execution hole
by Paul Ducklin
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…
<?xml version="1.0" encoding="UTF-8"?>
<data>
<name>Duck</name>
<job>
<employer>Sophos</employer>
<role>NakSec</role>
</job>
</data>
…might come out like this in JSON:
{"name":"Duck","job":{"employer":"Sophos","role":"NakSec"}}
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
jsonwebtokenfrom a group called Auth0. - The bug was patched three weeks ago. If you’ve updated your version of
jsonwebtokenfrom 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.
Breaking down JSON Web Tokens: From pros and cons to building and revoking
Contact DISC InfoSec if you need guidance on RESTful API security specs
Infosec books | InfoSec tools | InfoSec services
Dec 06 2022
Bug in Toyota, Honda, and Nissan Car App Let Hackers Unlock & Start The Car Remotely
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.
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.
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.
The Car Hacker’s Handbook: A Guide for the Penetration Tester
Nov 19 2022
7 API Security Statistics you should know
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
Attribution link: https://latesthackingnews.com/2022/11/18/7-api-security-statistics-you-should-know/
Sep 28 2022
5 Books Every API Hacker Should Read
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
Link: Hacking APIs: Breaking Web Application Programming Interfaces
Book Review
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
Link: The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws
Book Review
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
Link: Web Application Security: Exploitation and Countermeasures for Modern Web Applications 1st Edition
Book Review
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
Link: Bug Bounty Bootcamp: The Guide to Finding and Reporting Web Vulnerabilities
Book Review
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
Link: Real-World Bug Hunting: A Field Guide to Web Hacking
Book Review
“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.
InfoSec Books
Aug 16 2022
API Security: A Complete Guide
Our society has become increasingly dependent on technology in the past few decades, and the global pandemic accelerated this trend.
What is API Security?
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.
Jul 30 2022
Why And How CISOs Are Making API Security A Top Priority
A CISO’s mandate is to empower the business to move forward on key growth initiatives and simultaneously reduce risk. To this end, they must continuously evaluate and weigh the security ramifications of many strategic initiatives, ultimately weighing the potential impact on a company’s:
• Speed to market.
• Competitive advantage.
• Brand reputation.
By focusing on how their security infrastructure helps or hinders delivery on those three fronts, CISOs help drive business success. In today’s landscape, one new area has emerged that is integrally connected to all three of those company dynamics: the use of APIs to fuel innovation.
APIs are eating the world.
APIs are essential for companies to support their innovative and revenue-generating digital transformation initiatives. Open banking services, mobile and online services, digital information sharing apps, brands like DoorDash, Uber, PayPal, Spotify, Netflix, Tesla—you name it—all require APIs to function.
Companies are developing and pushing out APIs faster, and in larger quantities, than ever before. APIs allow companies to build and bring advanced services to market, opening up new avenues of business and revenue streams. Digitalization hastened this trend, and Covid accelerated its implementation. Companies had to quickly deploy remote services for workers and customers and build product integrations to support myriad devices—all of which demanded APIs. It’s no wonder that the public API hub Postman hit a record 20 million users earlier this year.
However, because APIs share highly sensitive data with customers, partners and employees, they have also become a very attractive target for attackers. CISOs have recognized the risk.
According to a new study released by AimPoint Group, W2 Communications and CISOs Connect, titled The CISOs Report, Perspectives, Challenges and Plans for 2022 and Beyond, CISOs identified the following as their top IT components needing security improvement.
• APIs: 42%
• Cloud applications (SaaS): 41%
• Cloud infrastructure (IaaS): 38%
APIs drive speed to market.
The faster a business can bring new services to market, the faster the benefits. For some companies (under Covid), speed to market meant the difference between keeping the business up and running versus shutting down operations. API usage ensured that organizations were open for business.
Businesses must always assess the value and the costs in terms of both achieving or losing the speed-to-market race. They must consider the obstacles that could prevent speed to market. In the case of APIs, security threats pose an enormous obstacle. They can slow down rollouts or, even worse, make them untenable.
By protecting APIs from exploitation, companies ensure their ability to drive speed to market, growth opportunities and competitive advantage.
APIs deliver a competitive advantage.
Speed to market is an important underlying factor that contributes to an organization’s competitive advantage. As an industry front runner, businesses have an opportunity to gain the lion’s share of a market and its profits.
In financial services, competitive advantage is a critical business objective, and technology transformation is its core strategic component. Fintech companies have fueled customer expectations, and open banking is right behind them, offering unimaginable innovation and conveniences by easily linking mobile apps to banking accounts.
Banking and financial institutions must stay on the cutting edge of these services to compete and stay relevant. APIs power these capabilities and allow institutions to leapfrog ahead of the competition.
However, security threats and lack of regulatory adherence can compromise successful API implementation and result in costly fines. Businesses must ensure safe passage between the emerging applications and customers’ valuable financial data. APIs represent the access point to PII and other important data assets that attackers target for their own gain and to the detriment of the business.
Dedicated API security is the cost of doing business.
The monetary growth opportunities promised by APIs are immense, but to harness them, CISOs must ensure the protection of their APIs. APIs support the interconnectivity of a company’s crown jewels—the essential and sensitive data that businesses require to deliver their digital goods and services.
Every company that is developing software has become an API-driven company. For API-driven companies, protecting those APIs is no longer a question—it’s simply the cost of doing business in a digitally transformed landscape. Without dedicated API security to protect these crucial connectivity tools, companies put everything at risk—speed to market, competitive advantage and the brand itself.
Last but not least, CISOs must build a collaborative approach to API security. APIs touch all areas of the business. CISOs need to take an active role in educating teams about their API security initiatives and their importance in reducing the company’s risks. CISOs must provide the answers and insights that empower others to help meet security goals.
CISO after CISO will tell you that creating a strong, cross-functional “security-aware” culture continues to be their number one priority. To generate this security mindset, leaders must prioritize relationships, acknowledge everyone’s contribution to security and continuously communicate the vital importance of security to achieve overall business objectives.
https://www.forbes.com/sites/forbestechcouncil/2022/07/29/why-and-how-cisos-are-making-api-security-a-top-priority/
Jun 13 2022
API security warrants its own specific solution
The OWASP Foundation recognizes this fact via the API Security Top 10 list of vulnerabilities and security risks. When we look at the list, there are six common methods of execution. Three of the issues occur due to weak access control and three to business logic abuse, with the remainder existing due to insufficient traffic management, application vulnerabilities, lack of visibility and lack of operational security readiness.
These issues are unique to APIs and make them particularly challenging to secure, so let’s look at each in detail.
1. Broken object level authorisation (BOLA)
Formerly known as Insecure Direct Object References (IDOR), BOLA allows the attacker to perform an unauthorized action by reusing an access token. This method has been widely used to attack IoT devices, for instance, as it can be used to allow the attacker to access other user accounts, change settings and generally wreak havoc much to the embarrassment of the IoT vendor.
The attack relies on the API’s resource IDs or objects not having sufficient validation measures in place. In some cases, the data used by the API has no user validation and is accessible to the public, while in other cases error messages return too much information, providing the attacker with more information on how to abuse the API.
Defending against BOLA attacks requires the validation of all user privileges for all functions across the API. API authorization should be well defined in the API specification and random/unpredictable IDs. It’s also important to test these validation methods on a routine basis.
2. Broken user authentication
An attacker can impersonate a genuine user if there are flaws with user authentication. Mechanisms such as log-in, registration, and password reset can be bombarded with automated attacks and, if poorly secured, will allow weak passwords, return error messages to the user with too much information, lack token validation or have weak or non-existent encryption.
Preventing these abuses requires security to be prioritized during development. All the authentication mechanisms mentioned above need to be identified and multi-factor authentication (MFA) needs to be applied. The development team should also look to implement volumetric and account lockout protection mechanisms to prevent brute force attacks.
3. Excessive data exposure
Some published APIs expose more data than is necessary as they rely on the client app rather than back-end systems to filter. Attackers can use this information to carry out enumeration attacks and build up an understanding of what works and what doesn’t, allowing them to create a “cookbook” for stealing data or for orchestrating a large attack at a later stage.
Limiting data exposure requires the business to understand and tailor the API to user needs. The aim is to provide the minimum amount of data needed, so the API needs to be highly selective in the properties it chooses to return. Sensitive or personally identifiable information (PII) should be classified on backend systems and the API should never rely on client-side filtering.
4. Lack of resources and rate limiting
If the API doesn’t apply sufficient internal rate limiting on parameters such as response timeouts, memory, payload size, number of processes, records and requests, attackers can send multiple API requests creating a denial of service (DoS) attack. This then overwhelms back-end systems, crashing the application or driving resource costs up.
Prevention requires API resource consumption limits to be set. This means setting thresholds for the number of API calls and client notifications such as resets and lockouts. Server-side, validate the size of the response in terms of the number of records and resource consumption tolerances. Finally, define and enforce the maximum size of data the API will support on all incoming parameters and payloads using metrics such as the length of strings and number of array elements.
5. Broken function level authorization
Effectively a different spin on BOLA, this sees the attacker able to send requests to functions that they are not permitted to access. It’s effectively an escalation of privilege because access permissions are not enforced or segregated, enabling the attacker to impersonate admin, helpdesk, or a superuser and to carry out commands or access sensitive functions, paving the way for data exfiltration.
Stopping this level-hopping activity requires authentication workflow to be documented and role-based access to be enforced. This requires a strong access control mechanism that flows from “parent to child” and doesn’t permit the reverse.
6. Mass assignment
The attacker discovers modifiable parameters and server-side variables that they then exploit by creating new users with elevated privileges or by modifying existing user profiles. This can be prevented by limiting or avoiding the use of functions that bind inputs to objects or code variables. The API schema should include input data payloads and enforce segregation by whitelisting client-updatable properties and blacklisting those that should be restricted.
7. Misconfiguration
Incomplete, ad-hoc or insecure default configurations, misconfigured HTTP headers, unnecessary HTTP methods, permissive cross-origin resource sharing (CORS), and verbose error messages containing sensitive information are, unfortunately, all too common in APIs. They’re usually the result of human error, due to a lack of application hardening, poor patching practices or improper encryption and, when discovered by an attacker, can be exploited, leading to fraud and data loss.
Configuration is all about putting in place the right steps during the API lifecycle, so it is advised to implement a repeatable hardening process, a configuration review and update process, and regular assessments of the effectiveness of the settings. Defining and enforcing responses (including those for errors) can also stop information getting back to the attacker. CORS policies should also be put in place to protect browser-based deployments.
8. Injection
A staple of the OWASP Web Application top 10 list, injection attacks see the untrusted injection of code into API requests to execute commands or to gain unauthorized access to data. These attacks can happen when the database or application lacks filtering or validation of client or machine data, allowing the attacker to steal data or inject malware by sending queries and commands direct to the database or application.
The mitigation of injection attacks requires separation between data/commands and queries. Data types and parameter patterns should be identified, and the number of records returned should be limited. All the data from clients and external integrated systems should be validated, tested, and filtered.
9. Improper asset management
Poorly secured APIs such as shadow, deprecated, or end-of-life APIs are highly susceptible to attack. Other threat vectors include pre-production APIs that may have been inadvertently exposed to the public, or a lack of API documentation that has led to an exposed flaw, such as authentication, errors, redirects, rate limiting, etc.
Here it’s critical to look at the API publication process by replacing or updating risk analyses as new APIs are released. Continuous monitoring of the entire API environment, from dev to test, stage and production, including services and data flow is also advised. Adopting an OpenAPI specification can help simplify the process.
10. Insufficient logging and monitoring
Attackers can evade detection entirely if API activity isn’t logged and monitored. Examples of insufficient logging and monitoring include misconfigured API logging levels, messages lacking detail, log integrity not being guaranteed, and APIs being published outside of existing logging and monitoring infrastructure.
Logging and monitoring need to capture enough detail to uncover malicious activity, so it should report on failed authentication attempts, denied access, and input validation errors. A log format should be used that is compatible with standard security tools and API log data should be treated as sensitive whether in transit or at rest.
Unique challenges
All ten attack methods reveal how difficult it can be to secure APIs, which are continuously being spun-up, updated or replaced, sometimes daily. In fact, they’re so numerous that their security can only be enforced using automation. Consequently, many organizations have tried to use rules-based security solutions and code-scanning tools, although these are not equipped to spot the types of abuses identified in the OWASP list. Web application firewalls (WAFs), for instance, offer limited protection because they look for known threats, while an API gateway can create more problems by acting as a single point of failure.
It’s for these reasons that Gartner recently created a distinct API security category, separate from these other tools, in acknowledgement of the fact that APIs have their own set of problems (that are also often unique to the business itself).
In the “Advance your Platform-as-a-Service Security” report, analyst Richard Bartley reveals API security tooling for API discovery and protection should be regarded as having equal importance to and sit between internet edge security (i.e., WAF) and the data plane security layers (i.e., the Cloud Workload Protection Platform or CWPP). This new breed of API security is therefore cloud-native and behavior-based, allowing it to spot and respond to API-specific anomalous activity.
These new tools specifically focus on the prevention of automated attacks against public-facing applications and the persistence of API coding errors. They use machine learning to analyze APIs and web applications coupled with behavioral analysis to determine whether the intent behind API interaction is malicious or benign. They can also act by blocking, rate limiting, geo-fencing and even deceiving attackers, thereby buying time to respond. Such capabilities mean that API-specific security solutions can be applied to aid the developer and to monitor the security of the API throughout its entire lifecycle, thereby preventing the automated attacks and vulnerability exploits identified in the OWASP API Security Top 10.
With APIs continuing to outstrip web apps in the rollout of new services, we must attend to how these are secured or risk building these services on shaky foundations. The hope is that with the OWASP Project highlighting how APIs can be exploited and Gartner creating a distinct new category, the tech sector will finally realize that API security is an anomaly that merits its own solution.
