Accélérez le déploiement de SASE grâce à la série "SASE Week Backstage". Explorer les sessions

fermer
fermer
  • Pourquoi Netskope signe chevron

    Changer la façon dont le réseau et la sécurité fonctionnent ensemble.

  • Nos clients signe chevron

    Netskope sert plus de 3 400 clients dans le monde, dont plus de 30 entreprises du Fortune 100

  • Nos partenaires signe chevron

    Nous collaborons avec des leaders de la sécurité pour vous aider à sécuriser votre transition vers le cloud.

Un Leader du SSE.
Et maintenant un Leader du SASE à fournisseur unique.

Découvrez pourquoi Netskope a été classé parmi les leaders de l'édition 2024 du Gartner® Magic Quadrant™️ pour le Secure Access Service Edge à fournisseur unique.

Recevoir le rapport
Pleins feux sur les clients visionnaires

Découvrez comment des clients innovants naviguent avec succès dans le paysage évolutif de la mise en réseau et de la sécurité d’aujourd’hui grâce à la plateforme Netskope One.

Obtenir l'EBook
Pleins feux sur les clients visionnaires
La stratégie de commercialisation de Netskope privilégie ses partenaires, ce qui leur permet de maximiser leur croissance et leur rentabilité, tout en transformant la sécurité des entreprises.

En savoir plus sur les partenaires de Netskope
Groupe de jeunes professionnels diversifiés souriant
Votre réseau de demain

Planifiez votre chemin vers un réseau plus rapide, plus sûr et plus résilient, conçu pour les applications et les utilisateurs que vous prenez en charge.

Obtenir le livre blanc
Votre réseau de demain
Présentation de la plate-forme Netskope One

Netskope One est une plate-forme cloud native qui offre des services de sécurité et de mise en réseau convergents pour faciliter votre transformation SASE et Zero Trust.

En savoir plus sur Netskope One
Abstrait avec éclairage bleu
Adopter une architecture SASE (Secure Access Service Edge)

Netskope NewEdge est le nuage privé de sécurité le plus grand et le plus performant au monde. Il offre aux clients une couverture de service, des performances et une résilience inégalées.

Découvrez NewEdge
NewEdge
Netskope Cloud Exchange

Le Netskope Cloud Exchange (CE) fournit aux clients des outils d'intégration puissants pour optimiser les investissements dans l'ensemble de leur infrastructure de sécurité.

En savoir plus sur Cloud Exchange
Aerial view of a city
La plateforme du futur est Netskope

Intelligent Security Service Edge (SSE), Cloud Access Security Broker (CASB), Cloud Firewall, Next Generation Secure Web Gateway (SWG), et Private Access for ZTNA intégrés nativement dans une solution unique pour aider chaque entreprise dans son cheminement vers l'architecture Secure Access Service Edge (SASE).

Présentation des produits
Vidéo Netskope
Next Gen SASE Branch est hybride - connectée, sécurisée et automatisée

Netskope Next Gen SASE Branch fait converger Context-Aware SASE Fabric, Zero-Trust Hybrid Security et SkopeAI-Powered Cloud Orchestrator dans une offre cloud unifiée, ouvrant la voie à une expérience de succursale entièrement modernisée pour l'entreprise sans frontières.

En savoir plus Next Gen SASE Branch
Personnes au bureau de l'espace ouvert
La conception d'une architecture SASE pour les nuls

Obtenez votre exemplaire gratuit du seul guide consacré à la conception d'une architecture SASE dont vous aurez jamais besoin.

Obtenir l'EBook
Optez pour les meilleurs services de sécurité cloud du marché, avec un temps de latence minimum et une fiabilité élevée.

Découvrez NewEdge
Autoroute éclairée traversant des lacets à flanc de montagne
Permettez en toute sécurité l'utilisation d'applications d'IA générative grâce au contrôle d'accès aux applications, à l'accompagnement des utilisateurs en temps réel et à une protection des données de premier ordre.

Découvrez comment nous sécurisons l'utilisation de l'IA générative
Autorisez ChatGPT et l’IA générative en toute sécurité
Solutions Zero Trust pour les déploiements du SSE et du SASE

