c{api}tal (Checkmarx API Training and Learning) is a purpose-built vulnerable API application based on the OWASP API Top 10 risks. It is built with Python (FastAPI – a quick and easy to use web framework for developing RESTful APIs in Python) and JS (React), and it includes 10 API security challenges.

c{api}tal was created by the Checkmarx Research team to provide users with a “playground” so they could learn and develop their API Security skills. It can be used to learn and exploit API Security vulnerabilities and for conducting your own API Security Capture The Flag (CTF) event.

In computer security, Capture the Flag (CTF) is an exercise in which “flags” are secretly hidden in purposefully vulnerable programs or websites. The goal is to complete challenges as fast as possible, get the highest score, and win the competition. Visit capital-ctf.com to learn about the vulnerabilities and the challenges.

We first introduced C{api}tal to the application security (AppSec) community at 2022 AppSec Village at DefCon30. It was an amazing experience! Dozens of users participated in the event, while only 6 of them were able to complete the 10 API challenges.

We think of all participants as winners for being able to up-level their security skills (why we were all at DefCon), but we obviously must pick 3 for the contest. Full credit goes to the winners:

Once the event ended, many awesome write-ups were done by security analysts and researchers who took part in the CTF event. One great example is this medium write-up by Maor Tal.

Digging into API risks

c{api}tal is a vulnerable, blogging application that allows users to register, create and delete posts, create and delete comments, follow other users, and more. The application can be built and deployed by running a simple docker-compose command:

docker-compose up –d 

Some of the API endpoints in c{api}tal can be seen here:

The application contains 10 risks that align to the OWASP API Top 10 Risks:

• Broken Function Level Authorization
• Broken Object Level Authorization
• Broken User Authentication
• Improper API Management
• Excessive Data Exposure
• Improper Assets Management
• Lack of Resources and Rate Limiting
• Security Misconfigurations
• Injection
• Mass Assignment
• Security Misconfiguration
• Insufficient Logging

In this blog, we will cover Broken Object Level Authorization (AKA BOLA) and Mass Assignment challenge.

Broken Object Level Authorization

Object level authorization is an access control mechanism that is usually implemented at the code level to validate that only one user can access objects that they should have access to.

Every API endpoint that receives an ID of an object, and performs any type of action on the object, should implement object-level authorization checks. The checks should validate that the logged-in user does have access to perform the requested action on the requested object. Failures in this mechanism typically lead to unauthorized information disclosure, modification, or destruction of all data. In simple words, BOLA allows a user to have access to fetch/update/delete any resource that they should not have access to.

How to exploit BOLA in a vulnerable application? Let’s look at this example.

This application contains an article written by “Blastoise”, which announces that “Whoever comments first will get 1,000,000$ from Pikachu”. Going into the article, we can see it received two comments as shown below:

As you can see, “Bob_the_dev” was second to comment in this article, and he wished he was the first to comment. Let’s demonstrate how we can take advantage of a BOLA vulnerability to make Bob_the_dev number 1.

We would like to try to delete the first comment of “Blastoise”, an action which we should not be able to perform if BOLA mitigation is in place.

PoC demonstrating a BOLA exploit:

We successfully deleted “Blastoise’s” comment while being authenticated to another user, which means the application is vulnerable to BOLA and we got the flag!

How is Bola allowed in the application?

delete comment route

and

delete_comment_from_article 

function is defined.

We can see the code does not contain a check for the user who requests to delete the comment, and therefore, any (authenticated) user is able to delete any comment, even if it is not their own.

Mitigation

The way to mitigate this type of risk is to have a proper check of the user who tries to access/update/delete any resource in the application. In case they are not the user who should have access to this resource, the application should block the request.

if comment.author != current_user:
 raise HTTPException(
 status_code = status.HTTP_403_FORBIDDEN,
 details = “Forbidden”
)

Mass Assignment

