CDNを介して配信されるJavaScriptファイルが変更されていないことを確認するにはどうすればよいですか?


88

一部のJavaScriptファイルがCDNでホストされるシナリオに取り組んでいます。これらのファイルがユーザー側でダウンロードされるときに、ファイルが改ざんされておらず、実際に指定されたCDNからのものであることを確認できるように、何らかのメカニズムが必要です。

SSLを使用している場合、タスクは非常に簡単であることを理解していますが、SSLなしのHTTPでも適切なファイルが提供されるようにしたいと思います。

私が検索できる限り、プラットフォーム間でサポートされているJavaScriptファイルのデジタル署名のような既存のメカニズムはありません。おそらくそれは必要ないのでしょうか?

JavaScriptファイルの作成者を確認するためにブラウザに組み込まれている方法はありますか?安全にこれを行うために私ができることはありますか?


13
この質問は興味深いと思いますが、話題外ではありませんか?
evolutionxbox

20
なぜhttpでファイルを提供するのですか?
njzk2

12
「しかし、なぜそのようなメカニズムがないのですか?」それはだから、本当に難しいです。データがサーバーを離れると、トーストになります。HTTPSは役立ちますが、プレーンなHTTP接続の場合、検証は失敗する可能性があります(または、合格)。MITM攻撃は、ブラウザが期待に応える前に、予想される署名や提供されたものの署名を変更するだけです。したがって、ユーザーがペイロードを受信した場合、それは完全に安全であると見なされます...必ずしもそうではありません。
VLAZ

4
「しかし、なぜそのようなメカニズムがないのですか?」HTTPSには、安価で効果的で広く適用可能なソリューションがすでにあるからです。
Kevin Krumwiede 16

9
これは、ServerFaultまたはSecurityにあるはずです。これは、ファイルを安全な方法で提供することであり、プログラミングとの関係は、たまたまソースファイルを表すファイルであるため、接線方向のみです。
underscore_d

回答:


140

実際のところ、このような機能は現在Subresource Integrityという名前で作成されています。タグintegrity属性を<script>調べます。 まだ全面的に採用されているわけではありませんが、この目的だけを満たします。

integrity

ユーザーエージェントがフェッチされたリソースが予期しない操作なしで配信されたことを確認するために使用できるインラインメタデータが含まれています。サブリソースの整合性を参照してください。

ソース

サブリソース整合性(SRI)は、ブラウザがフェッチしたファイル(CDNなどから)が予期しない操作なしに配信されたことをブラウザが確認できるようにするセキュリティ機能です。フェッチされたファイルが一致する必要がある暗号化ハッシュを提供できるようにすることで機能します。

ソース


例:

<script src="https://example.com/example-framework.js"
    integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    crossorigin="anonymous"></script>

ただし、プレーンHTTP経由でリソースを転送している場合は、Man in the Middle攻撃から保護されないことに注意してください。この場合、攻撃者がハッシュコードを偽装する可能性があり、操作されたスクリプトファイルに対する防御が役に立たなくなります。

このため、上記のセキュリティ対策に加えて、プレーンなHTTPではなく、常に安全なHTTPS接続を使用する必要があります。


9
OPがHTMLとアセットファイルを送信することを計画していると仮定すると、整合性チェックは簡単に偽造できることに言及する価値があると思います。サイトがHTTPSであり、HTTP経由でアセットを提供したい場合、ほとんどのブラウザーはこれを好みませんし、HTTPアセットを黙って無視します。
MonkeyZeus

3
@MonkeyZeusこれは、MITM攻撃の場合、または自社のサーバーが侵害された場合にのみ当てはまります。私の理解では、問題は、侵害されたCDNからどのように防御するかを明確に尋ねているということです。
ティモ

10
@TimoStaその通り!これらのチェックが行われていない場合、たとえばからのスクリプトを含めると、HTTPS経由でアクセスされているかどうかに関係なく、https://code.jquery.com/侵害した誰でもcode.jquery.comサイトをXSS code.jquery.comできます。これらのチェックが適切に行われている場合、攻撃者はスクリプトの読み込みを防止できるだけであり、悪意のあるスクリプトに置き換えることはできません。
Ajedi32

1
@MonkeyZeus私はあなたの懸念を述べて、私の回答にメモを追加しました。この文言に同意しますか?
Timo

1
@TimoStaとてもいいです、私はそれが好きです!ところで、最初のコメントを投稿する前でも+1をしました:-)
MonkeyZeus

36

サブリソースの整合性チェックを探しています。

たとえば、jQuery CDNスニペットは次のとおりです。

<script src="https://code.jquery.com/jquery-3.1.0.js"
        integrity="sha256-slogkvB1K3VOkzAI8QITxV3VzpOnkeNVsKvtkYLMjfk="
        crossorigin="anonymous"></script>