En savoir plus sur la confiance zéro
Bateau roulant en pleine mer
Netskope obtient l'autorisation FedRAMP High Authorization

Choisissez Netskope GovCloud pour accélérer la transformation de votre agence.

En savoir plus sur Netskope GovCloud
Netskope GovCloud
  • Ressources signe chevron

    Découvrez comment Netskope peut vous aider à sécuriser votre migration vers le Cloud.

  • Blog signe chevron

    Découvrez comment Netskope permet la transformation de la sécurité et de la mise en réseau grâce à l'accès sécurisé à la périphérie des services (SASE).

  • Événements et ateliers signe chevron

    Restez à l'affût des dernières tendances en matière de sécurité et créez des liens avec vos pairs.

  • Définition de la sécurité signe chevron

    Tout ce que vous devez savoir dans notre encyclopédie de la cybersécurité.

Podcast Security Visionaries

L'avenir de la sécurité : Quantum, IA et changements macropolitiques
Emily Wearmouth et Max Havey s'entretiennent avec Sanjay Beri, PDG de Netskope, et Krishna Narayanaswamy, directeur technique, sur l'avenir de la sécurité.

Écouter le podcast Parcourir tous les podcasts
L'avenir de la sécurité : Quantum, IA et changements macropolitiques
Derniers blogs

Découvrez comment Netskope peut faciliter le parcours Zero Trust et SASE grâce à des capacités d'accès sécurisé à la périphérie des services (SASE).

Lire le blog
Lever de soleil et ciel nuageux
SASE Week 2024 A la demande

Apprenez à naviguer dans les dernières avancées en matière de SASE et de confiance zéro et découvrez comment ces cadres s'adaptent pour répondre aux défis de la cybersécurité et de l'infrastructure.

Explorer les sessions
SASE Week 2024
Qu'est-ce que SASE ?

Découvrez la future convergence des outils réseau et sécurité dans le modèle économique actuel, dominé par le cloud.

En savoir plus sur SASE
  • Entreprise signe chevron

    Nous vous aidons à conserver une longueur d'avance sur les défis posés par le cloud, les données et les réseaux en matière de sécurité.

  • Carrières signe chevron

    Join Netskope's 3,000+ amazing team members building the industry’s leading cloud-native security platform.

  • Solutions pour les clients signe chevron

    Nous sommes là pour vous et avec vous à chaque étape, pour assurer votre succès avec Netskope.

  • Formation et accréditations signe chevron

    Avec Netskope, devenez un expert de la sécurité du cloud.

Soutenir le développement durable par la sécurité des données

Netskope est fière de participer à Vision 2045 : une initiative visant à sensibiliser au rôle de l'industrie privée dans le développement durable.

En savoir plus
Soutenir le développement durable grâce à la sécurité des données
Contribuez à façonner l'avenir de la sécurité du cloud

At Netskope, founders and leaders work shoulder-to-shoulder with their colleagues, even the most renowned experts check their egos at the door, and the best ideas win.

Rejoignez l’équipe
Carrières chez Netskope
L’équipe de services professionnels talentueuse et expérimentée de Netskope propose une approche prescriptive pour une mise en œuvre réussie.

En savoir plus sur les services professionnels
Services professionnels Netskope
Sécurisez votre parcours de transformation numérique et tirez le meilleur parti de vos applications cloud, Web et privées grâce à la formation Netskope.

En savoir plus sur les formations et les certifications
Groupe de jeunes professionnels travaillant

CORS Exploitation in the Cloud

Jan 09 2020

Cross-Origin Resource Sharing (CORS) is a mechanism which uses HTTP headers to tell a browser that a web application running at one origin has permission to access selected resources from a server at a different origin. This functionality exists for cases where an application developer would want to deliberately ignore a same origin policy (SOP) which mitigates many common attacks against browsers (notably cross-site scripting). This makes it a powerful tool for applications deployed on our increasingly distributed Internet but also a potential source of vulnerability. 

Background: What is the Same-Origin Policy?

The Same-Origin Policy is a mitigating control which restricts how scripts or other resources from one origin interact with resources from a third party. 