An API endpoint is vulnerable if it automatically converts client parameters into internal object properties, without considering the sensitivity and the exposure level of these properties. This could allow an attacker to update object properties that they should not have access to.

How to exploit Mass Assignment in a vulnerable application?

When a user tries to register/login to the application, the response the application returns with contains one interesting field that should not be there—“admin” parameter.

A default user in the application is not an admin, so why don’t we try to change that?

PoC demonstrating Mass Assignment exploit:

How is Mass Assignment allowed in the application?

Here is a snippet of the application code where the user profile returns the “status” of the user in terms of admin permissions as a new parameter in the response – “admin”. We can see the code does not restrict users from modifying such parameters, so any user could update his profile and modify his admin permissions:

We were able to modify the user’s permissions and now the user is an admin! And in the context of the CTF event, of course, we got the flag as well.

Mitigation

The way to mitigate such risk is not to expose sensitive properties and not allow users to update object properties that they should not have access to.

Final Thoughts

APIs are a critical part of modern mobile, SaaS (Software as a Service), and web applications and can be found in customer-facing, partner-facing, and internal applications. By nature, APIs expose application logic and sensitive data, potentially leading to data breaches, account takeovers, and much more. Because of this, APIs have increasingly become a target for attackers.

Without secure APIs, organizations would face many security risks and rapid innovation would be impossible. Therefore, it is extremely important to be aware of the OWASP API Top 10 risks and enforce proper API security mitigations for your APIs.

To help developers and AppSec teams improve their API security skills, Checkmarx researchers developed c{api}tal, which again, is a built-to-be-vulnerable API application based on the OWASP top 10 API risks.

Feel free to use c{api}tal to learn, train and exploit API Security vulnerabilities within your own API Security CTF event. c{api}tal will soon be available as an open-source project on GitHub! We encourage you all to be proactive and sharpen your API security and overall code security skills!

To learn more about Checkmarx approach to API security, and overall application security testing, request a demo of our Checkmarx One Application Security Platform today. Or sign up for a 14-day free trial here.

In this blog post, we’ll dive into some of the most interesting trends and statistics of open source licenses. In order to get such statistics, we scanned over 1,000,000 open source packages, in the ratio of 50:50 for poorly-maintained packages and well-maintained packages, to test the average maintained packages. These packages were filtered by using the open source tool scorecard project (by OSSF). The results were the following:

What is the most popular and used open source license these days?

MIT, big time. This license is a very permissive one, as GitHub defined it “A short and simple permissive license with conditions only requiring preservation of copyright and license notices. Licensed works, modifications and larger works may be distributed under different terms and without source code”, according to choosealicense.com.
The top 4 most popular open source license found were:

• MIT – 66%
• Apache2 – 13%
• GPL 3.0 – 5%
• GPL 2.0 – 4%

The rest of the popularity results can be seen in this chart:

Diving deeper into the statistics and usage of the MIT license, we can see that this license is being used in over 6M repositories, 31M code instances, and 191,000 packages, according to GitHub.

In addition, we checked the distribution of the languages of MIT and found that the most popular language that uses MIT license was JavaScript. Python, HTML, and Ruby were next in line, accordingly:

How many open source packages contained a legal risk?

According to Checkmarx, a package considered a high/medium risk package is defined as a package with legal risk. Checkmarx SCA gives every open source package it scans a few risk scores (copyright risk score, patent risk score, and so on) which calculate the level of risk of every package being scanned.
Out of all the scanned packages, 23,622 packages contained a legal risk. That means that ~2.5% of all open source packages contain a legal risk that needs to be addressed.

According to GitHub’s State of the Octoverse survey, the average project now has 203 OS dependencies, which means that in each open source project you import, you will use an average of 5 OS packages with legal risk attached to them.

We wanted to check the distribution of languages with the most legal high-risk packages. The results were outstanding. 94% of the results pointed to Maven (Java), while 0-1% pointed to Pip (Python):