2
攻撃者がダウンロードするスクリプトを変更すると同時に整合性フィールドを変更できるため、まったく役に立たない。
にオービットでライトネスレース

15
@LightnessRacesinOrbit:HTTPS経由でアクセスされる独自のドメインを制御しているが、を制御していない場合はそうではありませんcode.jquery.com。これにより、セキュリティが侵害されるのを防ぐことができますcode.jquery.com
SilverlightFox

2
@SilverlightFox:OK、MITM攻撃に対してまったく役に立たない*
オービットの

@LightnessRacesinOrbitはい。まだ非常に有用で、例えば、この攻撃を阻止しているだろう:bleepingcomputer.com/news/security/...
エイドリアンMouat

6

免責事項:いつものように、これらのメカニズムはhttpsを使用する場合にのみ有用であると考える必要があります。これらはhttpを使用したMitMで簡単に無効にできるためです。

上記の回答のメカニズムに加えて、親ページでコンテンツセキュリティポリシーの http応答ヘッダーを使用することもできます。

http://www.html5rocks.com/en/tutorials/security/content-security-policy/

Content-Security-Policy:script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng ='

ここで注意すべきことがいくつかあります。sha *-プレフィックスは、ハッシュの生成に使用されるアルゴリズムを指定します。上記の例では、sha256-が使用されています。CSPは、sha384-およびsha512-もサポートしています。ハッシュを生成するときは、タグを含めないでください。先頭と末尾の空白を含む、大文字と空白も重要です。

Chrome 40以降を使用すると、DevToolsを開いてページを再読み込みできます。[コンソール]タブには、各インラインスクリプトの正しいsha256ハッシュを含むエラーメッセージが含まれます。

このメカニズムはかなり前から存在しているため、ブラウザのサポートはかなり良いと思われます。必ず確認してください。

さらに、古い非準拠ブラウザーが安全でないことを確認したい場合は、ポリシーで許可されていない同期リダイレクトスクリプトをページの上部に含めることができます。


かなり前から存在していますが、ブラウザのサポートはあまり良くありません。caniuse.com/subresource-integrity
Sp0T

@ Sp0t-サブリソースの整合性(リンクの内容)は、他の回答のメカニズムです。私の答えは、はるかに優れたサポートを提供するコンテンツセキュリティポリシーについてです
Fabio Beltramini 2016

3

この種の署名ができることとできないことには重要なポイントがあります。誰かがあなたのコードを変更する仮想的な攻撃からユーザー保護することができます。コードが実行されているコードであることをサイトに保証することはできません。言い換えれば、クライアントからあなたのサイトに来るものはまだ信頼できません。


2

攻撃者がCDNから配信されたJavaScriptファイルを変更することを攻撃者に許可する場合、攻撃者は攻撃者が配信時に参照元を変更して検証の試みを削除し、送信元アドレスをCDN、および/またはJavaScriptへの参照を完全に削除します。

また、アプリケーションがユーザーのリゾルバーがHTTPリクエスト(または検証された信頼の連鎖を持たないその他のメカニズム)を介してCDNに正しく解決されているかどうかを判断する方法のワームの缶を開かないでください。

/ etc / hosts:

#  ...
1.2.3.4    vile-pirates.org    trustworthy.cdn
#  ...

2
最初の文は明らかに真実ではありません。参照ページがHTTPS経由で読み込まれ、JavaScriptファイルがHTTP-not-S経由で読み込まれた場合はどうなりますか?
user253751

あるいは、CDN自体が危険にさらされているが、自分のサーバーは危険にさらされていない場合
Ajedi32

@immibis:私は、OPがそのようなシナリオを提案するほど非合理的ではないと想定することを選択します。
エリックタワーズ

1
@immibisブラウザーが一般にHTTPSページがHTTP経由でJSをロードすることを許可しないのはなぜですか?
Barmar

1
@immibis私はブラウザがそれを許可しないので、それは不可能さえある状況を改善すると言っていました。
Barmar

1

これは、サブリソースの整合性で確認できます。多くのパブリックCDNでは、CDN Webサイトで提供される埋め込み可能なコードにSRIハッシュが含まれています。たとえば、PageCDNでは、jQuery CDNページでjqueryファイルをクリックすると、URLをコピーするか、以下のようにSRIハッシュを含むスクリプトタグを使用するオプションが表示されます。

<script src="https://pagecdn.io/lib/jquery/3.4.1/jquery.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script>

ページの読み込み時に、ブラウザはこのリソースのリクエストを発行し、リクエストの完了時に、受信したファイルのハッシュをスクリプトタグの整合性値として指定されたものと照合します。両方のハッシュが一致しない場合、ブラウザはjqueryファイルを破棄します。

現在、この機能は世界中のブラウザの91%でサポートされています。caniuseの詳細。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.