Some examples of cross-origin requests are:

  • A different domain (example.com to test.com)
  • A different subdomain (example.com to test.example.com)
  • A different port (example.com to example.com:8080)
  • A different protocol (https://example.com to http://example.com)

The Same-Origin policy mitigates some common web application attacks and is a critical tool for protecting users and applications on the modern web.

More details are available at the Mozilla Developer Network.

How Does CORS Work?

There are two headers which primarily govern CORS: Access-Control-Allow-Origin, and Access-Control-Allow-Credentials. When a script from foo.com wants to make a request to bar.com, the browser sends a pre-flight request to bar.com with foo.com in the Origin header. This is how the browser asks for permission for the resource to interact with the requesting site. The service on bar.com will then return an Access-Control-Allow-Origin response header if the domain matches an allowed origin. Only if the domain matches the one hosting the script does the browser send the HTTP request.

The Access Control Allow Origin header accepts various origins:

  • Domains and subdomains (http://blah.example.com, https://example.com)
  • Wildcards (*)
  • ‘Null’

The case of the ‘Null’ origin is interesting and can result in some misconfigurations which we do not explore in this article. ‘Null’ is an origin assigned by default to many documents, sandboxed code, and redirects. While this is useful, it  can potentially open up your application to attack. The Mozilla Developer Network and w3c specify that the null origin should not be used. More details about that vulnerability are available in Portswigger’s blog on the subject.

Access-Control-Allow-Credentials is a boolean – that is, it can be only True or False. If our application requires a user to be authenticated to use it, and that application makes CORS requests on behalf of that logged in user, we require Access-Control-Allow-Credentials to be true. If the resources we are accessing do not absolutely require that the user’s credentials be passed to the cross-domain resource, we should set this to False. 

In some cases, you may want to bypass the same-origin policy to share content from a CDN, an S3 bucket, or an on-premises server.

  • If you host your website in S3, but want to use JavaScript to be able to make authenticated GET and PUT requests against the same bucket by using the Amazon S3 API endpoint for the bucket.
  • Loading a web font.
  • Loading dynamic content from another webpage.
  • Making an authenticated GET request to an on-prem server.

If you want to allow any domain to make a cross-origin request, you can certainly use the setting Access-Control-Allow-Origin: *

Unfortunately, per the CORS specification – if you have wildcards in your ACAO header, then Access-Control-Allow-Credentials cannot be true. While you might think that maintaining a list of allowed origins makes good sense, it turns out that CORS policy cannot accept a list either! So in order to allow credentials to be passed over a CORS request, you must process the origin and ensure that it’s valid. As we’ll explain, this is a recipe for disaster when developers are not careful.

CORS in the Cloud

In addition to the fact that any VM you deploy in your IaaS environment which supports HTTP can enable CORS, many individual services support CORS, including: 

  • Azure Functions
  • Azure Logic Apps
  • Azure Blob Storage
  • Google Cloud Functions
  • Google Cloud Storage
  • Google Cloud Endpoints
  • Amazon Lambda
  • Amazon S3
  • Amazon API Gateway

Clearly, this is a functionality that is widespread, and often used by web developers. As your infrastructure grows and matures, CORS is very likely to see use across your cloud infrastructure.

In the case of Lambda and API Gateway, Amazon provides the following guidance:

“To enable cross-origin resource sharing (CORS) for a proxy integration, you must add Access-Control-Allow-Origin: <domain_name> to the output headers. <domain_name> can be * for any domain name.”

As mentioned above, this works wonderfully, as long as you don’t need the Access-Controls-Allow-Credentials field to be true. If you need credentials, you’ll need to process the user-supplied origin. If you have never deployed CORS before and turn to the Internet for a template, you may end up using one of the many code examples which only reflect the origin and do not provide specific instructions on ensuring CORS is deployed securely.

Realistically, the most secure configuration is a hard-coded allow list that is maintained by the developer. However, as discussed below, even this does not stop CORS from opening up an exploitable hole.

Exploiting Misconfigurations

One of the most common misconfigurations, as mentioned above, is reflecting the user-supplied origin header in the server response, effectively allowing requests from any origin. As an example, consider an AWS Lambda and API Gateway serverless architecture where the Lambda accesses data stored in a DynamoDB instance. If you want to include more than a single domain in the ACAO header (e.g., you have more than one subdomain that will need to access the API), then you’ll need to write a Lambda to handle the headers. Note that while we use AWS and Amazon services here as examples, these same sorts of vulnerabilities can also occur with the same architecture in both Azure and GCP. In the Azure case, this architecture would be comprised of Azure Application Gateway, Azure Functions, and CosmosDB. In GCP, the corresponding services would be Cloud Endpoints, Google Cloud Functions, and BigTable.

Figure 1: Simple CORS-enabled API Gateway Architecture

Now in this case, we can see that a request made to the API Gateway will trigger the lambda which generates the CORS headers. As we mentioned with this misconfiguration – the lambda is simply reflecting the origin provided by the user, and that request is then handed off to the second lambda to make database queries by way of the API gateway. This database can contain whatever sort of information you might access via API but don’t want disclosed to the world (e.g. customer records, API keys, etc.). 

This means that all an attacker needs to do is get an unwitting but authorized user to make the request on their behalf from their domain. This can be attained by any number of methods: script injection, phishing, or any other way that a user might inadvertently navigate to an attacker-controlled resource. When the victim navigates to the attacker controlled resource, the sensitive request is made from the attacker’s origin with the authorized user’s credentials, and CORS allows this to occur, providing the sensitive data back to the attacker.

Impacts of CORS Misconfigurations

Examples of CORS misconfigurations being exploited:

  • A US Department of Defense Website had an improper access control in CORS which allowed an attacker to steal user sessions.
  • A bitcoin exchange had a vulnerability which could steal users’ private API key, allowing all of their BTC to be transferred to an arbitrary address.

These vulnerabilities and others like them underscore the need to verify that your CORS configuration is correct. This means ensuring that you are not simply reflecting the origin that you are provided by the browser, but maintaining an accurate, up-to-date allow list. 

The Cream in Your XSS Coffee

(AUTHOR NOTE: It doesn’t matter if you personally like cream in your coffee. This is just a euphemism. I personally favor a venti Americano with a splash of cream and 3 splenda.)

Using CORS trust relationships, we can actually use even properly configured environments to make a cross-site scripting vulnerability on one site far more damaging. Given an XSS vulnerability on a page which is trusted via CORS, an attacker can retrieve sensitive information from the site which trusts the vulnerable page. 

In this scenario, we’ll use the same API Gateway configuration as above, but assume that it actually does the CORS Origin checks correctly – that is, it looks for a valid subdomain and returns only if the user is authenticated and the request comes from a subdomain which is on an accurate allow list. 

Figure 2: Simple CORS-enabled S3 Front-End for API Gateway Architecture

In this scenario, there is no CORS misconfiguration, but instead the page on the S3 Bucket is vulnerable to Cross-Site Scripting. In this scenario, the attacker exploits that cross-site scripting vulnerability and instead injects JavaScript which retrieves information from the database. All of this happens because the API gateway, and therefore the database, trust the website hosted in the bucket. 

These attacks and more have been detailed in a non-cloud context by the folks over at Portswigger, the makers of Burp Suite. 

Even though these are hypothetical examples, knowing about CORS security is key because cross-domain requests are even more common in the cloud than they are in on-premises systems and so there are more opportunities for these sorts of vulnerabilities to exist and be exploited. So how do we deal with attacks that target our CORS-enabled cloud applications?

Thinking About CORS Under ATT&CK

The MITRE ATT&CK framework provides a useful way of looking at where CORS, whether configured correction and used to exploit trust relationships or misconfigured and exploited, can impact your enterprise and the ripple effects of ensuring that your web applications are safe from cross-site scripting. In this section, we summarize the associated tactics and techniques.

Enticing a user to access a page with a malicious script

Tactics: User Execution
Techniques: Drive-by Compromise, Spearphishing Link
Mitigations: Restrict Web-Based Content

Blocking JavaScript is a powerful tool for preventing this entire exploit chain in the first place. Of course, this can be difficult to do generally due to the ubiquity of JavaScript on the modern web. Having an allow list for running Javascript from trusted sources is crucial.
This mitigation is, due to the nature of the attack, the only one in this list designed to protect users on the endpoint rather than protect the application from exploitation.

Using the CORS misconfiguration to gain privileged access via origin reflection

Tactics: