0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

通信ゼロの試験が、通信を混ぜても成功したら困る

0
Posted at

AI補助で開発・検証したブラウザー内CSV比較試作の記録には、ローカルのBlob読込までHTTP通信として数えた試験の失敗が残っています。この記事ではソースと保存済み検証記録から、通信監視の検出力を確かめる方法を整理します。

「検査を壊したら落ちるところまで確かめる」という原則は、既存の記事でも扱っています。ここでは、Blobの誤計数とCSPで遮断されたfetchという、ブラウザーの通信監視で起きた2つの場面に絞ります。

通信が0件だったという結果だけでは、監視が壊れていても同じ数字が出ます。 試作の検証では、試験用の通信を一時的に混ぜ、試験が失敗することを確認した記録を残しています。

開発・検証と本稿の構成・執筆にAIを使用しています。以下はソースと保存済み検証記録に基づく整理で、本稿のために試験を再実行したものではありません。

Blob URLにHTTPの文字があっても、HTTP通信とは数えません

試作は静的ファイルを読み込んで起動し、CSV解析や比較をWorkerで行います。ファイル選択後に、実際のHTTP通信が増えていないことを確認したい設計です。

ところが、監視記録にはblob:で始まるWorkerの読込が現れました。Blob URLには作成元のoriginが含まれます。blob:の後ろにHTTPの文字があっても、それだけでサーバーへ通信したとは言えません。Blob URLはメモリ内のリソースをURLとして扱う仕組みです。MDNのBlob URL説明

この試作が生成した同じoriginのBlobだけを別集計にしました。HTTP・HTTPSや想定外のURLは、引き続き失敗の対象です。判定の考え方だけ取り出すと、次のようになります。

function classify(raw: string, appOrigin: string) {
  const url = new URL(raw);
  if (url.protocol === "blob:" && url.origin === appOrigin) {
    return "local-blob";
  }
  if (url.protocol === "http:" || url.protocol === "https:") {
    return "http";
  }
  return "unexpected";
}

blob:を一律に除外するのではなく、試作が作るものの範囲を決めます。URL分類は通信観測の一部で、これだけで安全性を判定するものではありません。

CSPが止めても、送ろうとした呼出しを数えます

もう1つ、通信の成功だけを数えると、CSPに遮断された呼出しを見落とします。connect-srcはfetch、XHR、WebSocketなどの接続先を制限します。MDNのconnect-src説明

この試作で確かめたいのは、CSV選択後のHTTP通信が0件であることと、通信・保存APIの試行が0件であることです。そこで、ブラウザーのrequest監視に加え、API呼出しとCSP違反を観測しました。初期の静的ファイル取得は別の区間に分けます。

requestの観測にはPlaywrightのBrowserContextイベントを使いました。Playwright公式ドキュメント

一時的なfetchを混ぜた版は、試験が失敗しました

検出力の確認では、一時的なfetch('/privacy-probe', ...)を比較処理に混ぜました。送信内容は検証用の架空固定文字列だけです。検証環境のローカルサーバー宛てとし、実データや外部サーバーを使っていません。

CSPが呼出しを遮断しました。それでも監視記録にはfetchの試行とCSP違反が残り、0件を求める試験は失敗しました。遮断されただけで成功にする試験になっていないことを確認できました。

一時コードを除去し、production buildを作り直した後の保存済み記録は次のとおりです。

観測項目 件数
初期のHTTP取得 4
CSV選択後のHTTP通信 0
同じoriginのローカルBlob読込 8
通信・保存API試行 0

対象はCSV選択、比較、確認票保存、設定変更、停止、再実行、resetです。試験用コードを混ぜた版の失敗と、除去した版の成功を別々に記録しました。

1つの変異で、すべての経路を証明したことにはしません

この確認で分かったのは、今回混ぜたfetchを監視が検出したことです。全APIや、Worker初期化直後の呼出しまで同じように検出できるとは証明していません。フックを置くタイミングや到達範囲を含め、検出力の確認を増やす余地があります。

結果は架空データを使ったChromeの検証記録です。ブラウザー拡張、OS、ブラウザー内部の安全消去まで保証するものではありません。

通信をしないという条件を試験にするなら、成功件数と一緒に、その監視を失敗させた証拠も残します。

0
0
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?