Moreover, if we compare the number of risky Maven dependencies to the total Maven dependencies fetched in this research, we can learn that 19% of the Maven dependencies are considered high risk. That means that 1 out of 5 Maven OS dependencies you use might be legally risky.

So, Maven open source dependencies might contain high legal risk, how do you know?

We wanted to dive a little bit into Maven’s results and check which was the most popular source from which we took the decision for the license type. Basically, eliminating popular sources like GitHub and Mvnrepository that can be scrapped in order to get the license of each OS package (with a certain level of trust, of course), we used the pom.xml and the jar file of each Maven package. These files contain interesting data about the package, as well as the license it is using.

The results were the following:

We can see that in 62% of the Maven instances, the license was derived from the pom.xml file while only 38% arrived from the jar file.

Comparing risks of license that are part of the copyleft family

In the previous blog post, we discussed copyleft vs. permissive licenses, and why copyleft ones are considered riskier to use.

In short, copyleft is a property of the license that means that the package is free to use, but it is forbidden to make it proprietary. A copyleft license is also viral since any work containing a package that is copyleft-license must also retain this property. We use 3 different options to mark the copyleft value of each license:

• Full – Full copyleft license
• Partial – Copyleft applies on modifications only
• No – Not a copyleft license

The results were the following:

We can see that 95% of packages do not contain a copyleft type of license, 4% contains partial copyleft licenses and only 1% are full copyleft licenses. These results make sense, as we noticed the two most popular licenses in use were MIT and Apache2, which are permissive licenses.

Copyright risk score distribution:

One of the components that are scored and calculated in order to decide the level of legal risk that an open source package contains is the copyright risk score. A copyright risk score is a number between 1 and 7, in which 1 is considered the most permissive score, while 7 is the most restrictive score:

1 – Licensee may use code without restriction.

2 – Anyone who distributes the code must retain any attributions included in the original distribution.

3 – Anyone who distributes the code must provide certain notices, attributions, and/or licensing terms in documentation with the software.

4 – Anyone who distributes a modification of the code may be required to make the source code for the modification publicly available at no charge.

5 – Anyone who distributes a modification of the code or a product that is based on or contains part of the code may be required to make publicly available the source code for the product or modification, subject to an exception for software that dynamically links to the original code.

6 – Anyone who distributes a modification of the code or a product that is based on or contains part of the code may be required to make publicly available the source code for the product or modification.

7 – Anyone who develops a product that is based on or contains part of the code, or who modifies the code, may be required to make publicly available the source code for that product or modification if s/he (a) distributes the software or (b) enables others to use the software via hosted or web services.

License risk is derived from the copyright risk score of the license. Levels 1-3 are considered low risk, levels 4-5 are medium, 6 and up are high. The result was the following:

As we can see, 93% of the packages contained low risk, while 4% of the packages contained medium risk and 3% of the packages contained high risk.

Final thoughts:

As MIT & Apache2 share together almost 80% of license types found among 1,000,000 open source packages, we can learn that these two permissive licenses are here to stay, and they might symbolize a pattern in which both organization and developer prefer to use open source packages that contain a more permissive type of license.

From the fetched statistics we learned that Maven packages can be very risky to use, and tend to contain the riskiest licenses in their dependencies, be extra careful when using them.

One thing is sure, the open source community is trying to make open source components easy to adopt and comply with, while organizations and developers using such components have to make sure they are aware of every component they use, verifying that they meet its requirements and creating a compliant environment for their software.

The problem

Many developers falsely believe that OSS (open source software) is freely available without any restrictions attached to it when using it in their development process. That is completely wrong. Each OSS’s license states the terms & conditions that have to be filled in order to use it for commercial uses. Not following and applying these conditions may introduce a certain risk to the organization which can lead to unwelcomed, critical consequences.

The risks

#1 Being forced to share modifications to the public:

In case you are using an OSS that uses a “copyleft” type of license, such as GPL, LGPL, AGPL, EPL, or MPL in your code, your software development might be governed by the respective OSS license and therefore, the ownership of your software will not be exclusive.

Your software must comply with the same requirements that are applicable to the OSS you used, for example, a GPL license. In the case of you releasing a modified version to the public in some way, this requires you to make the modified source code publicly available for anyone, since part of its conditions are to disclose the source code and make sure modifications are released under the same license. Not doing so means you have violated the GPL license conditions.

#2 Being exposed for a lawsuit:

Legally, companies using OSS in their applications must comply with licenses for each component to maintain the rights to modify and distribute their technology. Any violation attached to the license may lead to a potential lawsuit against the company and/or the client using the uncompiled software.

One of few examples is the ongoing lawsuit that Elastic has filed against Amazon, in order to prevent Amazon from using its service to distribute Elastic-built software from Amazon Web Services. In the case of a non-compliance company, you might also face penalties and restrictions on selling your company’s software product until compliance is met. In most cases, responding to a claim ends up costing more than if your company complied in the first place.

#3 Businesses risks:

In case there is a failure to comply with licenses, a company may be exposed to business disruption, due to the fact that some licenses may automatically terminate because of the company non-compliance status. An injunction may prevent distributing a product until the source code is released. The later a problematic dependency is discovered the more costly it will be to resolve in the software development process.

#4 IPO killer:

Lack of audit and plan to address open source license issues will not only slow down a potential IPO preparation process, but also may depress an IPO value, both in the short term and at any point of a public company life cycle.

#5 Prohibition of commercial distributing:

Some OSS licenses have policies that do not permit any commercial distribution of software that uses their licenses. Therefore, in the case when you are using OSS containing these licenses, you will not be able to sell or rent any deliverables that fall under these licenses. For example, Jason Hunter, Java Enterprise Edition, and Oracle licenses are part of these restrictive licenses.

But there is more, a non-compliance transitive consequence might be:

• Negative effect: Non-compliance companies may suffer from negative coverage & press
• Reputation: Damage or complete loss of reputation with customers and clients
• Credibility: Damage or complete loss of credibility with the open source community
• Resources: Consuming more resources (time + money) to remove a component/detect & fix the issue.

Research

Checkmarx has conducted research on the legal risk factors in open source packages. The goal was to scan a high number of open source dependencies, determine how many of them contain a legal risk, and what is the severity of such risk in order to prioritize these risks and their fixes.

To make this research authentic, we used well-maintained packages as well as poorly maintained packages (50:50) that were part of GitHub OS projects that were filtered by using the open-source tool scorecard project (by OSSF). We fetched interesting metrics using an automated SCA tool, and the results were the followings:

• ~5.3% of the open-source packages have a license that contains “legal risk”. According to GitHub State of the Octoverse Report, “Open-source projects have an average of 203 package dependencies” – which means that on average, each project a developer uses contains 10 packages that use licenses with legal risk.
• The vast majority of these legal risks are considered high risk/medium risks, which means they have to be addressed in order to make your product safe and compliant.

So, what should you do?

Every organization has to make sure they are properly managing their open source licenses risks. Managing your open source dependencies (and their transitive dependencies) and their risk can be a very tedious, overwhelming challenge due to:

• The high amount of open source dependencies (and their transitive dependencies) your organization use on the code
• Challenge of collecting each license you are using
• Categorizing these licenses into risks
• Prioritizes these license’s risks
• Fixing the compliance issues

To help manage open source license risk, Checkmarx SCA enables your organization to address license issues earlier in the SDLC, and cuts down on manual processes by scanning your code, identifying the license type, and the risks it contains, so you can deliver secure and compliant software faster and at scale. Below is an example of the information Checkmarx SCA provides.

For a free demonstration of Checkmarx SCA, please contact us here.

OS dependencies are being used very broadly among developers due to their amazing benefits.
Studies show that ~85–97% of the software applications rely on OS components, and the average project now has 203 dependences, according to GitHub’s State of the Octoverse survey.

