JavaScript エコシステムに対するサプライチェーン攻撃の防止

サプライチェーン攻撃は、JavaScript エコシステムにとって大きな問題です。この短い投稿では、ブラウザ内とブラウザ外の両方のすべての JavaScript ランタイムで実装できる簡単なセキュリティ対策の概要を説明します。これにより、今日 JavaScript エコシステムを悩ませているサプライチェーン攻撃のほとんどを防ぐことができます。

問題: 権限の継承

Web サイトがハッキングされた最近の事件は次のとおりです。

• 研究者らは、ポリフィルのサプライチェーン攻撃と模倣ギャンブルサイトの巨大なネットワークを結び付けています

問題の核心は、JavaScript モジュールが、それを呼び出したアプリケーションまたはモジュールの権限を継承するということです。これは、ブラウザ内ランタイムとブラウザ外ランタイムの両方の問題です。

アプリケーションが依存するモジュールのバージョンが、アプリケーションの作成者が知らないうちに変更される可能性があるという事実により、この問題はさらに複雑になります。したがって、すべての依存関係のコードが徹底的にレビューされたとしても (これ自体が大変な労力です)、依存関係のバージョンがロックダウンされていない場合、この労力は無駄になってしまいます。

なぜバージョンをロックダウンして、サーバーベースの依存関係を使用しないのでしょうか?これは主に、モジュール発行者がバグ修正を公開する場合、修正されたコードを使用する方が良いためです。これが、esm.sh などの JavaScript CDN がサーバーをサポートする大きな理由の 1 つです。

?ウェブサイトへの影響

Web ブラウザはサンドボックス化された実行環境であるため、Web サイトによってインポートされたサードパーティの JavaScript モジュール (3JM) がエンドユーザーのデバイスに損害を与えることはありません。

それにもかかわらず、3JM は、Web サイトの同意なしに、デバイスのコンピューティング リソースを使用し、ビットコイン マイニングなどのネットワーク リクエストを発行することができます。

?ブラウザ外の JavaScript アプリケーションへの影響

Deno などの一部のオフブラウザ ランタイムは、JavaScript/TypeScript アプリケーションに与えられるアクセス許可を制限する措置を実装しています。しかし、これらの対策は以下の理由から不十分です:

• Deno のようなパーミッション システムが強制されている場合でも、JS モジュールは呼び出し元のパーミッションを制限なく継承できます。これは、アプリケーションが完全な書き込み権限を持っている場合、コンピューティング リソース以外のリソースにアクセスできない電子メール アドレス バリデーターが、OS ユーザーに知られずにユーザー ファイルを削除できることを意味します。
• アプリケーションは多くの場合、OS ユーザーの完全な権限で実行されます。たとえば、MDRB などのツールで実行されるコードの場合、現在、実行中のコードへのアクセス許可を制限することはできません。

現在の解決策

現在、セキュリティ チームは、NPM などのよく知られたレジストリで公開されているモジュールの脆弱性を探すための自動プロセスを導入しています。このセキュリティ対策にはいくつかの欠点があります:

• 公開されたすべての既知のモジュールのすべてのバージョンをスキャンすることは、信じられないほどリソースを大量に消費します。
• 実際に利用可能なすべてのモジュールがスキャンされているという保証はありません。

?解決策: モジュールごとの権限

これらの問題を解決するために、JS/TS アプリケーションの現在の動作方法と下位互換性のある新しいモジュールごとの権限システムを提案します。

これには、各アプリケーションとモジュールが deno.json / deno.jsonc / package.json ファイルで宣言できる新しいオプションの権限設定が含まれます。権限には 2 つの部分があります:

• Permissions.self — ここで、アプリケーションまたはモジュールが、その依存関係に必要なアクセス許可を宣言します。
• Permissions.imports — ここで、アプリケーションまたはモジュールは、依存関係に割り当てることに同意するアクセス許可を宣言します。これは、各依存関係が要求できる権限のスーパーセットです。

JS/TS ランタイムによる権限の使用方法は次のとおりです。

• アプリケーションまたはモジュールがモジュール M をインポートすると、ランタイムは M の Permissions.self がインポーターが M に課す制限内にあるかどうかをチェックします。 >。そうでない場合、インポートはエラー (PermissionError など) をスローします。
• モジュールまたはアプリケーションが許可されていないことを実行しようとした場合にも、ランタイム エラー (PermissionError など) がスローされます。このランタイム エラーは、アプリケーションを中止せずに捕捉して処理できます。

権限の値は次のようになります:

{
  "self": {
    "read":  {"allow": [], "deny": []},
    "write": {"allow": [], "deny": []},
    "net":   {"allow": [], "deny": []},
    "env":   {"allow": [], "deny": []},
    "run":   {"allow": [], "deny": []}
  },

  "imports": {
    "jsr:@org/module@1.0.0": {
      "read":  {"allow": [], "deny": []},
      "write": {"allow": [], "deny": []},
      "net":   {"allow": [], "deny": []},
      "env":   {"allow": [], "deny": []},
      "run":   {"allow": [], "deny": []}
    },
    "https://cdn.example/org/module@1.0.0": {
      "read":  {"allow": [], "deny": []},
      "write": {"allow": [], "deny": []},
      "net":   {"allow": [], "deny": []},
      "env":   {"allow": [], "deny": []},
      "run":   {"allow": [], "deny": []}
    },
    "[default]": {
      "read":  {"allow": [], "deny": []},
      "write": {"allow": [], "deny": []},
      "net":   {"allow": [], "deny": []},
      "env":   {"allow": [], "deny": []},
      "run":   {"allow": [], "deny": []}
    }
  }
}

現在のソリューションと比較して、私が提案するソリューションにはいくつかの利点があります。

• 軽量 — 公開されたモジュールはスキャンする必要がありません。
• 徹底的 — 権限は実行時に強制されるため、適切な JS/TS エンジンが使用されていれば、未知のモジュールであっても漏れることはありません。

これは非常に簡単そうです。 JS/TS 言語を変更する必要はありません。アクセス許可の設定が存在しない場合は、アプリケーションとその依存関係グラフがすべてコマンド ライン引数 ∎

によって提供されたアクセス許可を持っている現在の状況に戻ります。

以上がJavaScript エコシステムに対するサプライチェーン攻撃の防止の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。