Skip to main content

Golang security: access restriction bypass vulnerability in JWT

Written by:
Daniel Berman

Daniel Berman

Leeya Shaltiel

wordpress-sync/snykgo_header_image

December 22, 2020

0 mins read

Back in July, the Snyk security team was alerted about a potential security issue in the JWT package. This package provides a Go implementation of JSON web tokens and the issue that was discovered related to a function called VerifyAudience that was not working as expected. The function allowed passing a double quotes (“”) value which could cause the audience verification to succeed where it should not.

Interestingly, the vulnerability was actually fixed six months before the issue itself was opened (the fix included additional validation for the aud value using the ValidateAudienceAgainst function). However, the fix was pushed into a specific version (v4.0.0-preview1) available in pkg.go.dev but not pushed into the master branch of the repository.

Similar to other ecosystems, many Go developers prefer to simply clone the master branch of a GitHub repository, which in this case meant two things:

  1. The issue was opened after a fixed version was made available!

  2. The amount of projects affected by this vulnerability remained high, mainly because most of them are using the master branch and not the specific tag with the available fix.

Once qualified and verified as a vulnerability, the maintainer of the package was notified. Since we did not receive a reply, and because the security research team concluded that the issue was too risky, Snyk assigned a CVE and published it in the beginning of September.

This vulnerability is just one example out of hundreds of proprietary Golang security vulnerabilities uncovered this year by Snyk’s security research team. This article sheds some light on the processes used and the trends Snyk is seeing in this quickly growing popular ecosystem.

Golang’s popularity and growing security risk

It’s hard not to be impressed by the growth metrics that Golang has been showing over the past few years. Year after year, Golang—or Go as it’s more commonly referred to—is listed as one of the top five most loved and most wanted languages in StackOverFlow’s annual developer surveys. Activity in GitHub is also high with Go ranking #4 in pull requests and issues, #3 in stars, and #7 in pushes.

Practicality, ease-of-use, performance—all these factors are often cited as the key reasons developers enjoy building with Go. But what about security? Well, according to the 2019 Go community survey, 75% of Go developers claim that security is important to them and the Go team recently announced plans to develop a database of known vulnerabilities together with Golang security scanners. The security risk in Golang is as real as it gets and these are important steps that will help make developing in this language safer and more secure.

At Snyk, we’ve also invested heavily to achieve this same goal. As a result of the work done by Snyk’s security research team, hundreds of new Golang security vulnerabilities have been added into the Snyk Intel Vulnerability Database since 2019. This intelligence is used by an increasing number of Snyk users to test and monitor their Golang projects for security vulnerabilities but was also not easy to come by - this is a relatively new ecosystem and the unearthing process differs considerably compared to more established programming languages.

What makes Golang security research so unique

As it relates to uncovering new vulnerabilities and security research as a whole, Go’s uniqueness stands out for a number of reasons.

First, the number of overall security vulnerabilities themselves. Over a relatively short period of time, we have witnessed a significant growth in the number of vulnerabilities. In comparison to more established programming languages such as Java and JavaScript, The Go ecosystem does not have a particularly long history of vulnerabilities. However, the data we have gathered shows increases in both the number of packages and modules as well as overall growing awareness within the Go community to security issues. The number of Golang security vulnerabilities added into the Snyk Intel Vulnerability Database in 2020 is almost double the amount of all vulnerabilities added between 2015 and 2019!

wordpress-sync/blog-snyk-vulnerability-db-page-example

Another noteworthy fact to mention is that the variety of vulnerability types is also considerably wider in comparison to other languages. For the vulnerabilities added in 2020 alone, there are 44 different CWEs! This wide distribution, together with the large number of vulnerabilities, makes the security research super interesting.

Beyond CVEs—Snyk’s research into Golang security vulnerabilities

Not every vulnerability is disclosed and has a CVE assigned to it. Other than tracking new CVEs, Snyk’s security team is able to identify vulnerabilities that have still yet to be officially disclosed but that might, for example, be discussed in public forums. This research is one of the pillars that makes the Snyk Intel Vulnerability Database so unique in terms of completeness—providing comprehensive security coverage beyond what is publicly available and official CVE reports.

These vulnerabilities are often the most dangerous ones. Malicious actors will use early knowledge of the vulnerability and take advantage of the window in time between when a vulnerability is being discussed and when it is publicly acknowledged as they know that once disclosed, it is only a matter of time until a fix is made available.

To minimize this window, Snyk sources various online resources such as technical forums, GitHub issues and pull requests, and even social media feeds, to identify new vulnerabilities as soon as possible and extremely early in the vulnerability’s lifecycle. We triage the vulnerabilities, their severity and whether a fix is available via an upgrade. Once confirmed, they are added to our database and users are notified.

For Go, Snyk receives tens of alerts per day of potential newly identified  security vulnerabilities. The alert is just the initial indication—we then dive deeper into the issue to qualify it as a vulnerability. When triaging the security report, we will engage in a proof-of-concept (POC) activity of the security issue and if qualified, the vulnerability will be assigned a CVE. The maintainer of the relevant open source package is also contacted so the appropriate measures to mitigate the security concern can be taken as soon as possible.

The research resulting in the unearthing of these proprietary vulnerabilities plays a key role in protecting applications. Indeed, out of the 10 most common Go security vulnerabilities found among Snyk customers, 7 are proprietary vulnerabilities that Snyk unearthed and that did not exist in any CVE database.

Snyk for Golang

Snyk provides development and security teams trying to stay secure when building their Golang applications with a solution that is easy to implement, facilitates quick fixes, and is powered by accurate security intelligence:

  • Developer-friendliness - Snyk seamlessly integrates with existing development workflows, scans projects in a matter of seconds (even projects the size of Kubernetes!), and is extremely easy to use, ensuring high adoption and maximized productivity.

  • Comprehensive coverage - Snyk will identify both security vulnerabilities AND license issues across the different stages of the SDLC, supporting Go Modules applications, including those running inside containers.

  • Security depth - Since 2019, Snyk has added hundreds of proprietary Go security vulnerabilities to the Snyk Intel vulnerability database. Most of these vulnerabilities are proprietary, are not found in NVD, and are a result of the uncovering work done by Snyk’s security research team.

Using Go and want to get started? Try Snyk for Free!

wordpress-sync/snykgo_header_image

How CISOs are Transforming their DevSecOps Strategies

500 devs to 1 security professional is the reality of today. The security pro’s role must transform into an aware, knowledgeable, supportive partner capable of empowering developers to make security decisions.