ネットスコープは2024年Gartner®社のセキュリティ・サービス・エッジ(SSE)のマジック・クアドラントでリーダーの1社として評価されました。 レポートを読む

閉める
閉める
  • Netskopeが選ばれる理由 シェブロン

    ネットワークとセキュリティの連携方法を変える。

  • 導入企業 シェブロン

    Netskope は世界中で 3,000 を超える顧客にサービスを提供しており、その中にはフォーチュン 100 企業の 25 以上が含まれます

  • パートナー シェブロン

    私たちはセキュリティリーダーと提携して、クラウドへの旅を保護します。

実行能力とビジョンの完全性において
最上位の評価

ネットスコープが2024年Gartner®社のセキュリティ・サービス・エッジ(SSE)のマジック・クアドラントで3年連続リーダーの1社として評価された理由をご覧ください。

レポートを読む
Netskope、2024年ガートナー®マジッククアドラント™セキュリティサービスエッジ部門でリーダーに選出 メニューのグラフィック
私たちは、お客様が何にでも備えることができるように支援します

お客様について
窓の外を見て微笑むメガネをかけた女性
Netskopeのパートナー中心の市場開拓戦略により、パートナーは企業のセキュリティを変革しながら、成長と収益性を最大化できます。

Netskope パートナーについて学ぶ
色々な若い専門家が集う笑顔のグループ
明日に向けたネットワーク

サポートするアプリケーションとユーザー向けに設計された、より高速で、より安全で、回復力のあるネットワークへの道を計画します。

ホワイトペーパーはこちら
明日に向けたネットワーク
Netskope One プラットフォームの紹介

Netskope One は、SASE とゼロトラスト変革を可能にする統合型セキュリティおよびネットワーキング サービスを提供するクラウドネイティブ プラットフォームです。

Netskope One について学ぶ
青い照明の抽象画
セキュアアクセスサービスエッジ(SASE)アーキテクチャの採用

Netskope NewEdgeは、世界最大かつ最高のパフォーマンスのセキュリティプライベートクラウドであり、比類のないサービスカバレッジ、パフォーマンス、および回復力を顧客に提供します。

NewEdgeの詳細
NewEdge
Netskope Cloud Exchange

Netskope Cloud Exchange (CE) は、セキュリティポスチャに対する投資を活用するための強力な統合ツールを提供します。

Cloud Exchangeについて学ぶ
Netskopeの動画
  • セキュリティサービスエッジ製品 シェブロン

    高度なクラウド対応の脅威から保護し、あらゆるベクトルにわたってデータを保護

  • Borderless SD-WAN シェブロン

    すべてのリモートユーザー、デバイス、サイト、クラウドへ安全で高性能なアクセスを提供

  • Secure Access Service Edge シェブロン

    Netskope One SASE は、クラウドネイティブで完全に統合された単一ベンダーの SASE ソリューションを提供します。

未来のプラットフォームはNetskopeです

インテリジェントセキュリティサービスエッジ(SSE)、クラウドアクセスセキュリティブローカー(CASB)、クラウドファイアウォール、セキュアウェブゲートウェイ(SWG)、およびZTNAのプライベートアクセスは、単一のソリューションにネイティブに組み込まれており、セキュアアクセスサービスエッジ(SASE)アーキテクチャへの道のりですべてのビジネスを支援します。

製品概要はこちら
Netskopeの動画
Next Gen SASE Branch はハイブリッドである:接続、保護、自動化

Netskope Next Gen SASE Branchは、コンテキストアウェアSASEファブリック、ゼロトラストハイブリッドセキュリティ、 SkopeAI-Powered Cloud Orchestrator を統合クラウド製品に統合し、ボーダレスエンタープライズ向けに完全に最新化されたブランチエクスペリエンスを実現します。

Next Gen SASE Branchの詳細はこちら
オープンスペースオフィスの様子
SASEアーキテクチャの設計 For Dummies

SASE設計について網羅した電子書籍を無償でダウンロード

電子書籍を入手する
最小の遅延と高い信頼性を備えた、市場をリードするクラウドセキュリティサービスに移行します。

NewEdgeの詳細
山腹のスイッチバックを通るライトアップされた高速道路
アプリケーションのアクセス制御、リアルタイムのユーザーコーチング、クラス最高のデータ保護により、生成型AIアプリケーションを安全に使用できるようにします。

生成AIの使用を保護する方法を学ぶ
ChatGPTと生成AIを安全に有効にする
SSEおよびSASE展開のためのゼロトラストソリューション

ゼロトラストについて学ぶ
大海原を走るボート
NetskopeがFedRAMPの高認証を達成

政府機関の変革を加速するには、Netskope GovCloud を選択してください。