Simply put, the license is what turns a code (project) into open source software.
An open source license is basically a legal and binding contract between the author of the OS dependency and the client who consumes the service, in this case, the open source code.
The license states that the software can be used in commercial applications only under specified terms.

As a developer, you can’t just use, copy, modify or distribute open source dependencies. In order to properly (and legally) use an OS dependency in your software, it is mandatory to be aware of the permissions, limitations, and conditions of each license of each open source dependency you use in your code.

What are the different types of OS licenses?

Every open source package uses one (or more) license and there are more than 100 different OSI licenses Approved.

These licenses can be divided into 2 main groups:

• Permissive
• Copyleft

Permissive – as the name suggests, the licenses that fall under this group provide more freedom to use, copy, modify, and distribute the OS dependency code.
These have very minimal restrictions on the way you can use them in your software, allowing its use in proprietary derivate projects.

Copyleft – These types of licenses are less permissive, and they typically contain a restriction to use, modify, and distribute the content of the OS dependency.
We can think about the code as intellectual property of the author of the OS dependency, which needs to “approve” you to use its content.

Thus, one of the most noticeable limitations of using such dependencies is the obligation to make their code open for anyone.

These are a few of the most popular licenses and their type:

Table 1

Comparison:

The GNU’s General Public License, or GPL, was created by Richard Stallman in order to protect the GNU software from becoming proprietary. This license falls under the copyleft type, which requires anyone using an open-source dependency with a GPL license to release their code as open source.

The Apache license was created by Apache Software Foundation (the ASF) in order to allow free usage, modifications, and distribution of Apache-licensed products. Apache 2.0 falls under the permissive type of licenses, but nevertheless, there are a few limitations and conditions that must be fulfilled, in order to properly use its products.

In Table 2, we can see a comparison between these two licenses:

Table 2

*In GPL 3.0, the GNU organization added the patent use aspect to the permissions list, allowed developers to add local disclaimers, and expanded the development options. All of these are in order to expand the usage of GPL worldwide.

Why you should be concerned

Without any doubt, writing and distributing an uncompliant software may put your business at risk. The risks to a non-compliant business are not limited just to just lawsuits, but may also force you to share your code with the world, damage your business reputation among the OS community and your clients, hurt your chance to make a successful IPO, prohibit you from commercially distribution your product, and much more.

Law suite examples:

In an ongoing scenario, Elastic Vs Amazon, Elastic had to change its license to a different, restrictive license in order to prevent Amazon from using its service to distribute an Elastic-built software from Amazon Web Services.

“The move to block users from buying Elastic-built software from Amazon Web Services — by switching to a restrictive software license — capped a years-long dispute between the two companies that started in 2015, when Amazon’s cloud unit launched its own competing product based on Elasticsearch’s code, and named it Amazon Elasticsearch Services — causing confusion about who created the software, and diverting customers from Elastic”.

Elastic changed their license from Apache 2.0-license to the Server Side Public License (SSPL) which was explained in:
“Our license change is aimed at preventing companies from taking our Elasticsearch and Kibana products and providing them directly as a service without collaborating with us.”

This battle is yet to be decided in court, but in case Elastic will prove right, Amazon might have to pay a big chunk of money due to using Elastic licenses’ in a non-compliant way and not following the conditions and limitations it requires.

So, what should you do?

Every organization has to make sure they are properly managing their open-source licenses risks.
Managing your open-source dependencies and their risk can be a very tedious, overwhelming challenge due to:

• The high number of open-source dependencies your organization use on the code
• Challenge of collecting each license they are using
• Categorizing these licenses into risks
• Prioritizes these license’s risks
• Fixing the compliance issues

For that, Checkmarx Software Composition Analysis (SCA) solution enables your organization to address open source license issues earlier in the SDLC, and cut down on manual processes by scanning your code, identifying the license type and the risks it contains, so you can deliver secure & compliant software faster and at scale.

For a free demonstration of Checkmarx SCA, please contact us here