Bright Security’s Enterprise Grade Dev-Centric DAST Integrates with

Microsoft Defender for Cloud →
Product
Product overview

See how dev-centric DAST for the enterprise secures your business.

Web attacks

Continuous security testing for web applications at high-scale.

API attacks

Safeguard your APIs no matter how often you deploy.

Business logic attacks

Future-proof your security testing with green-flow exploitation testing.

LLM attacks

Next-gen security testing for LLM & Gen AI powered applications and add-ons.

Interfaces & extensions

Security testing throughout the SDLC - in your team’s native stack.

Integrations

Connecting your security stack & resolution processes seamlessly.

Docs

Getting started with Bright and implementing it in your enterprise stack.

Book a demo

We’ll show you how Bright’s DAST can secure your security posture.

Resources
Blog

Check out or insights & deep dives into the world of security testing.

Webinars & events

Upcoming & on-demand events and webinars from security experts.

Docs

Getting started with Bright and implementing it in your enterprise stack.

Case studies

Dive into DAST success stories from Bright customers.

Research

Download whitepapers & research on hot topics in the security field.

Company
About us

Who we are, where we came from, and our Bright vision for the future.

News

Bright news hot off the press.

Webinars & events

Upcoming & on-demand events and webinars from security experts.

We're hiring

Want to join the Bright team? See our open possitions.

Bug bounty

Found a security issue or vulnerability we should hear about? Let us know!

Contact us

Need some help getting started? Looking to collaborate? Talk to us.

Resources > Blog >
JWT, or How I Left my Front Door Open

JWT, or How I Left my Front Door Open

Imagine for a moment, the most exciting day for a product launch, main features developed, hearts palpitating, shoulders have been cried upon, many nights have been rushed working, product managers are exhausted, everybody is heavy, tears of joy rushing from their eyes…three, two, one and….Launch! 

The product is live as a SaaS service… A sigh has been communally shared, everything works, the customers can login, they see the shiny menu that your new UX designer has worked so hard to create.  A day passes, two, a week…and then something weird happens: Some customers complain that the data displayed on their dashboard is incorrect, some users have been added to their organization or some data is missing, but what could be the culprit?


In the case that the product uses JWT (JSON Web Tokens) for authentication, there could potentially be multiple issues if not implemented correctly. In this article we will try to address JWT and its implementation in the following sections.

JWT Basics

JSON Web Tokens (Shortened JWT) are a method of transferring small structured parts of information between parties in a trusted or secured manner. Trusted meaning signed by a verified public key versus Secured meaning encrypted by a known secret key.

These JWT tokens are most commonly used as either authorization mechanisms or encryption methods, we will focus on the authorization part in this document as this is the scenario that is most interesting to us (and is actually the most prevalent).

Let’s assume for the sake of our discussion that we have Jimmy, he is a user of our SaaS application; Jimmy starts his day by logging in to the application, his credentials are being verified by either a local users repository or a third party provider, the authentication succeeded and now Jimmy receives a JWT Token which looks like this:

Looks fun doesn’t it? Oh, wait, it’s encoded, let’s break it down for a second, in decoded form it looks like this:

The token is split into three parts: 

  • The header: defines what type of token it is and what algorithm is used to sign the validity of the token
  • The payload: which will contain information about who the token was signed for, the role or the authorization of the user, the identity of the user, the timestamp of the token, etc.
  • The verify signature part: this will include the signature of the token, and the secret if needed.

This token is passed from the application to the user and is usually submitted back in the Authorization header, this way the application verifies the authenticity of the token and checks the user role / identity that will have access to the application.

The server signs the token with its own key, that way it can verify that the contents are not modified and that the token was indeed issued by the server.

The application flow will look something like this:

Token Manipulation

Now that we know what the regular mechanism of JWT looks like, let’s try to see what can (and a lot of times can) go wrong, there are multiple ways to attack the application that uses JWT tokens, let’s assume that our token looks like this (after the decoding that is):


The attacker will want to access the application, maybe change the permissions or impersonate a different user, our only method of checking the validity of the token is the strength and the security of the signing key. For example if the attacker will modify the Role field to Admin in the application and the application doesn’t re-check the role, the user can access Administrative functions, as long as the signature is valid, at least we can be sure that the token is valid and was not manipulated before sending back to the application.

Some attack vectors in this scenario will try to address the header first:

  • Modifying or downgrading the Algorithm of the token: setting the Alg field to none, if the application allows it, will mean that there is no signature, thus allowing the attacker to change every field of the token and impersonate anyone, attacker can also try to downgrade the algorithm to a weak algorithm will allow the attacker to Brute force the key to the token and sign his own tokens instead.

Modifying header parameters: changing fields like JWK, JKU or KID, allow the attacker to either refer to a different signing key that will be used for token verification or to a blank key, for example can use his own key to sign the token and embed it into the JWK header or refer the server to the URL of the key used to sign using the JKU and submit self signed tokens to the application.

Everything but the kitchen sink

If an attacker can create or sign false tokens to the application, this effectively means that the authorization mechanism is basically broken, he can impersonate any user or role within the application thus gaining access and performing any damage that he wants with the impersonated user’s identity.

So, what can be done about it? Let’s put it into the Do’s and Don’ts of using JWT tokens:

Do:

  • Rotate signing keys periodically, so that if the key is exposed the tokens that are signed will be exposed for a short time, minimizing the threat.
  • Secure your keys, don’t store them in the application, better to store them in a cloud KeyVault / KMS.
  • Verify the role signed in the token vs the user repo.
  • Verify the Signing key and URL, don’t allow URLs from locations that you don’t control in the JKU
  • Set the token expiration to the shortest time required, don’t issue tokens that have long expiration times

Don’t:

  • Trust external JKU locations
  • Allow KID (Key Identifiers) to be set for inexistent keys
  • Try to write your own frameworks to decrypt keys
  • Try to use homegrown Encryption algorithms
  • Use weak keys or allow to downgrade the Hashing algorithms

Resources

Domain Hijacking: How It Works and 6 Ways to Prevent It

What Is Domain Hijacking?  Domain hijacking refers to the unauthorized acquisition of a domain name by a third party, effectively taking control away from the rightful owner. This form of cyber attack can lead to significant disruptions, including loss of website functionality, email services, and potentially damaging the brand’s reputation.  Domain hijackers often exploit security

Mastering Vulnerability Management: A Comprehensive Guide

Modern day organizations face a constant barrage of cyber threats, making it imperative to implement robust vulnerability management processes. Vulnerability management is a systematic approach to identifying, evaluating, treating, and reporting on security vulnerabilities in systems and their associated software. In this blog post, we’ll delve into the four crucial steps of vulnerability management process

Vulnerability Scanners: 4 Key Features, Types, and How to Choose

A vulnerability scanner is a specialized software tool designed to assess the security of computers, networks, or applications by automatically detecting and analyzing weaknesses. These scanners proactively search for security vulnerabilities, such as unpatched software, misconfigurations, and other security gaps that could be exploited by attackers. Some scanners can simulate the actions of an attacker to help identify exploitable vulnerabilities.

Get our newsletter