Netskope GovCloud について学ぶ
Netskope GovCloud
  • リソース シェブロン

    クラウドへ安全に移行する上でNetskopeがどのように役立つかについての詳細は、以下をご覧ください。

  • ブログ シェブロン

    Netskope がセキュリティ サービス エッジ (SSE) を通じてセキュリティとネットワークの変革を実現する方法を学びます

  • イベント&ワークショップ シェブロン

    最新のセキュリティトレンドを先取りし、仲間とつながりましょう。

  • 定義されたセキュリティ シェブロン

    サイバーセキュリティ百科事典、知っておくべきすべてのこと

「セキュリティビジョナリー」ポッドキャスト

On Patents, Trolls, and Innovation
In this episode host Emily Wearmouth chats with Suzanne Oliver, an intellectual property expert, and Krishna Narayanaswamy, co-founder and CTO of Netskope, about the world of patents.

ポッドキャストを再生する
On Patents, Trolls, and Innovation
最新のブログ

Netskope がセキュリティ サービス エッジ (SSE) 機能を通じてゼロ トラストと SASE の導入をどのように実現できるかをご覧ください。

ブログを読む
日の出と曇り空
SASE Week 2023年:SASEの旅が今始まります!

第4回 SASE Weekのリプレイセッション。

セッションの詳細
SASE Week 2023
セキュリティサービスエッジとは

SASEのセキュリティ面、ネットワークとクラウドでの保護の未来を探ります。

セキュリティサービスエッジの詳細
4方向ラウンドアバウト
  • 会社概要 シェブロン

    クラウド、データ、ネットワークセキュリティの課題に対して一歩先を行くサポートを提供

  • リーダーシップ シェブロン

    Netskopeの経営陣はお客様を成功に導くために全力を尽くしています。

  • カスタマーソリューション シェブロン

    お客様の成功のために、Netskopeはあらゆるステップを支援いたします。

  • トレーニングと認定 シェブロン

    Netskopeのトレーニングで、クラウドセキュリティのスキルを学ぶ

データセキュリティによる持続可能性のサポート

Netskope は、持続可能性における民間企業の役割についての認識を高めることを目的としたイニシアチブである「ビジョン2045」に参加できることを誇りに思っています。

詳しくはこちら
データセキュリティによる持続可能性のサポート
思想家、建築家、夢想家、革新者。 一緒に、私たちはお客様がデータと人々を保護するのを助けるために最先端のクラウドセキュリティソリューションを提供します。

当社のチーム紹介
雪山を登るハイカーのグループ
Netskopeの有能で経験豊富なプロフェッショナルサービスチームは、実装を成功させるための規範的なアプローチを提供します。

プロフェッショナルサービスについて学ぶ
Netskopeプロフェッショナルサービス
Netskopeトレーニングで、デジタルトランスフォーメーションの旅を保護し、クラウド、ウェブ、プライベートアプリケーションを最大限に活用してください。

トレーニングと認定資格について学ぶ
働く若い専門家のグループ

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: Initial Access
Techniques: Attacker in the Browser
Mitigations (proposed): Application Developer Guidance, Vulnerability Scanning

Although MITRE does not currently link Application Developer Guidance to Attacker in the Browser, ensuring CORS is properly configured is an application developer responsibility. Some vulnerability scanners will detect CORS misconfigurations.

 Exploiting cross-site scripting on a vulnerable page

Tactics: Initial Access
Techniques: Exploit Public-Facing Application
Mitigations: Vulnerability Scanning

Cross-site scripting can be challenging to notice in code review, but there are lots of good tools for automatically finding cross-site scripting. In particular, input validation is one of the most powerful tools for mitigating XSS.

Exploiting the trust relationship between the page and the API gateway

Tactics: Privilege Escalation
Techniques: Process Injection
Mitigations: Vulnerability Scanning

Although conventionally, process injection refers to applications running on the endpoint, here we’re still making the same connection – an application is issuing commands on behalf of an attacker via injected code. By expanding our definition of process injection to include web applications, we cover the case of an application with a cross-site scripting vulnerability making a malicious call on behalf of an attacker.  Unfortunately, the only mitigation is to ensure that applications which are CORS-enabled do not have latent vulnerabilities.

Returning sensitive data from the database

Tactics: Collection
Techniques: Data from Information Repositories
Mitigations: Audit

More than auditing the database itself for sensitive data or for access from unauthorized places, it is crucial to audit the applications which access and allow access to sensitive data. 

Conclusion

If you’re running cloud infrastructure, especially APIs in the cloud, you almost certainly have CORS deployed somewhere. Verifying that you do not have CORS misconfigurations in your cloud apps is a critical step in securing your cloud infrastructure. However, even if you have CORS properly configured, it can bite you if the apps which leverage CORS connections are not themselves secure since CORS can act as an amplifier for any latent vulnerability. By using the Mitre ATT&CK framework, we can create tabletop scenarios which allow us to profile and emulate attacks before they happen and give us a holistic view of our defense posture against certain types of exploits.

Stay informed!

Subscribe for the latest from the Netskope Blog