見出し画像

[W3C]Subresource Integrity の要点まとめ

り

W3CのWeb Application Security WGが公開している、「Subresource Integrity(サブリソース完全性)」というRecommendationの大事なところを日本語でまとめていきます。英語の原文は以下です。

概要

本文書はユーザーエージェントが、取得したリソースに意図していない改変がないどうかを確認する仕組みを定義します。

はじめに

ウェブサイトはさまざまなオリジンからスクリプト・画像などを取得し、表示しています。その場合、以下のような攻撃が可能です。

  • 攻撃者がDNSポイズニングなどを使いユーザーが意図していない有害なコンテンツをダウンロードするように仕掛ける

  • 攻撃者がCDNサーバーのファイルを置き換えて、有害なコンテンツをインジェクションする

現状サーバーを認証する方法はありますが、ファイルの中身を意図したものかどうか認証する仕組みが必要です。ここで、integrity属性を紹介します。このintegrity属性は、読み込まれるはずの内容をハッシュ暗号化した文字列が入ります。つまり、ユーザーエージェントはスクリプトなどを実行する前に、意図した内容かどうかをハッシュ文字列を使って確認することができます。

以下のように使うことができます。(勧告文書の1.2.1 EXAMPLE 2・3より)

<link rel="stylesheet" href="https://site53.example.net/style.css"
      integrity="sha384-+/M6kredJcxdsqkczBUjMLvqyHb1K/JThDXWsBVxMEeZHEaMKEOEct339VItX1zB"
      crossorigin="anonymous">
<script src="https://analytics-r-us.example.com/v1.0/include.js"
        integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC6CGiSN2n4QUbHNPhzk5Xhm0djZLQqTpL0HzTUxk"
        crossorigin="anonymous"></script>

フレームワーク

ハッシュは次のようなスクリプトで生成することができます。

echo -n "alert('Hello, world.');" | openssl dgst -sha384 -binary | openssl base64 -A

そして、ユーザーエージェントはSHA-256、SHA-384、SHA-512のハッシュをサポートする必要があります(MUST)

セキュリティに関する考慮事項

元々セキュアでないコンテキスト

HTTPのページなどの場合、攻撃者は文書自体を改変できる恐れがあります。このため、Integrityを含むメタデータはセキュアなコンテキストのみを対象にしています。

ハッシュ衝突

MDNやSHA-1などはハッシュ衝突しやすいため、現状ではSHA-384などを使いましょう。

クロスオリジンデータ流出

本文書はCORS属性の設定が必要になります。もしこの設定を省いた場合は、攻撃者は同一ドメインポリシーに違反することができてしまいます。

もし攻撃者が適当なハッシュ(ダイジェスト)を使い、ファイルを取得しようとします。もし失敗した場合は、「このダイジェストでは取得できない」ということがわかり、攻撃者に情報を与えることになってしまいます。

よく使われる以下のような値をブルートフォースで試すこともできてしまいます。

{'status': 'authenticated', 'username': 'admin'}

関連するトピックのリンク