andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Principal Developer Advocate

Andrea Chiarelli

Broken Object Level Authorization is the most critical API security vulnerability. Learn how Fine Grained Authorization (FGA) can help fix it.

According to [OWASP](https://owasp.org/), the worldwide web security community, Broken Object Level Authorization (BOLA) is the most critical vulnerability affecting APIs. What is this vulnerability? How can it be exploited? How can you prevent it in your API? Keep reading to find the answers to these questions.

## What Is OWASP API Security Top Ten?

One of the main goals of the OWASP community is to make developers and technologists aware of the risks their applications and systems are exposed to. With this in mind, the community publishes some documents that highlight what are the most common security risks.

The [OWASP Top Ten](https://owasp.org/www-project-top-ten/) document is the most popular one. It focuses on web development in general. But there is also a more specific document for APIs: the [API Security Top Ten](https://owasp.org/www-project-api-security/).

Both the 2019 and the [2023](https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc.html) versions of the document report that [Broken Object Level Authorization](https://github.com/OWASP/API-Security/blob/master/2023/en/src/0xa1-broken-object-level-authorization.md) is the most critical security risk. It's incredible that after four years this security risk is still affecting APIs around the world! Is there a way to mitigate if not eliminate this vulnerability?

The answer to this question is positive: you can prevent  this vulnerability from affecting your API by designing a proper authorization system. But before you get to the solution, let's learn what Broken Object Level Authorization is.

## What Is Broken Object Level Authorization?

Authorization is the process of determining what a user has access to. This access control can be done in many different ways based on the business rules of the specific application.

In the API context, each request to a protected endpoint should be analyzed to determine if the client is authorized to access and perform the requested action. Typically, this check is done at the code level and is based on verifying that the client has the right permissions to access the resource (the object) exposed by the API endpoint.

The main problem in this case is to define what is the actual resource to protect.

In some scenarios, it's the API endpoint itself. Consider the `/profile` endpoint: it implicitly returns the profile data of the current user. The API may know who the current user is from the session storage or from the access token sent along with the request.

In other scenarios, the object to protect is the requested resource. Consider the endpoint `profile/42`, which returns the profile data of the user with ID 42. In this case, comparing the current user ID to the requested user ID may not be correct. Think of an administrator who should have access to the profile data of all the users. The authorization check should verify that the current user has permission to access the requested object.

Inaccurate permission checking in endpoints that use object IDs exposes the API to BOLA attacks. In fact, an attacker could manipulate the object ID to gain access to an object for which they have no permissions.

> In the past, the Broken Object Level Authorization (BOLA) vulnerability was called Insecure Direct Object Reference (IDOR). The name was changed because it suggested that the problem was with the ID, while in fact it's with the authorization check.

## An Example of BOLA Vulnerability

To understand how a Broken Object Level Authorization vulnerability can be exploited by an attacker, let's use a practical example.

Suppose your bank provides you with an app to manage your account. Being a curious developer, you take a look at how your app interacts with the server. You notice that it calls the endpoint `https://thebankwebsite.com/accounts/9876543` to get data about your own account whose number is 9876543.

You remember that one of your friends has the same bank as you. You also remember that you made a money transfer to him in the past, so you look for his account number in the messages he has sent you. You find out that his account number is 1029387. So, you take curl or another HTTP client and replay your HTTP request to the bank's server by changing the endpoint's URL: `https://thebankwebsite.com/accounts/1029387`.

Surprisingly, you get the data about your friend's account from the server! This means that the bank's API has a BOLA vulnerability. Their authorization check fails at the object access level.

You can imagine, for example, that the API implementation for that particular endpoint is as follows:

```javascript
const express = require('express');
const app = express();
const { auth, requiredScopes } = require('express-oauth2-jwt-bearer');

//This checks that the provided access token is valid
const validateAccessToken = auth({
  audience: '...yourApiIdentifier...',
  issuerBaseURL: `https://...yourDomain.../`,
});

//This checks that the provided access token grants reading permissions
const checkReadPermissions = requiredScopes('read:account');

app.get('/accounts/:accountNumber', 
        validateAccessToken, 
        checkReadPermissions,
        function(req, res) {
          res.json(getAccountData(req.params.accountNumber));
        }
);
```

This Node.js Express code snippet shows how a GET request on the `/accounts/:accountNumber` endpoint is handled. Note that the endpoint is protected by two middleware:

- `validateAccessToken`, which ensures that the client provides a valid access token.
- `checkReadPermissions`, which ensures that the access token contains the required `read:account` scope in order to allow the client to access the requested account.

Unfortunately, these checks are not sufficient to implement an accurate access to the account object. In fact, they will not prevent you from accessing your friend's account.

<include src="ebook-ads/WebSecurity" />

## How to Prevent BOLA Vulnerabilities

What measures can you take to prevent BOLA vulnerabilities?

A common suggestion is to avoid using easily recognizable object identifiers in your endpoint URL, such as the bank account number in the example above. This measure prevents the knowledge of the object ID from allowing an attacker to compose a specific HTTP request. For example, you could use a GUID in the URL to identify the bank account instead of the bank account number itself. GUIDs are randomly generated values and make them very difficult to guess.

This approach can mitigate the risk of BOLA attacks, but it doesn't solve the problem. If the attacker finds a way to determine the GUID associated with a bank account, this protection will be bypassed.

The real problem is not in the object ID but in the authorization mechanism. The access control of your API should not be limited to controlling access to the endpoint. It should verify that only authorized users can access **the object exposed by the endpoint**.

In the bank account example, this means that additional checks should be performed. For example, you can check that the current user is the owner of the account, as outlined below:

```javascript
// ...existing code...

app.get('/accounts/:accountNumber', 
        validateAccessToken, 
        checkReadPermissions,
        function(req, res) {
          const userId = req.auth.payload.sub;
          const account = getAccountData(req.params.accountNumber);
  
          if (account.userId == userId) {
            res.json(account);  
          } else {
            res.status(403).json("Permission denied."); 
          }
        }
);
```

This would solve the unauthorized access to the bank account described earlier. However, it might not cover other scenarios. For example, consider a bank account with multiple owners. Each owner could have different permissions on the account. Also consider a bank employee: they should be able to access the accounts of their branch customers. And perhaps a regional manager should be able to access the accounts of multiple branches.

As you can see, the authorization policy that your API should implement strictly depends on the specific business logic. This logic is mainly determined by the relationship between users and resources. When this relationship becomes complex, your API code run the risk of getting messed up.

## What Is Fine-Grained Authorization?

To handle complex authorization policies, you should use Fine Grained Authorization (FGA). FGA allows you to control access to resources by analyzing a context described by various attributes and relationships. By having access to a detailed context, you can more effectively control who can access what in your system.

You can design and implement FGA in a variety of ways, but the most common models are as follows:

- **Attribute-Based Access Control (ABAC)**. This authorization model allows you to make authorization decisions by evaluating attributes such as the user's role or age, the resource type or size or status, the action requested, the current date and time, and so on.
- **Policy-Based Access Control (PBAC)**. This authorization model allows you to make authorization decisions based on policies. It is very similar to ABAC. The main difference is that PBAC focuses more on logic while ABAC relies more on data.
- **Relationship-Based Access Control (ReBAC)**. This authorization model focuses on the relationship between users and resources. This also includes relationships between resources. ReBAC provides a more expressive and powerful authorization model that can describe very complex contexts.

Okta offers [Fine Grained Authorization](https://fga.dev) through two solutions based on the ReBAC model:

- [Auth0 FGA](https://dashboard.fga.dev/). This is an *authorization service* that centralizes your authorization logic and data. It allows you to define your authorization model, store your authorization data, and make your authorization decisions across all your applications. Read the [Auth0 FGA documentation](https://docs.fga.dev/intro/authorization-and-auth0-fga) to learn more.
- [OpenFGA](https://github.com/openfga). This is the Open Source project powering the Auth0 FGA service. You can install the [OpenFGA Server](https://github.com/openfga/openfga) and use its SDKs to integrate authorization into your applications.

## How FGA Solves BOLA Vulnerabilities

Auth0 FGA and OpenFGA allow you to fix Broken Object Level Authorization vulnerabilities in your APIs without messing up your code. Whether you use the hosted product or install the Open Source engine on your servers, FGA allows you to centralize the access control to the resources protected by your API.

You can do this in three steps:

1. **Define your authorization model**. In this step, you define the types of objects in your system and their possible relationships with each other. The authorization model is usually fairly static once written. Check out [this document to learn more about defining your authorization model](https://docs.fga.dev/modeling).
2. **Store your authorization data**. This step allows you to define the actual data and its relationships according to the authorization model you defined in the previous step. This represents the state of the system and will be changing as users interact with your application.
3. **Add authorization check to your API**. In the third step, you integrate authorization checks into your API and start leveraging the power of FGA.

### Define your authorization model

Going back to the bank account example, you can define your authorization model in Auth0 FGA by using its [configuration language](https://docs.fga.dev/modeling/configuration-language). The following code shows a minimal example of how your model could be written:

```yaml
model
  schema 1.1
type user
type branch
  relations
    define employee: [user]
type account
  relations
    define branch: [branch]
    define owner: [user]
    define can_create: employee from branch
    define can_view: owner or employee from branch
```

Notice that the last line in the model above defines the account owner and the employees of the branch where the account was opened as the legitimate viewers. This is the basis for avoiding the Broken Object Level Authorization problem.

Using the [Auth0 FGA Playground](https://play.fga.dev/), you can also get a visual representation of this model:

![The bank authorization model in the Auth0 FGA Playground](https://images.ctfassets.net/23aumh6u8s0i/3cklRF8G4IPBGWb07P4JsI/a75e9daf57459430a9c40f620aad7792/auth0-fga-bank-authorization-model.png)

> You can play with the model used in this article by [making your own copy](https://play.fga.dev/stores/create/?id=01GVMW810J23DEBPGT22MFE4M7).

### Store your authorization data

As the next step, you fill this model with actual data. You define your users and add a direct relationship to the objects in your model. You also define relationships between objects and other aspects that depend on your specific model. You provide data to the system using tuples. For example, the following tuples define some relationships related to the bank model presented earlier:

```json
[
  // User Mary is the owner of the account 12345
  {
    "user": "user:mary",
    "relation": "owner",
    "object": "account:12345"
  },
  // User John is an employee of the branch b1
  {
    "user": "user:john",
    "relation": "employee",
    "object": "branch:b1"
  },
  // Account 12345 was created in the branch b1
  {
    "user": "branch:b1",
    "relation": "branch",
    "object": "account:12345"
  }
]
```

To learn how [to populate your authorization model with data, read this document](https://docs.fga.dev/writing-data).

### Add authorization check to your API

Finally, you can add the authorization checks to your API using one of the [available SDKs](https://docs.fga.dev/integration/install-sdk). Referring back to the bank example, the Node.js Express code will perform its authorization checks as follows:

```javascript
const { OpenFgaApi } = require('@openfga/sdk');
const fgaClient = new OpenFgaApi({
  //...configuration...
});

// ...existing code...

app.get('/accounts/:accountNumber', 
        validateAccessToken, 
        checkReadPermissions,
        function(req, res) {
          const userId = req.auth.payload.sub;
          const account = getAccountData(req.params.accountNumber);
  
          const { allowed } = await fgaClient.check({
            tuple_key: {
              user: `user:${userId}`,
              relation: 'can_view',
              object: `account:${req.params.accountNumber}`,
            },
          });
  
          if (allowed) {
            res.json(account);  
          } else {
            res.status(403).json("Permission denied."); 
          }
        }
);
```

The authorization check is performed by `fgaClient.check()`, which passes the tuple to be verified to the FGA engine. The FGA engine uses the authorization model and the data you provided to determine if the current user is authorized to view the requested account. Since you have defined there who the legitimate viewers of this account are, your API is not BOLA vulnerable. In addition, your code is kept clean.

Read more about [integrating FGA into your API](https://docs.fga.dev/integration).

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

## Summary

By the end of this article, you should have a clearer idea of what Broken Access Level Authorization is and how Fine Grained Authorization can help prevent it.

You have begun to explore what BOLA is and how it can be exploited with a practical example. You have seen that the root cause of this vulnerability is an inadequate authorization system. You learned about FGA and saw what Auth0 offers in this area.

Using the API example analyzed earlier, you learned how to integrate it with Auth0 FGA to overcome the BOLA vulnerability in three steps: define an authorization model, populate the model with data, and invoke the authorization check from the API.

In addition to avoiding BOLA vulnerabilities, Auth0 FGA provides a powerful authorization system to solve very complex scenarios effectively and efficiently. [Give it a try](https://fga.dev/).


How Fine Grained Authorization Solves the Most Critical API Security Risk

jameeka_aron

Jameeka has over 20 years of Information Technology and Cyber Security experience. She is a versatile leader, successfully leading teams as both a CISO and CIO across various industries including; Aerospace & Defense, Apparel, Retail, and Manufacturing at both Fortune 100 and privately held companies and many spaces in between. <br>
She is highly skilled in Business Engagement (International and U.S. based) Audit, Compliance, Vulnerability, Risk and Identity Management, Digital Transformation, Mergers, Acquisitions, Divestitures, and leading Cross-Functional and Matrixed teams.

CISO

Jameeka Aaron

CISO Jameeka Green Aaron on Auth0’s actions around this insidious vulnerability

On Thursday, December 9, 2021, a vulnerability in the Java logging library Log4j was disclosed and assigned the CVE ID [CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228), also nicknamed Log4Shell. The Cybersecurity and Infrastructure Agency (CISA) also released an [alert](https://www.cisa.gov/uscert/ncas/current-activity/2021/12/10/apache-releases-log4j-version-2150-address-critical-rce) on the 10th of December.

This is an incredibly serious vulnerability that has had security teams in every industry on high alert, working around-the-clock to ensure that their systems are secure. At a high level, Log4J allows Remote Code Execution (RCE) on an affected server, granting an attacker full control. A detailed explanation was published by [LunaSec](https://www.lunasec.io/docs/blog/log4j-zero-day/).

Security is our top priority at Auth0 and we recognize the critical role our platform plays for our customers. Since the vulnerability came to light, Auth0 teams across Engineering, Product, Customer Success, and Security, led by our Detection and Response team have been all hands on deck to evaluate any potential impact on our platform. This is one of the most dangerous vulnerabilities that our industry has seen and we have treated it with that level of seriousness. It also has the potential to be very widespread and takes time to methodically review code and systems. We started with our most critical assets and worked outwards, gaining more assurance as we progressed.

As we stated in our tweet last [weekend](https://twitter.com/auth0/status/1470086301902721024), we did not see direct impact then, nor do we now, after continuous assessment and monitoring. We can confirm that there were no signs of exploitation, and the Log4j library is not used in our core service code base. 

Auth0 does use a very small number of third-party components that were vulnerable to Log4Shell. We have been working closely with our partners throughout the incident response process, firstly to apply patches as soon as they are released, and secondly to identify if they could have been used as a potential path to compromise our service. Again, our review has not shown any signs of abuse from the vulnerability.

The speed of response from our teams and our existing security architecture was essential here. Using our existing security tooling, we were able to scan our entire code base and containers for the affected library and quickly get assurance that we were not affected. We also deployed WAF rules on our edge for an extra layer of protection and then focused our efforts on assuring our supply chain. Finally our Red Team has been trying to actively use the vulnerability against the Auth0 platform, further increasing our levels of assurance through offensive testing.

This vulnerability is very serious. We recommend that all of our customers continue to closely review and monitor their own systems and third-party components for the vulnerability and any signs of compromise. And critically make sure you are running the latest versions of any impacted software (please see [Okta’s blog](https://sec.okta.com/articles/2021/12/log4shell) for details of the impact to the Okta products).

Subsequently other vulnerabilities have been reported in Log4j ([CVE-2021-45046](https://nvd.nist.gov/vuln/detail/CVE-2021-45046) and [CVE-2021-45105](https://nvd.nist.gov/vuln/detail/CVE-2021-45105)) and we expect there to be more as the library gets further attention from security researchers. We will continue to closely monitor and investigate the situation, and provide prompt notification if the situation changes.

Auth0’s Response to Log4J

HTTPS downgrade attacks compromise your web application security by switching to HTTP. Learn how to prevent them.



Using HTTPS in your web application is mandatory to guarantee trust and security. However, an attacker may try to downgrade that secure protocol into simple HTTP and grab or tamper with the exchanged data. Learn how this type of attack works and how you can prevent it.

## What is an HTTPS Downgrade Attack

Nowadays, most websites and web applications use HTTPS as their default protocol. This happened [thanks to the effort of browser providers and other supporters](https://www.eff.org/encrypt-the-web). Using a secure protocol like [HTTP over TLS](https://en.wikipedia.org/wiki/HTTPS) is a best practice for a few reasons:

- It guarantees **confidentiality** since data exchanged between the client and the server are encrypted.
- It ensures **authenticity** since the domain identity is verified by a trusted third-party ([Certificate authorities](https://en.wikipedia.org/wiki/Certificate_authority)).
- It offers data **integrity** since any tampering attempt is detected.

In other words, by using HTTPS, you avoid typical *person-in-the-middle* ([man-in-the-middle](https://en.wikipedia.org/wiki/Man-in-the-middle_attack)) attacks, where an attacker intercepts and possibly alters messages exchanged between the client and the server.

However, even if you enabled your website to use HTTPS, there are situations that an attacker can exploit to downgrade the secure protocol to the unprotected HTTP. How can this happen?

Suppose your website is using HTTPS, but you missed updating a link in one of your pages, say the following one:

``` html  
<a href="http://mywebsite.com/awesomepage">Awesome page</a>
```

This link uses plain HTTP. What happens if the user clicks that link and the HTTPS-enabled server receives a plain HTTP request? The typical approach is to redirect the client to use HTTPS, as shown by the following diagram:

![HTTP to HTTPS redirect](https://images.ctfassets.net/23aumh6u8s0i/2j1wM2BuZFlC4Sv8mttvmd/9623624757c57d369a593248d7a19b00/http-to-https-redirect)

However, an attacker may intercept that apparently harmless HTTP request and trigger the person-in-the-middle attack you are attempting to avoid with HTTPS. The following diagram shows how interception may occur:

![HTTPS downgrade attack](https://images.ctfassets.net/23aumh6u8s0i/1aPLFQvJvCirLdlhZPqc57/9e89921d3ec5899a640b62b91518c9b7/https-downgrade-attack)

From that request on, all messages sent by the client are transmitted via HTTP and manipulated by the attacker. One single HTTP request may compromise the whole communication security between the client and the server. For this reason, you should never mix HTTP and HTTPS protocol on a website.

To avoid this type of protocol downgrade, you should make sure that all the internal links in your website are relative or use HTTPS. This may be an affordable solution for small websites, but it is not feasible for a large website, especially if its content results from many people's contributions.

<include src="TweetQuote" quoteText="Ensuring security by simply forcing HTTPS as the default protocol is not so trivial."/>

## Using Content Security Policy

The HTTP [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) (CSP) header can help you force browsers to use HTTPS throughout your website. The `upgrade-insecure-requests` directive is designed for this purpose. By adding the following meta tag in the head section of all the pages of your website, any link using HTTP will be interpreted as if it uses HTTPS:

``` html  
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
```
Consider that the directive also applies to non-navigational links, such as scripts, stylesheets, images, and other media.

> **Note:** While major browsers support the `upgrade-insecure-requests` directive, it has never been implemented in IE11. Even if Microsoft's browser is now deprecated, it is still being used.

Alternatively, your server application can send the HTTP header to the browser. For example, in an [Express](https://expressjs.com/) application, you can send it through a middleware, as shown in the following code snippet:

``` javascript  
const express = require("express");
// ...other require...

const app = express();

app.use(function(req, res, next) {
  res.setHeader("Content-Security-Policy", "upgrade-insecure-requests");
  next();
});
// ...other code...
```

An alternative to manually setting HTTP security headers in your server application is to use a specific package. For example, in an Express application, you can use [helmet](https://helmetjs.github.io/).

> **Note**: By using the `upgrade-insecure-requests`, the HTTP fallback is automatically disabled. This means that if the requested resource is not actually available via HTTPS, the request will fail.

## Using HSTS

There are situations where the CSP `upgrade-insecure-requests` directive may not be enough. For example, this happens when a third-party website has a link to your website with the `http` scheme. Actually, the `upgrade-insecure-requests` directive tells the browser to use HTTPS for any further request originated by that page. However, the page itself is supposed to be requested through HTTPS. If it is requested via HTTP, the person-in-the-middle attack may still happen, and the attackers can manipulate the HTTP headers before they reach the browser. In other words, the CSP `upgrade-insecure-requests` directive doesn't eliminate the risk of having HTTPS downgraded to HTTP.

You need a way to tell the browser to use HTTPS to request **any** resource of your website, not just the resources linked to the current page. This is the purpose of another HTTP header: the HTTP `Strict-Transport-Security` header (HSTS). The following is an example of HSTS header received by a browser:

```
Strict-Transport-Security: max-age=31536000; includeSubDomains
```

When the browser receives such a header, it records the page's domain and the expiration time expressed in seconds through the `max-age` directive. From now on, the browser will use HTTPS for any request sent to that domain, regardless of the specified protocol. This will happen until the expiration time elapses unless a new HSTS header is received. In fact, each time the browser gets a new HSTS header, the expiration time is updated.

In the example, besides the `max-age` directive, you notice the `includeSubDomains` directive. This directive tells the browser to apply the HTTPS request policy to any subdomain of the current page's domain. This increases the security of the whole domain hosting your website or application.

## Preloading Strict Transport Security

So, by using the HSTS header, you ask the browser to use HTTPS for any request to your website for a given time. With this instruction, the browser will ignore any attempt to make requests via HTTP, wherever they come from. However, there is still one possibility that could cause HTTPS downgrade: the very first access to your website.

Suppose a user has never visited your website. Now, suppose they manually insert your website URL in their browser's address bar by explicitly using the `http` scheme. Since this is the very first time the user makes a request to your website and their browser knows nothing about it, that request is vulnerable. Only after the first request with an HSTS header the browser knows that it always has to use HTTPS. An attacker may intercept the first request, and your website is compromised.

How can you instruct a browser to reach your website by always using HTTPS, including the very first time?

Well, you can request to add your domain to the [HSTS Preload List](https://hstspreload.org/). This domain list is maintained by Google and is hardcoded into Chrome as the list of sites that should be requested exclusively via HTTPS. Most major browsers also have their HSTS preload list based on the Chrome list.

You need [to meet a few requirements](https://hstspreload.org/#submission-requirements) to be included in the list. Among others, you have to add the `preload` directive to the HSTS header as in the following example:

```
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
```

Once your domain is included in the hardcoded HSTS list of a browser, the browser will no longer make any requests to your website via HTTP.

## Web APIs and HTTPS Downgrade Attacks

So far, the discussion about HTTPS downgrade concerns browsers. What about Web APIs?

You may apply HTTP-to-HTTPS redirection and HSTS headers, but API clients usually don't follow the redirect, unlike browsers. So, the only practical approach is to deprecate the HTTP protocol and use only HTTPS, as recommended by [CIO.gov](https://https.cio.gov/apis/).

The main problem here is how to deal with possible HTTP requests. In case of migration from an HTTP-based API to HTTPS, you should apply a progressive transition involving the partners that have built clients for your API. Also, be explicit in the API documentation about using HTTPS. From a technical point of view, your API should return the 403 Forbidden HTTP status code to an HTTP request.

The following is a simple example of Express middleware that refuses HTTP requests:

``` javascript  
const express = require("express");
// ...other require...

const app = express();

app.use(function(req, res, next) {
  if (!req.secure && req.get('x-forwarded-proto') !== 'https') {
    return res.status(403).send('Please, use HTTPS');
  }
  next();
});
// ...other code...
```

In the code above, you check if the current request is using HTTPS (`req.secure`) or the original request used that protocol (`req.get('x-forwarded-proto') !== 'https`). The latter check makes sense if your API is behind a reverse proxy. If the request is not using HTTPS, the server sends a 403 HTTP status code as a response.

<include src="asides/AboutAuth0" />

## Conclusion

In this article, you learned how ensuring security by simply forcing HTTPS as the default protocol in your website or application is not so trivial. The person-in-the-middle attack may still happen in particular situations. However, you can leverage a few standard HTTP headers to mitigate this risk: the CSP `upgrade-insecure-requests` directive and the HSTS header with preloading. You also learned that a slightly more crude approach should be used for Web APIs due to the lack of standard clients that can apply security policies similar to browsers'.

To learn more, visits the [OWASP HSTS Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) and the [CIO.gov HTTPS adoption guidelines](https://https.cio.gov/).




Preventing HTTPS Downgrade Attacks

How to manage third-party assets in order to mitigate security risks while developing and maintaining your web application.

Security risks may arise in your applications not just from your own code but also from third-party dependencies. Learn how you can protect your web applications from vulnerabilities that come from third-party assets.

## Third-Party Assets Risks

Building web applications requires special attention to security issues since they are publicly accessible. As a developer, you should make sure that your applications are reasonably protected from [the most common security concerns](https://auth0.com/blog/developers-guide-to-common-vulnerabilities-and-how-to-prevent-them).

However, your effort to build secure web applications may be nullified by vulnerabilities that may exist in third-party assets such as library packages, JavaScript scripts, or CSS files. Those external resources may contain vulnerabilities that affect your application. In other words, a vulnerability in a third-party asset becomes a vulnerability in your application.

What are the risks you may face with third-party vulnerabilities? They are basically the same risks you can have with vulnerabilities in your own code:

- exposure to [Cross-Site Scripting (XSS)](https://auth0.com/blog/cross-site-scripting-xss/)
- being subject to [Cross-Site Request Forgery (CSRF) attacks](https://auth0.com/blog/cross-site-request-forgery-csrf/)
- predisposition to [clickjacking tricks](https://auth0.com/blog/preventing-clickjacking-attacks/)
- injection flaws and other common attacks

However, you may have additional risks due to potential deliberate malicious code in any of your project's dependencies. For example, this malicious code may expose you to:

- loss of confidential and personal data
- unauthorized access to systems and other applications
- downtime of system infrastructure

A few notorious cases, like [the `event-stream` package threat](https://medium.com/intrinsic/compromised-npm-package-event-stream-d47d08605502) or [the Equifax incident](https://www.cnet.com/news/equifax-ceo-data-breach-heres-what-went-wrong/), are emblematic examples of what can happen if you neglect third-party packages security.

Let's discover what you can do to mitigate such risks.

<include src="TweetQuote" quoteText="A vulnerability in a third-party asset becomes a vulnerability in your application."/>

## Best Practices to Mitigate Risks

To mitigate the risk of introducing vulnerabilities in your web application due to third-party assets, you should set up a structured process in your development flow. This process is basically composed by four steps:

- Assets inventory
- Dependencies analysis
- Risk assessment
- Risk mitigation

Let's take a look at each of these steps.

### Assets inventory

The first step in this process is to know what dependencies your web application is using. This may seem a naive assertion, but, honestly, do you actually know how many dependencies your application uses?

Think of the `node_modules` folder of your Node.js project or the [global packages folder](https://docs.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders) for .NET Core solutions or the equivalent for other programming languages and development environments. They usually contain a lot of packages. Maybe you installed a few of them, but most likely, they depend on other packages. So, you end up having a significant amount of code you have not written in your project. And the more uncontrolled code you have in your codebase, the more likely you introduce vulnerabilities into your application.

Also, don't forget to consider even scripts or stylesheets you include in your client applications, regardless of whether you include a bundled copy of them or link to a *Content Delivery Network* (CDN). Think of [jQuery](https://jquery.com/download/) and [Bootstrap](https://getbootstrap.com/docs/4.5/getting-started/download/) assets or the [Google Analytics tag](https://developers.google.com/analytics/devguides/collection/analyticsjs), for example.

Knowing exactly which dependencies your project uses is fundamental to know the associated risks and to mitigate them. This step may also give you the opportunity to think about the real need for each third-party dependency.

### Dependencies analysis

Once you list the dependencies used in your project, you should inspect them to search for vulnerabilities.

If the dependency comes from an open-source project, you can check its code. Otherwise, you can consult the vendor's security bulletins or check out specialized databases such as the [National Vulnerability Database](https://nvd.nist.gov/).

Of course, manually checking all your dependencies is not feasible. You should use tools that automate this task for you. For example, if you use GitHub as your code repository service provider, you should regularly receive [security vulnerabilities alerts](https://docs.github.com/en/free-pro-team@latest/github/managing-security-vulnerabilities/managing-vulnerabilities-in-your-projects-dependencies) that may affect your projects' dependencies. They also provide automated pull requests via [Dependabot](https://github.com/dependabot).

Even *npm* provides you with the ability [to check for security vulnerabilities in your Node.js projects](https://docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities). You can launch this inspection by typing `npm audit` in a terminal window. You can also automatically update your npm dependency by running `npm audit fix`.

Alternatively, you can use [OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/), a tool from OWASP that integrates with other code management systems such as Maven, Gradle, Jenkins, and others. Or you can use the [OWASP Dependency-Track](https://owasp.org/www-project-dependency-track/) platform to identify security risks with a structured and advanced approach.

Whatever tool you use, the result of this analysis step is a list of the vulnerabilities that affect your dependencies and their severity.

### Risk assessment

Of course, your hope is to get an empty vulnerability list for your dependencies. However, the chances are that you detect a few security risks affecting your application. In this case, you have to make some decisions.

Usually, your decisions depend on your answers to the following questions:

- How severe is that vulnerability?
- Is there any available fix?
- What is the effort to fix the vulnerability?
- Is this vulnerability relevant to your application?

You may think that if a new version of your dependency fixes that vulnerability, you have to install that update. However, updating a dependency is not always a smooth task. You need to be sure that that new version doesn't break your application or other dependencies. Also, you need to make sure that the new version is not introducing new security issues. You need to balance the effort of upgrading and the benefits it brings.

Maybe you can find vulnerabilities that actually don't affect your application, so you can postpone the dependency upgrade to a later time. In other words, in some circumstances, you can decide to accept the risk represented by the security issue you discovered in a dependency.

So, this step of the mitigation process is basically a thoughtful reasoning about the risks and benefits of taking an action over the issues. To learn more about this decisional process, take a look at [the OWASP Vulnerable Dependency Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html).

### Risk mitigation

Now you have a clear picture of the situation. You may have vulnerabilities that can be temporarily ignored, but you may have issues that need to be fixed.

If a fix for a vulnerability exists and the upgrade is straightforward for your application, you should apply it. In case there's no fix for a vulnerability affecting one of your dependencies, you have two choices:

- Collaborating with the author/vendor of the dependency to solve the vulnerability.
- Find a workaround to prevent the vulnerability exploitation.

At the end of this process, you should have addressed the most dangerous vulnerabilities that could affect your application.

<include src="TweetQuote" quoteText=" By using third-party dependencies, you are taking responsibility for code you did not write."/>

## Keeping Risk Mitigation Under Control

Even if you have been able to ensure an acceptable level of risk with your dependencies, you can't relax yet. Your codebase is a live environment. Even if you don't change your code, your third-party assets may change without you realizing it. Just a simple rebuild can add uncontrolled code to your project. The same situation may happen without any build process when you use a third-party script or CDN.

You may have different scenarios depending on the type of project and its configuration. Let's see how to deal with those issues.

### Locking Server-Side Assets

Most modern development environments rely on centralized remote registries for dependency management, such as, for example, [npm](https://www.npmjs.com/), [NuGet](https://www.nuget.org/), [Maven](https://search.maven.org/), [Packagist](https://packagist.org/), and others. Even a simple rebuild of your project may trigger the download and installation of dependency updates without you realizing it.

Of course, it depends on your package manager configuration. Let's take *npm* as an example. It is the standard Node.js package manager, and it relies on the `package.json` configuration file to track a Node.js project's dependencies. This is an example of `package.json` file:

``` json  
{
  "name": "my-app",
  "version": "1.0.0",
  "description": "This is my application",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "axios": "^0.19.2",
    "express": "^4.17.1"
  }
}
```

It declares that the current project depends on [axios](https://github.com/axios/axios) version 0.19.2 and [Express](https://expressjs.com/) version 4.17.1. However, the caret (`^`) before the version number tells the package manager that any compatible version with the current one can be installed. Following the [semantic versioning convention](https://docs.npmjs.com/cli/v6/using-npm/semver), this means that the package manager is allowed to install any patch below version 0.20.0 for axios and any patch and minor fixes below version 5.0.0 for Express.

Say you found no security issues in the current versions of those packages. With this configuration, you may add an uncontrolled version of those dependencies in your project with the risk of introducing new vulnerabilities.

You have two ways to fix the dependency versions of your Node.js project:

- Specify the exact version of your dependencies in `package.json` by removing any [range indicator](https://docs.npmjs.com/cli/v6/using-npm/semver#advanced-range-syntax).
- Consider the `package-lock.json` file as an integral part of your project and commit it into your source code repository (see [the `package-lock.json` documentation for more information](https://docs.npmjs.com/cli/v6/configuring-npm/package-lock-json)).

You may have the same problem with other package managers. For example, in .NET you can specify a reference in your project as in the following example:

``` xml  
<Project Sdk="Microsoft.NET.Sdk.Web">



  <PackageReference
    Include="Microsoft.AspNetCore.Components.WebAssembly.Authentication"
    Version="3.2.*" />



</Project>
```

In this case, NuGet will install the highest stable package version starting with 3.2. Again, you are not sure of the specific version you are running in your application. So, use a specific version for your dependency to make sure you are getting the package you trust. Check out [the NuGet package versioning document to learn more](https://docs.microsoft.com/en-us/nuget/concepts/package-versioning).

### Locking Client-Side Assets with Subresource Integrity

Hosting scripts and stylesheets on a CDN is a common practice. It helps to reduce bandwidth consumption and improve performance. However, that code is out of your control. The code maintainer may apply changes to it, or an attacker can replace it with malicious code without you realizing it.

Using third-party CDNs exposes your application to a potential security risk. How can you mitigate this risk?

The typical approach to mitigate it is to apply [Subresource Integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity). This standard feature, supported by all recent browsers, allows you to block any third-party asset that changed since your latest security review. Let's take a quick look at how Subresource Integrity works.

Assume you have a reference to React in your HTML page as in the following:

``` html  
<script src="https://unpkg.com/react@17.0.1/umd/react.production.min.js">
</script>
```

This reference uses [the unpkg CDN](https://unpkg.com/) to load a specific version of React. Indicating a specific version is a good practice to make sure you have the exact version of a library you already verified. In the unpkg CDN, if you just indicate a major version of a library, for example, `react@17`, you will get the most recent update of that library. So, similarly to npm, you specify version 17 but will get version 17.0.1 and subsequent patches and minor updates.

However, even if you specify a given version of your library, you may not be sure if the code has not been tampered with, say, after an attack. You may also need to use libraries or scripts that don't provide any explicit version number.

The Subresource Integrity feature ensures that the third-party asset has not been changed since your latest security review. To enable that feature, you need to add two attributes to the script element seen above. The protected script would appear like the following:

``` html  
<script src="https://unpkg.com/react@17.0.1/umd/react.production.min.js"
  integrity="sha256-Ag0WTc8xFszCJo1qbkTKp3wBMdjpjogsZDAhnSge744="
  crossorigin>
</script>
```

You added the `integrity` and `crossorigin` attributes to the `<script>` tag.

The value of the `integrity` attribute is [the hash value](https://en.wikipedia.org/wiki/Hash_function) of the third-party asset. It is represented by a string in the form `algorithm-hash`. In the example above, the algorithm is `sha256`, and the actual hash value is `Ag0WTc8xFszCJo1qbkTKp3wBMdjpjogsZDAhnSge744=`.

The `crossorigin` attribute enables the browser to requests the asset to the server and to check its integrity. Without `crossorigin` the browser will load the asset independently on its integrity.

When the browser loads the asset from the CDN, it will compute the file's hash value. If the value is equal to the value specified in the `integrity` attribute, the asset is loaded. Otherwise, the asset will be blocked, and an error will be thrown in the browser's console, as in the following picture:

![Invalid integrity hash value in Chrome console](https://images.ctfassets.net/23aumh6u8s0i/6momWxXgjwk5VKmpXM1N0s/f87bfd27e0d5330ee52568756d524962/chrome-console-invalid-hash)

The console shown above is from Chrome. In this specific browser, the error message also provides the expected correct value for the hash. So, you can leverage the Chrome console as a manual tool to compute the value for the `integrity` attribute as a side effect of the integrity verification.

> Consider that not all browsers generate an error message with the expected hash value.

Alternatively, you can use the [SRI Hash Generator](https://www.srihash.org/), an online tool that generates the whole script tag with the computed `integrity` value.

If you prefer a command-line tool, you can use `shasum` in a Linux-based environment. In this case, you need to download the asset on your machine to calculate the hash value. Assuming you downloaded the React library file on your machine, the command you need to run looks as follows:

``` bash  
shasum -b -a 256 react.production.min.js | awk '{ print $1 }' | xxd -r -p | base64
```

This will show the computed hash value on your screen.

You can also use [openssl](https://www.openssl.org/) to generate the hash value. This is the command you have to run:

``` bash  
openssl dgst -sha256 -binary react.production.min.js | openssl base64 -A
```

> So far, you have seen an example of protecting from an external script with Subresource Integrity. Additionally, the same mechanism applies also to CSS files. To protect your application from external stylesheets, you can use the same `integrity` and `crossorigin` attributes for the `<link>` tag.

<include src="asides/AboutAuth0" />

## Conclusion

Throughout this article, you learned that writing your code with security in mind may not be enough to make your application secure. You also need to pay attention to third-party assets. Once you add them to your application, they become a part of it, with any potential vulnerability they may have.

The article suggested the best practices you should follow to keep your third-party assets under control. First, you should know what your third-party assets are, which vulnerability they may be affected by, and which level of risk they bring to your application. Then, once you reach an acceptable security risk level, you need to freeze the current situation to avoid unwanted updates or tampering. You can do it by locking package versions on the server side and using Subresource Integrity on the client side.

To learn more about managing vulnerabilities of third-party dependencies, check out the [OWASP Vulnerable Dependency Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html).

Managing Third-Party Assets Security Risks in Your Web Apps

Learn how clickjacking attacks implement visual tricks to capture users' clicks, and how you can prevent them by applying client-side and server-side solutions.

Clickjacking Attacks and How to Prevent Them

Learn how CSRF attacks work and how to prevent Cross-Site Request Forgery vulnerabilities in your Web applications by exploring a practical example.

Prevent Cross-Site Request Forgery (CSRF) Attacks

Learn how XSS works and how to prevent it in Web applications.

Defend Your Web Apps from Cross-Site Scripting (XSS)

joan-pepin

As CSO, Joan is responsible for the holistic security and compliance of Auth0's platform, products, and corporate environment. She brings 20 years of experience to the role, with a career that has spanned a wide variety of industries, including healthcare, manufacturing, defense, ISPs, and MSSPs. <br /><br />Previously, Joan served as Business Information Security Officer (BISO) at Nike, Inc, CISO, and VP of Security at Sumo Logic, and held different positions at Guardent/Verisign/Secureworks organization. Joan holds a patent for developing the methodology to assess whether a communication contains an attack. <br /><br />She is also is a well-recognized thought leader and has spoken at major events, such as RSA, WhiteHat Security Summit, and Forrester Security Summit, and is frequently called upon for her expertise and commentary in Cloud Security and Compliance in large-scale and DevOps/CI environments.

Chief Security Officer (CSO)

Joan Pepin

On July 31st 2019, at 5:11am, we received an email from Insomnia reporting a service vulnerability. By 11:00pm the same day, we had fixed the issue in production.


On July 31st, 2019 at 05:11 UTC, Insomnia Security responsibly disclosed a JWT validation bypass issue to Auth0 while performing a penetration test for one of our customers. **A lone path of one of our older, stable versions of our codebase was not using our standard baseline JWT implementation, which allowed a case-insensitive JWS algorithm to match an "unsigned" verifier. This affected a very small subset of our endpoints.**

After receiving the disclosure, we fixed the vulnerability within hours on the public cloud, and through logging, verified it was not being exploited in any way. We have seen **zero** signs that the vulnerability was discovered or exploited in the wild, and have recorded **zero** attempts to abuse the vulnerability.

We worked closely with Insomnia Security to immediately rectify the issue. As they state: 

_"Auth0's public platform was quickly patched and they rolled out patches to their private platform over time. Overall, the response from Auth0 was swift and pleasant. They quickly remediated the issue and appreciated the vulnerability report."_

We take great care in our public libraries so that a vulnerability like this isn't available in our customers' or library users' code. Unfortunately, for this specific code path, we didn't rely on our own module, be assured we do now. Since this disclosure, we have: 

-   Conducted an exhaustive exercise with Auth0 Engineering and Product Security to review our libraries.

-   Launched a Bug Bounty program to accelerate the identification and remediation of existing vulnerabilities.

Transparency is one of our core values and permeates throughout our company, including the way in which we communicate about issues. We appreciate the continued feedback from the security community-at-large to ensure we are providing the most secure platform for our global customers.

## Timeline

July 31st, 2019 at 05:11 — UTC Email sent to the security team by the Insomnia researcher

July 31st at 08:30 UTC — Security Incident Channel created by Auth0 IR Team

July 31st at 13:18 UTC — Vulnerability confirmed and fix started

July 31st at 21:34 UTC — Fix deployed to our stable environment

July 31st at 22:45 UTC — Fix verified by the Auth0 Security Team

July 31st at 23:00 UTC — Fix validated in production and by security researchers




Insomnia Security Disclosure

Learn how responsible disclosure of a cybersecurity vulnerability made the risk mitigation process safe for Auth0 customers and vendors.



On October 5, 2017, security company [Cinta Infinita](http://www.cintainfinita.com) contacted Auth0 to report a vulnerability in our Legacy Lock API ([CVE-2018-6873](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6873)). Cinta Infinita discovered the issue while conducting independent research. In specific cases, Cinta Infinita was able to bypass password authentication when logging into Auth0’s Management Dashboard by forging an authentication token. After verifying the vulnerability, we responded immediately, pushing a patch to our cloud service within four hours of initial notification. Our engineers then worked around the clock to patch our Private SaaS Appliance customers over the following two weeks.

During our investigation it became clear that the vulnerability was a special case of a deeper structural problem. The attack exploited an underlying Cross Site Request Forgery (CSRF/XSRF) vulnerability ([CVE-2018-6874](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6874)). CSRF vulnerabilities are a common structural flaw when embedding a login widget into a web application due to the nature of cross-origin authentication (one of the reasons we’ve been pushing for [Universal Login](https://auth0.com/blog/authentication-provider-best-practices-centralized-login/)).

To fully remediate this issue and protect our customers, we needed to make a significant change to our [Lock login widget](https://auth0.com/lock) and its [supporting library](https://auth0.com/docs/libraries/auth0js/). Unlike the fix for the special case discovered by Cinta Infinita, this issue could not be solved without forcing our customers to upgrade the libraries/SDKs on their end, a much more significant undertaking.

We worked with Cinta Infinita to allow us time to address the issue prior to their public release. Neither party wanted the vulnerability to be exposed for a lengthy period of time, so we agreed on an aggressive schedule that still provided ample opportunity for all of our customers to upgrade.

With Cinta Infinita’s support on the timing, we moved forward with a strategy to mitigate the vulnerabilities by rewriting the affected libraries and releasing new versions of our SDKs (auth0.js 9 and Lock 11). This was an all-hands-on deck effort that included our Engineering, Customer Success, and Security teams as well as many individuals from across Auth0. Our goal was to provide a seamless upgrade. We achieved that for customers who were on Lock 10 and auth0.js 8.

We launched a multi-touch communications plan to all customers announcing the deprecation and removal of the vulnerable endpoints, giving them notice to migrate to the new SDKs. Customers on Enterprise plans were contacted and given the opportunity to speak directly with the Security and Professional Services teams to work out individually tailored migration plans.

Understanding that the upgrade would be cumbersome for many customers, our Engineering team continued to work on the underlying issue and was able to develop a mitigation strategy that could be implemented on the server side. This strategy not only decreased the burden to our customers, it also significantly reduced the <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Verifying_Same_Origin_with_Standard_Headers">severity rating of the API vulnerability</a>. This occurred three weeks before planned public disclosure.

With server-side mitigations in place for our Cloud Customers, users are now much better protected even prior to migrating to new software versions. Due to the heavily downgraded severity, we are able to provide customers with three additional months to upgrade, with the **vulnerable endpoints removal of service now taking place on July 16, 2018 instead of April 1, 2018**.

<include src="TweetQuote" quoteText="Due to the heavily downgraded severity, vulnerable endpoints removal of service now taking place on July 16, 2018."/>

Security is a top priority at Auth0, and we’ve invested heavily in building up our program over the last year.

* We have implemented a new Secure Software Development Lifecycle process that encompasses all new development efforts.
* All of our developers take part in regular secure development training.
* We have embedded Product Security engineers into the various engineering teams to focus on the internal code and processes, while building out our Application Security team to focus on external interfaces and component security.
* We perform regular penetration tests and code reviews executed by industry-leading third parties, as well as automated vulnerability and component security scans.

With these people, processes, and tools in place, a project to review and refactor our code base is already underway. This project will make the introduction of vulnerabilities even more unlikely in the future.

<include src="TweetQuote" quoteText="Security is a top priority at Auth0, and we’ve invested heavily in building up our program over the last year."/>

Vulnerabilities are a part of life in software development. We would like to thank Cinta Infinita, an excellent partner in this process. Cinta Infinita has worked responsibly with us to protect our customers. We encourage anyone to report potential vulnerabilities to us through our [Whitehat responsible disclosure program](https://auth0.com/whitehat). We take all such reports very seriously as part of our commitment to providing the best security for our customers.

Migration guides are available to help customers upgrade to [auth0.js version 9](https://auth0.com/docs/libraries/auth0js/v9/migration-guide) and [Lock version 11](https://auth0.com/docs/libraries/lock/v11/migration-guide).

If you have any questions or feedback, please reach out to us. You can contact your CSM, open a [support ticket](https://support.auth0.com/), or chat with us in the Auth0 community forum on the [deprecations roadmap topic](https://community.auth0.com/t/upgrade-reminder-changes-to-deprecation-roadmap/9552 ) and the [migrations FAQ topic](https://community.auth0.com/t/april-1st-migrations-deprecations-faq/9723).


Managing and Mitigating Security Vulnerabilities at Auth0

sam-judson

Former Auth0 Employee

Samuel Judson

Duo Security announced the discovery of a new class of SAML response vulnerability affecting SSO. Auth0 is not vulnerable to this issue.



On February 27, 2018, [Duo Security](https://duo.com) announced the discovery of a new class of vulnerability affecting SAML-based single sign-on systems. This flaw can allow an authenticated attacker to fool SAML systems into logging in as a different user, even without knowledge of the victim’s password. Note that this type of attack can be prevented by Multi-Factor Authentication, even if software used is vulnerable.

Malicious impersonation of this type can have a broad range of risks, including (but not limited to) compromising the victim as well as the system. An attacker could potentially impersonate a user with greater permissions, as well as elevate their own privileges.

Researchers from [Duo Labs](https://duo.com/labs), Duo’s security research team, identified several vendors affected by this class of vulnerability. You can read more information on SAML, details of the exploit, and affected vendors in Duo’s announcement here: [Duo Finds SAML Vulnerabilities Affecting Multiple Implementations](https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations).

## Auth0 is Not Affected by the Vulnerability

As [cited in Duo’s disclosure](https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations), all three of the following items are needed in order to enable this vulnerability:

1. SAML Responses contain strings that identify the authenticating user.
2. XML canonicalization (in most cases) will remove comments as part of signature validation, so adding comments to a SAML Response will not invalidate the signature.
3. XML text extraction may only return a substring of the text within an XML element when comments are present.

The library that Auth0 uses internally to parse SAML responses prevents the third requirement for exploitation. This prevents the vulnerability being exploited when  Auth0 is used as a SAML Service Provider (SP).

## Am I Affected?

Auth0 is not vulnerable to this issue, therefore, Auth0 customers do not need to take any action if using Auth0 as a SAML SP. However, if you are using Auth0 as a SAML Identity Provider (IdP) and are _processing SAML responses in your own code_, you will need to verify whether the libraries you are using are vulnerable as per [the original disclosure from Duo](https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations). If you are using a vulnerable library, you must ensure that **any affected software is updated to patch the vulnerability**.

Auth0 provides the [passport-wsfed-saml2](https://github.com/auth0/passport-wsfed-saml2) Passport strategy as open-source software. This strategy is **not vulnerable** to this SAML security vulnerability reported by Duo. If you or your company are using this strategy, you do not need to take any additional action.

If you have any further questions or concerns, please [open a support ticket](https://support.auth0.com/) or [ask in our community forum](https://community.auth0.com/).


Auth0 Not Affected by SAML Vulnerabilities Identified by Duo Security

685342d5e7f42c3ab8d251d7d4a53308?s=100&d=mm&r=g avatar

685342d5e7f42c3ab8d251d7d4a53308?s=100&d=mm&r=g

Robin Percy

A new security vulnerability has been found in the WPA2 WiFi protocol.  We will look at the details of this, and how to mitigate it.



**TL;DR:**  A new security vulnerability has been found in WPA2 (the protocol that secures almost every modern WiFi connection).  The security weakness potentially allows a sinister agent, within range of the network, to hijack traffic and view any sensitive communication that is not encrypted.  In this article we'll take a look at the vulnerability, the risk it poses to you, and how to mitigate it.


## What is it?

*KRACK*.  Or *Key Reinstallation AttaCK*.  This is the name given to the latest security vulnerability found within the WPA2 protocol, which the majority of us use to secure our WiFi networks.  The weakness could potentially affect *any* device that secures WiFi with WPA2.  Once exploited, a malicious agent would be able to steal sensitive information such as bank account details, user account details and passwords, etc.  It may also be possible for the malicious agent to inject and manipulate data such as Ransomware or Malware.

Discovered by the security researcher [Mathy Vanhoef](https://twitter.com/vanhoefm), the KRACK vulnerability has cast a dark shadow over the *proven-secure* WPA2 protocol, the very protocol that hasn't been destabilised in over 14 years.  From a high level, the vulnerability allows a malicious agent to intercept a connection between a WiFi network and device.  The malicious agent can then force the reinstallation of an already in use encryption key, by manipulating and replaying the cryptographic handshake process that happens between the device and network.  Once exploited, a malicious agent can access any unencrypted information sent over that network connection.

When a user goes to join a WiFi network, be it on their laptop, tablet or phone, a 4-way-handshake (4 step process) is initiated in which a fresh session key is negotiated.

The 4 step process is reflected in the following image, with the `AP` being the *Access Point (Network)* and the `STA` representing the device:

![WiFi 4-way handshake process](https://images.ctfassets.net/23aumh6u8s0i/5WM8Se3acljfPMs0U5IYct/1b2270474e02c13e126cbdae9acd9032/wifi-4-way-handshake)

After *step 3* in this process, the session key is installed and will be used to encrypt normal data frames.  The Access Point will retransmit step 3 of the handshake, however, if it does not receive an appropriate response or acknowledgement.  As a result of this, the client may receive step 3 multiple times, reinstalling the *same* session key each time, and thereby resetting both the *incremental transmit packet number (nonce)* and *receive replay counter* used by the data-confidentiality protocol.

Using the KRACK exploit, a malicious agent can force these *nonce* resets by replaying transmissions of step 3.  By forcing nonce reuse in this manner, the data-confidentiality protocol can be attacked.  Packets can be replayed, decrypted, and forged, leading to the theft of information, decryption of sensitive data and injection of malicious software.


## Who does it affect?

In short, the most vulnerable devices outed so far are *Android* and *Linux* devices due to the `wpa_supplicant` WiFi client that is commonly used.  That being said, this statement is taken directly from the vulnerability researcher, Mathy:

<include src="TweetQuote" quoteText="Any device that uses Wi-Fi is likely vulnerable to the KRACK vulnerability."/>

Unlike most vulnerabilities that are found in small or isolated components of systems, this vulnerability comes from within the WPA2 protocol itself.  The attack is against the 4-way handshake, and does not exploit access points themselves, but instead targets clients (devices such as laptops, tablets and phones).  This means that although a router may be updated and running the latest firmware, it is relatively unimportant, as whichever OS the connecting device is running on may be using the exploitable WPA2 protocol.

Although Windows, Mac and other brands are susceptible to this attack, as mentioned above, the most vulnerable are Linux based systems.  Quoting directly from the research paper, we can learn exactly why:

> " Our attack is especially catastrophic against version 2.4 and above of wpa_supplicant (the Wi-Fi client commonly used on Linux). Here, the client will install an all-zero encryption key instead of reinstalling the real key. 

> When the client now receives a retransmitted message 3 of the 4-way handshake, it will reinstall an all-zero key.  Because Android uses wpa_supplicant, Android 6.0 and above also contains this vulnerability. 

> Note that currently **50%** of Android devices are vulnerable to this exceptionally devastating variant of our attack. "

The reason this vulnerability could be particularly dangerous in a public WiFi situation is because among other things, the key reinstallation attacks allow a malicious agent to decrypt a TCP packet, learn the sequence number, and hijack the TCP stream to **inject arbitrary data**. This enables one of the most common attacks over Wi-Fi networks: injecting malicious data into an unencrypted HTTP connection.  Although a particular threat to public WiFi, of course, this is still a potential threat at home too.

Take a look below at the exploit being demonstrated in action, bypassing WPA2 against ***Android*** and ***Linux.***

<iframe width="800" height="450" src="https://www.youtube.com/embed/Oh4WURZoR98" frameborder="0"  allowfullscreen></iframe>


## What does this mean for you?

Well, hopefully, not too much.  As we'll see in the *mitigation* section below, vendors are responding well to this exploit and patches are already widely available.  However, that does not necessarily mean we are automatically safe.  The research paper was actually written back in May, but held privately for review, to give vendors a chance to patch software.  Since the paper was written, Mathy and his team have actually found an even easier way of exploiting the 4-way-handshake:

> With our novel attack technique, it is now trivial to exploit implementations that only accept encrypted retransmissions of message 3 of the 4-way handshake. In particular this means that attacking **macOS** and **OpenBSD** is significantly easier than discussed in the paper.

If you are a user of Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others, there is a good chance you may be affected by some variant of the attack.  Without wanting to make too many assumptions, I'm fairly sure that means pretty much all of us.  There is one caveat to this vulnerability though.  To exploit and manipulate the network connection, the malicious agent *would* need to be in range of the WiFi network.  This means that generally speaking, your home network is *relatively* safe, so long as your family and friends aren't avid hackers.  However, if you are a regular user of Public WiFi networks, it *could* be a much more bleak picture.

This vulnerability is also newly published, and there are (as of yet) no direct exploits available online for would-be malicious agents.  Because of this, and because Mathy will *not* release the code used to find and manipulate the vulnerability, the exploit would need to be entirely recreated by anyone who wished to use it maliciously.  That being said, the world is full of extraordinarily talented software engineers, and any one of them could use the research paper to reverse-engineer the exploit, and release their code at any time.

I am not intending to down-play this vulnerability, I fully understand how dangerous it could be, but it *is* being addressed and patched by vendors at a fantastic rate.  Another point to note here is that any network traffic with end-to-end encryption means a significant amount of the risk would be mitigated, as intercepted messages would not be able to be viewed so credentials and details could not be stolen.


## How to mitigate the situation

In this case, changing your WiFi network password or even swapping out your network router is not going to help.  The key to mitigating this vulnerability is ***patching your software.***  As I mentioned above, the vendor companies were informed of this vulnerability a few months ago, and most have been working away behind the scenes to release updates and patches.

For a full list of vendors who have already addressed this vulnerability, check out the [CERT Vulnerability Database](https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4) page.  As you will note, some of the biggest named vendors released patches quietly days / weeks ago.

Yesterday: 

- [Cisco](https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa)  released security patches,
- [Intel](https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00101&languageid=en-fr) released security patches,
- [Netgear](https://kb.netgear.com/000049498/Security-Advisory-for-WPA-2-Vulnerabilities-PSV-2017-2826-PSV-2017-2836-PSV-2017-2837) released security patches and information,
- [Aruba](http://www.arubanetworks.com/assets/alert/ARUBA-PSA-2017-007.txt) released a security advisory.

For Linux based systems:

- [OpenBSD](https://marc.info/?l=openbsd-announce&m=148839684520133&w=2) released WPA2 patches,
- [Debian](https://www.debian.org/security/2017/dsa-3999) also released patches.
- [Ubuntu](https://askubuntu.com/a/965685) fixes have been issued.

***Microsoft*** announced that they have included security patches in their October batch of security updates.  ***Apple*** have announced that they will be releasing macOS patches in the coming days, once tested.  ***Google*** have stated that patches for Android and ChromeOS will be released as soon as possible.

For other vendors, the [WiFi Alliance are working to mitigate](https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-security-update).


## Conclusion

<include src="TweetQuote" quoteText="As with most security vulnerabilities, the most important thing to consider here is patching your software as soon as you can."/>

As with most large or small security vulnerabilities, the biggest thing to consider here is ***patching your software*** as soon as you can.  With new updates and patches being released on an almost hourly basis as the moment, keep an eye on your vendor to ensure you grab yours as soon as applicable.

This exploit has indeed come as a huge shock to the security industry.  Not only was WPA2 a mathematically *proven* technology, but it was also certified and trusted.  The fact that it has taken 14 years for this exploit to come to light is just as big a shock, though I believe we should be glad that it has.  And amicably too.

For all of the research I've done over the last couple of days, I cannot find any examples of this exploit being used in a malicious way, or in any past hacks.  As I mentioned above, and as one can see from the research paper, this is not a particularly easy vulnerability to exploit, however I can almost guarantee now that it's come to light, there will be many trying.  You can help to stop them succeeding by ensuring you update / patch your systems.

I think *thanks* are in order for [Mathy Vanhoef](https://twitter.com/vanhoefm).  Both for finding and researching this vulnerability, but for being incredibly mature and responsible in the way he diagnosed and reported it.

If you would like a detailed insight into the inner workings of this vulnerability, Mathy has released his findings in a [KRACK Vulnerability Research Paper](https://papers.mathyvanhoef.com/ccs2017.pdf).

Stay safe out there!

[ **- @rbin**](https://twitter.com/rbin)


**About Auth0**

Ensuring that one's hardware *and* software are both patched and kept updated to the latest version is the best way of avoiding security vulnerabilities.  Many of the most prevalent security concerns start with users and user credential management.  Happily, we can ensure our user management is as secure as possible.

Auth0, a global leader in Identity-as-a-Service (IDaaS), provides thousands of customers in every market sector with the only identity solution they need for their web, mobile, IoT, and internal applications. Its extensible platform seamlessly authenticates and secures more than 50M logins per day, making it loved by developers and trusted by global enterprises.

As a developer, you can [try Auth0 for free!](https://auth0.com/signup)  Sign up now to [get started](https://auth0.com/signup).

For more information, visit [https://auth0.com](https://auth0.com/) or follow [@auth0 on Twitter](https://twitter.com/auth0).


WPA2 KRACK Attack: The WiFi Hack and What it Means

56227bdd539c480cc054eaa72eb1885d?s=200 avatar

56227bdd539c480cc054eaa72eb1885d?s=200

Guest Author

Antonio Sanso

JSON Web Encryption is vulnerable to a classic Invalid Curve Attack. Learn how this may affect you and what to do about it.



---

**TL;DR** If you are using [go-jose](https://github.com/square/go-jose), [node-jose](https://github.com/cisco/node-jose), [jose2go](https://github.com/dvsekhvalnov/jose2go), [Nimbus JOSE+JWT](https://bitbucket.org/connect2id/nimbus-jose-jwt/wiki/Home) or [jose4](https://bitbucket.org/b_c/jose4j/wiki/Home) with [ECDH-ES](https://tools.ietf.org/html/rfc7518) please update to the latest version. [RFC 7516 aka JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) and software libraries implementing this specification used to suffer from a classic [Invalid Curve Attack](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.107.3920&rep=rep1&type=pdf). This can allow an attacker to recover the secret key of a party using JWE with [Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES)](https://tools.ietf.org/html/rfc7518), where the sender could extract receiver’s private key.

---

## Premise

In this blog post I assume you are already knowledgeable about elliptic curves and their use in cryptography. If not [Nick Sullivan](https://twitter.com/grittygrease)'s  [A (Relatively Easy To Understand) Primer on Elliptic Curve Cryptography](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/) or Andrea Corbellini's series [Elliptic Curve Cryptography: finite fields and discrete logarithms](https://andrea.corbellini.name/2015/05/23/elliptic-curve-cryptography-finite-fields-and-discrete-logarithms/) are great starting points. Then if you further want to [climb the elliptic learning curve](https://moderncrypto.org/mail-archive/curves/2016/000784.html) including the related attacks you might also want to visit [https://safecurves.cr.yp.to/](https://safecurves.cr.yp.to/). Also the [DJB and Tanja talk at 31c3](https://www.youtube.com/watch?v=y_YxRUTI-xU) comes with an explanation of this very attack (see minute 43) or  [Juraj Somorovsky et al's research](https://web-in-security.blogspot.com/2015/09/practical-invalid-curve-attacks.html) can become handy for learners.

Note that this research was started and inspired by [Quan Nguyen from Google](https://research.google.com/pubs/pub45790.html) and then refined by [Antonio Sanso from Adobe](https://twitter.com/asanso).

## Introduction

JSON Web Token (JWT) is a JSON-based open standard ([RFC 7519](https://tools.ietf.org/html/rfc7519)) defined in the [OAuth specification family](https://tools.ietf.org/wg/oauth/) used for creating access tokens. The [Javascript Object Signing and Encryption (JOSE) IETF expert group](https://tools.ietf.org/wg/jose/) was then formed to formalize a set of signing and encryption methods for JWT that led to the release of  [RFC 7515 aka JSON Web Signature (JWS)](https://tools.ietf.org/html/rfc7515) and [RFC 7516 aka JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516). In this post we are going to focus on JWE.

A typical JWE is dot separated string that contains five parts:

* The JWE Protected Header
* The JWE Encrypted Key
* The JWE Initialization Vector
* The JWE Ciphertext
* The JWE Authentication Tag

An example of a JWE taken from the [specification](https://tools.ietf.org/html/rfc7516) would look like:

```
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGeipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDbSv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaVmqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je81860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi6UklfCpIMfIjf7iGdXKHzg.
48V1_ALb6US04U3b.5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji      SdiwkIr3ajwQzaBtQD_A.XFBoMYUZodetZdvTiFvSkQ
```

This JWE employs RSA-OAEP for key encryption and A256GCM for content encryption :

![JWE Token](https://images.ctfassets.net/23aumh6u8s0i/1dyW4IOQJ2ho2Awh683SGM/88808f9284793e4f0d2f553793149e88/header0)

This is only one of the many possibilities JWE provides. A separate specification called [RFC 7518 aka JSON Web Algorithms (JWA)](https://tools.ietf.org/html/rfc7518) lists all the possible available algorithms that can be used. The one we are discussing today is the [Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES)](https://tools.ietf.org/html/rfc7518).  This algorithm allows deriving an ephemeral shared secret ([this blog post from Neil Madden](https://neilmadden.wordpress.com/2016/05/20/ephemeral-elliptic-curve-diffie-hellman-key-agreement-in-java/) shows a concrete example on how to do ephemeral key agreement).

In this case the *JWE Protected Header* lists as well the used elliptic curve used for  the key agreement:

![JWE Decoded](https://images.ctfassets.net/23aumh6u8s0i/5noTU8YY54mWlpUKyi2Ozq/88c9228b62e82608553b669cde0197b2/header)

Once the shared secret is calculated the key agreement result can be used in one of two ways:

1. Directly as the Content Encryption Key (CEK) for the "enc" algorithm, in the Direct Key Agreement mode, or

2. As a symmetric key used to wrap the CEK with the A128KW, A192KW, or A256KW algorithms, in the Key Agreement with Key Wrapping mode.

This is out of scope for this post but as for the other algorithms the [JOSE Cookbook](https://tools.ietf.org/html/rfc7520) contains example of usage for ECDH-ES in combination with AES-GCM or AES-CBC plus HMAC.

## Observation

As highlighted by Quan during his talk at [RWC 2017](https://www.realworldcrypto.com/rwc2017):

>Decryption/Signature verification input is always under attacker’s control

As we will see thorough this post this simple observation will be enough to recover the receiver’s private key. But first we need to dig a bit into elliptic curve bits and pieces.

## Elliptic Curves

An elliptic curve is the set of solutions defined by an equation of the form:

**y^2 = x^3 + ax + b**

Equations of this type are called *Weierstrass equations*. An elliptic curve would look like:

![Elliptic Curve](https://images.ctfassets.net/23aumh6u8s0i/3JMVwOaOP8hav8C2MS8N74/e52a69e348548f4b51730cfd23defc2b/EC)

**y^2 = x^3 + 4x + 20**

In order to apply the theory of elliptic curves to cryptography we need to look at elliptic curves whose points have coordinates in a finite field Fq. The same curve will then look like below over Finite Field of size 191:

![Field Size](https://images.ctfassets.net/23aumh6u8s0i/2HBFINrYLGCVLAu5XTPzY1/829e76c4db6c3e059cdbcaad63b369ac/ECFP)

**y^2 = x^3 + 4x + 20 over Finite Field of size 191**

For JWE the elliptic curves in scope are the one defined in [Suite B](https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml) and ([only recently](https://www.rfc-editor.org/rfc/rfc8037.txt)) [DJB](https://cr.yp.to/djb.html)'s curve.
Between those, the curve that so far has reached the higher amount of usage is the famous P-256.

Time to open [Sage](https://www.sagemath.org/). Let's define P-256:

![P-256](https://images.ctfassets.net/23aumh6u8s0i/1w5nccSNZHZy9uMtZiscOi/1b644b3c53c2740ab5e0364630ebef38/p256)

The order of the curve is a really huge number hence there isn't much an attacker can do with this curve (if the software implements ECDH correctly) in order to guess the private key used in the agreement. This brings us to the next section:

## The Attack

The attack described here is really the classical [Invalid Curve Attack](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.107.3920&rep=rep1&type=pdf). The attack is simple and powerful and takes advantage from the mere fact that Weierstrass's formula for scalar multiplication does not take in consideration the coefficient b of the curve equation:

**y^2 = ax^3 + ax + b**.

The original's P-256 equation is:

![P-256](https://images.ctfassets.net/23aumh6u8s0i/1w5nccSNZHZy9uMtZiscOi/1b644b3c53c2740ab5e0364630ebef38/p256)

As we mention above, the order of this curve is really big. So we need now to find a more convenient curve for the attacker. Easy peasy with Sage:

![Sage](https://images.ctfassets.net/23aumh6u8s0i/7wF06Ez5NZQpbcDNVqTzDL/c86e6f9a18d6954588b623f181859b61/lift)

As you can see from the image above we just found a nicer curve (from the attacker point of view) that has an order with many small factors. Then we found a point P on the curve that has a really small order (2447 in this example).

Now we can build malicious JWEs (see the **Demo Time section** below) and extract the value of the secret key modulo 2447 with complexity in constant time.

A crucial part for the attack to succeed is to have the victim to repeat his own contribution to the resulting shared key. In other words this means that the victim should have his private key to be the same for each key agreement. Conveniently enough this is how the [Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES)](https://tools.ietf.org/html/rfc7518) works. Indeed ES stands for Ephemeral-Static were Static is the contribution of the victim!

At this stage we can repeat these operations (find a new curve, craft malicious JWEs, recover the secret key modulo the small order) many many times and collecting information about the secret key modulo many many small orders.

And finally [Chinese Remainder Theorem](https://en.wikipedia.org/wiki/Chinese_remainder_theorem) for the win!

At the end of the day the issue here is that the specification and consequently all the libraries I checked missed validating that the received public key (contained in the JWE Protected Header is on the curve), You can see the Vulnerable Libraries section below to check how the various libraries fixed the issue.

Again you can find details of the attack in the [original paper](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.107.3920&rep=rep1&type=pdf).

## Demo Time

**[INSTANT DEMO CLICK HERE](https://afternoon-fortress-81941.herokuapp.com/)**

![Demo](https://images.ctfassets.net/23aumh6u8s0i/5X3r9P3BfAM4MJr0pLjxW6/ad911b7bc91929f77e4919d7a542f1e7/attacker)

### Explanation

In order to show how the attack would work in practice I set up a live demo in Heroku. In [https://obscure-everglades-31759.herokuapp.com/](https://obscure-everglades-31759.herokuapp.com/) is up and running one Node.js server app that will act as a victim in this case. The assumption is this: in order to communicate with this web application you need to encrypt a token using the [Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES)](https://tools.ietf.org/html/rfc7518). The static public key from the server needed for the key agreement is in [https://obscure-everglades-31759.herokuapp.com/ecdh-es-public.json](https://obscure-everglades-31759.herokuapp.com/ecdh-es-public.json):

![Demo explanation](https://images.ctfassets.net/23aumh6u8s0i/6hUUsH3W5njnGY5NTNKkl1/852801c26b71b9cbf87db67f8fdaf027/ecdh)

An application that wants to POST data to this server needs first to do a key agreement using the server's public key above and then encrypt the payload using the derived shared key using the JWE format. Once the JWE is in place this can be posted to [https://obscure-everglades-31759.herokuapp.com/secret](https://obscure-everglades-31759.herokuapp.com/secret). The web app will respond with a response status 200 if all went well (namely if it can decrypt the payload content) and with a response status 400 if for some reason the received token is missing or invalid. This will act as an oracle for any potential attacker in the way shown in the previous The Attack section.

I set up an attacker application in [https://afternoon-fortress-81941.herokuapp.com/](https://afternoon-fortress-81941.herokuapp.com/).

You can visit it and click the 'Recover Key' button and observe how the attacker is able to recover the secret key from the server piece by piece. Note that this is only a demo application so the recovered secret key is really small in order to reduce the waiting time. In practice the secret key will be significantly larger (hence it will take a bit more to recover the key).

In case you experience problem with the live demo, or simply if  want to see the code under the hood, you can find the demo code in Github:

* [https://github.com/asanso/jwe-receiver](https://github.com/asanso/jwe-receiver) contains the code of the vulnerable server.
* [https://github.com/asanso/jwe-sender](https://github.com/asanso/jwe-sender) contains the code of the attacker.

## Vulnerable Libraries

Here you can find a list of libraries that were vulnerable to this particular attack so far:

* [node-jose](https://github.com/cisco/node-jose) v0.9.3 include the fixes necessary, which was [published few weeks ago](https://github.com/cisco/node-jose/blob/master/CHANGELOG.md). Here the [Gist](https://gist.github.com/asanso/fa25685348051ef6a28d49aa0f27a4ae) of the original proof of concept.*
* [jose2go](https://github.com/dvsekhvalnov/jose2go)'s fix landed in [version 1.3](https://groups.google.com/forum/).
* [Nimbus JOSE+JWT](https://bitbucket.org/connect2id/nimbus-jose-jwt/wiki/Home) pushed out a fixed artifact to Maven central as v4.34.2. Here the [Gist](https://gist.github.com/asanso/5b8cabb862e6f730e00a97d8565dc325) of the original proof of concept.**
* [jose4](https://bitbucket.org/b_c/jose4j/wiki/Home) now comes with a [fix](https://bitbucket.org/b_c/jose4j/commits/0517896170af8d5c057407c70a7b08dae454829e) for this problem since v0.5.5. Here the [Gist](https://gist.github.com/asanso/350e3ce993e44d0509c6023aa77fc6af) of the original proof of concept.**
* [go-jose](https://github.com/square/go-jose) (this is the original library found vulnerable by [Quan Nguyen](https://research.google.com/pubs/pub45790.html))

Some of the libraries were implemented in a programming language that already protects against this attack checking that the result of the scalar multiplication is on the curve:

\* Latest version of Node.js appears to be immune to this attack. It was still possible to be vulnerable when using browsers without web crypto support.

** Affected was the default Java SUN JCA provider that comes with Java prior to version 1.8.0_51. Later Java versions and the BouncyCastle JCA provider do not seem to be affected.  

## Improving the JWE Standard

I reported this issue to the JOSE working group via [mail to the appropriate mailing list](https://www.ietf.org/mail-archive/web/jose/current/msg05612.html). We all seem to agree that an errata where the problem is listed is at least welcomed. This post is a direct attempt to raise awareness about this specific problem.

## Aside: Securing Applications with Auth0

Are you building a [B2C](https://auth0.com/b2c-customer-identity-management), [B2B](https://auth0.com/b2b-enterprise-identity-management), or [B2E](https://auth0.com/b2e-identity-management-for-employees) tool? Auth0, can help you focus on what matters the most to you, the special features of your product. [Auth0](https://auth0.com/) can help you make your product secure with state-of-the-art features like [passwordless](https://auth0.com/passwordless), [breached password surveillance](https://auth0.com/breached-passwords), and [multifactor authentication](https://auth0.com/multifactor-authentication).

[We offer a generous **free tier**](https://auth0.com/pricing) to get started with modern authentication.

## Acknowledgement

The author would like to thanks the maintainers of [go-jose](https://github.com/square/go-jose), [node-jose](https://github.com/cisco/node-jose),[jose2go](https://github.com/dvsekhvalnov/jose2go), [Nimbus JOSE+JWT](https://bitbucket.org/connect2id/nimbus-jose-jwt/wiki/Home) and [jose4](https://bitbucket.org/b_c/jose4j/wiki/Home) for the responsiveness on fixing the issue. [Francesco Mari](https://twitter.com/francescomari) for helping out with the development of the demo application. Tommaso Teofili and Simone Tripodi for troubleshooting. Finally as mentioned above I would like to thank [Quan Nguyen from Google](https://research.google.com/pubs/pub45790.html), indeed this research could not be possible without his initial incipit.

That's all folks. For more crypto goodies, follow me on [Twitter](https://twitter.com/asanso/).

<div class="alert alert-info">
<strong>About Antonio Sanso:</strong><br />
Antonio works as Senior Software Engineer at Adobe Research Switzerland where he is part of the Adobe Experience Manager security team. Antonio is co-author of "OAuth 2 in Action" book. He found vulnerabilities in popular software such as OpenSSL, Google Chrome, Apple Safari and is included in the Google, Facebook, Microsoft, Paypal and Github security hall of fame. He is an avid open source contributor, being the Vice President (chair) for Apache Oltu and PMC member for Apache Sling. His working interests span from web application security to cryptography. Antonio is also the author of more than a dozen computer security patents and applied cryptography academic papers. He holds an MSc in Computer Science.
</div>


Critical Vulnerability in JSON Web Encryption

diegopoza

System Engineer, geek, foodie, technology lover, speaker.

Sr Manager, Developer Advocacy

Diego Poza

Tavis Ormandy, a vulnerability researcher at Google, discovered that Cloudflare was accidentally leaking sensitive data including passwords, private messages, and more. Learn how this may affect you and your customers and what to do next.



On February 17th, Tavis Ormandy, a vulnerabilities researcher at Google, sent the tweet that kicked off 2017's biggest security story yet:

![Tweet](https://images.ctfassets.net/23aumh6u8s0i/70lrHor3JHJ2mpMhcIYmD0/a8ae61fe8062a2abad060c9707f51819/tweet)

*Could someone from cloudflare security urgently contact me.* That's not something anyone wants to read on a Friday afternoon, but especially not when it's coming from one of the world's top infosec researchers.

The problem? While doing some routine bug checking, [Ormandy](https://twitter.com/taviso?lang=en) saw some data that did not match at all what he expected to find.

"It's not unusual to find garbage, corrupt data, mislabeled data or just ... non-conforming data...but the format of the data this time was confusing enough that I spent some time trying to debug what had gone wrong, wondering if it was a bug in my code," [he wrote](https://bugs.chromium.org/p/project-zero/issues/detail?id=1139), "In fact, the data was bizarre enough that some colleagues around the Project Zero office even got intrigued."

The rest of the Google Project Zero team (a team of security researchers employed specifically to find new [zero-day exploits](https://en.wikipedia.org/wiki/Project_Zero_(Google))) probably expected Google's announcement of the first [practical SHA-1 collision](https://auth0.com/blog/sha-1-collision-attack/) to be the big news of the week.

As they looked closer, they found “encryption keys, cookies, passwords, chunks of POST data and even HTTPS requests” for all sorts of different sites using Cloudflare—private messages, reservations, plaintext API requests from a password manager, hotel bookings.

How did all of this happen?

## Cloudflare was dumping memory across the web

It begins with a simple bug in the code to Cloudflare's highly popular reverse proxy service. HTTP requests to certain types of sites signed up with Cloudflare would trigger the bug, which would then "leak" data from random* *Cloudflare customers' sites (those that happened to be in memory at the time).

![Cloudflare](https://images.ctfassets.net/23aumh6u8s0i/SFApl9rEVZFr1bZEQnm2k/1df7cc080c9c802b225f4610a0daee12/cloudflare)

*A simple depiction of how a reverse proxy like Cloudflare's works. Since reverse proxies are shared between customers, data from all was at risk of being disclosed.*

Since September, random bits of data have been coming out of initialized memory and leaking across random Cloudflare customer's sites. In other words, if you went to visit a site that used Cloudflare, you could have had other people's sensitive information “leaking” into your own browsing session.

When search engines “crawled” these pages to index them, the same kind of information “leaked.” Because search engines cache the output they receive when they visit a page, all these leaked tokens, secrets, and messages were indexed, split up and spread across *millions* of pages of search results.

![Search Results](https://images.ctfassets.net/23aumh6u8s0i/569KQNvP3RuTSc2z9FCZy/83586ba930635d2bace66281330bc291/SERPs)

(Source: [Wordfence](https://www.wordfence.com/blog/2017/02/cloudflare-data-leak/))

While Cloudflare is working with the major search engines to purge their caches of sensitive information now, it's hard to avoid thinking about the paranoid version of events.

Paranoid version: state actors, or state-sponsored actors with significant resources, discovered this vulnerability before Google did. They found a way to send manipulated HTTP requests to Cloudflare sites that would output a predictable stream of user data—and have either packaged everything they found for resale or set about figuring out how to crack what could be billions of passwords, credit card numbers, and secret tokens.  

Cloudflare claims they can rule out this scenario with access logs, but whether or not that's true has been subject to [some debate](https://news.ycombinator.com/item?id=13721452).

> Auth0 can improve software security with the breached password detection feature. [This feature protects and notifies your users when their credentials are leaked by a data breach of a third party](https://auth0.com/breached-passwords). You can optionally prevent access until the user has reset their password.

## What you should do now

The way that data was disclosed means that any site using Cloudflare could potentially have had its secrets and tokens compromised. Patreon, Yelp, Uber, Medium, Fitbit, and OKCupid all use Cloudflare—for a full list of sites you can [click here](https://github.com/pirate/sites-using-cloudflare). Several tools have also been [built to assess your risk](http://www.doesitusecloudflare.com/), like this script that [crawls your Chrome history](https://gist.github.com/kamaljoshi/2cce5f6d35cd28de8f6dbb27d586f064).

Though many, many sites use Cloudflare, at least to some degree. It's still quite unlikely that your personal information has been exposed. Many of the individual sites mentioned have also come out and written posts to explain whether you should be concerned—perhaps most notably, 1Password, which was initially mentioned in Tavis's tweets as a [potentially compromised site](https://blog.agilebits.com/2017/02/23/three-layers-of-encryption-keeps-you-safe-when-ssltls-fails/).

The first thing you want to do to protect yourself from this and future incidents is to enable [multifactor authentication](https://auth0.com/multifactor-authentication). The most important sites to enable MFA on are the ones you use as an SSO iDP—if you're logging into 20 different sites using your Google credentials, then you definitely want to enable some form of MFA there.

While it's unlikely your passwords were exposed, this is as good a reminder as any that you should be using strong, unique passwords and organizing them using a password manager.

Resetting individual passwords for sites doesn't make much sense—the list of compromised sites is simply so vast. The only solution is to do a mass reset and make sure you're using proper password hygiene going forward.

## What you should do for your customers

As a site operator, you're probably wondering 1) if you're at risk, and 2) if any of your users' data was exposed in this incident.

Cloudflare has already reached out to domain owners that they have proactively identified as being at risk in this leak. However, the absence of notification does not mean that your domain (and customers) are safe.

First off, enable multifactor authentication [if you haven't already](https://auth0.com/multifactor-authentication). It's the easiest way to get a huge boost to the security of your site.

Many site operators have begun forcing password resets for all of their users. If you run a consumer site, it may not be worth the trouble and inconvenience. If your customers are in the enterprise, then it is probably a very good idea to force a change. If you're not going to make your users change their passwords (and from a cursory browse of the web this Monday morning, it appears that this is mostly the case), then you should at least recommend it.

As far as data invalidation, any secrets which you can easily rotate—session identifiers, tokens, keys—should immediately be changed. Customer SSL keys do not appear to have been compromised in this incident, but it would be prudent to change as much data as you can which may have passed through Cloudflare.  

If you or any of your customers are regulated by the Health Insurance Portability and Accountability Act (HIPAA), then you'll [definitely want](https://www.aptible.com/blog/aptible-was-not-affected-by-cloudbleed/) to have your security/compliance teams get in touch with your lawyers and discuss whether this is a breach that needs to be reported.


"vulnerability"