HARファイルサニタイザー

概要

HAR ファイルはブラウザ自身が記録したページ読み込みの記録で、DevTools から 書き出せます。「自分の環境では再現しない」不具合の報告に添付できるものとして これ以上有用な資料はありませんが、同時に、公開の issue に貼って最も危険な ものでもあります。ログイン済みセッションのキャプチャには、セッション Cookie、 Authorization ヘッダ、たまたま通信中だった OAuth の認可コード、送信した すべてのフォーム、サーバーが返したすべてのレスポンス本文が入っています。

このツールは、構造を保ったまま秘密だけを落とすようにキャプチャを書き換えます。 リクエスト一覧・メソッド・ステータスコード・ヘッダ名・タイミング・サイズ、 つまりメンテナが問題を推論するのに必要なものはすべて残り、アカウントを 危険に晒す値だけが [REDACTED] に置き換わります。

使い方

1. DevTools の Network タブでリクエスト一覧を右クリックし、Save all as HAR を選びます。
2. その JSON をここに貼ります（ファイルを開いて中身を貼っても同じです）。
3. 伏せられたフィールド数を確認し、出力にざっと目を通します。
4. Download で sanitized.har を保存し、元のファイルではなくそちらを添付します。

削除されるもの

HAR は同じ秘密を複数の場所に持つため、そのすべてを消す必要があります。 1 つ取りこぼすことが、ここで最も問題になる失敗です。サニタイズされたように 見えるファイルは、明らかにされていないファイルより危険です。何も疑わずに 添付してしまうからです。

• ヘッダ — Cookie、Set-Cookie、Authorization、および名前に token / secret / credential / session / api-key を含むもの。 Location も対象です。OAuth コールバック後のリダイレクトは URL に 認可コードを載せて運ぶためです。
• 分解済み Cookie 配列 — HAR は Cookie を二重に記録します。生のヘッダ行と、 name/value に分解された cookies[] 配列です。この配列の値は名前を問わず すべて消します。Cookie 名は用途を表さないためです（実際の運用では s・_sess・SID がいずれもセッション Cookie です）。
• リクエスト本文 — postData.text と分解済みの postData.params[] の 両方を、フィールド名を見ずに消します。ログインフォームの項目名は pass・ otp・cvv かもしれず、キーワードリストに書き出せるものではありません。
• レスポンス本文 — 全削除します。意図しない開示の最大の発生源です。 /api/me の JSON レスポンスにはユーザーレコードが丸ごと入っています。
• リダイレクト先と WebSocket フレーム — response.redirectURL と Chrome の _webSocketMessages。後者の最初のフレームは認証のハンドシェイクであることが 非常に多いです。
• サーバー IP と呼び出し元 — serverIPAddress は内部のアドレッシングを 露出させ、Chrome の _initiator はリクエストを発生させたスクリプトの URL をクエリ文字列付きで保持します。
• クエリパラメータ — 資格情報に見える名前のもの（token・api_key・ AWSAccessKeyId・signature・code・state・sid、および key・ secret・password を含むもの）。page や lang のような非機密の パラメータは URL が読めるように残します。
• ページタイトルとリファラ — ページタイトルは URL そのものであることが 多く、OAuth コールバック後の Referer は認可コードを運びます。

意図的に残すもの

雑なキーワードフィルタなら引っかかるものの、消すと共有した理由そのものが 失われるため、2 種類は手を付けません。

• CORS のレスポンスヘッダ — Access-Control-Allow-Origin などに秘密は 含まれず、そもそも CORS の不具合は HAR を共有する最も一般的な理由の 1 つです。 問いの答えを伏せてしまえば、そのキャプチャは無意味になります。
• 認証チャレンジ — WWW-Authenticate と Proxy-Authenticate は、サーバーが どの方式を要求しているかを示します。これはヒントであって資格情報では ありません。

このツールでは消せないもの

名前による判定には原理的な限界があり、公開の issue に添付する前にその位置を 知っておく価値があります。

• URL のパスに入った秘密 — /reset/9f3c… や /invite/abc123 は、ルーティングを 知らなければ /users/42 と区別できません。パスセグメントはそのまま残します。 消せばリクエスト一覧が壊れるためです。
• 無害な名前のカスタムヘッダに入ったトークン — X-Client-Id という名前で 署名済みの値を運んでいれば、どのキーワードにも一致しません。共有前に自分の ヘッダ名を確認してください。
• 非機密パラメータに入った個人情報 — ?email= のメールアドレスは残ります。 email はフィールド名であって資格情報ではないためです。これが問題かどうかは 送る相手によります。
• URL そのもの — 内部ホスト名、ステージング環境のドメイン、API のパスは すべて保持され、それらを合わせると構成が見えます。

実用的な線引きとしては、このツールはキャプチャを「ベンダーのチケットや自社の issue トラッカーに添付できる」状態にします。「インターネットに公開しても 安全」は、ファイルを読んで判断する別の問題として扱ってください。

注意事項

値は削除ではなく置換なので JSON の形は変わらず、どの HAR ビューアでも結果を 開けます。例外は content.encoding で、レスポンス本文を置き換えたときに、 元のバイト列を説明していた base64 の宣言を削除します。[REDACTED] は base64 ではなく、厳格なビューアはそこで失敗するためです。

カウンタは「見つかった秘密の数」ではなく「消去または削除したフィールド数」を 報告します。Cookie を持たない静的サイトのキャプチャでも数が大きくなり得ます。 レスポンス本文がすべて数に入るからです。

HAR でない入力は素通しせず拒否します。以前のこのツールは任意の JSON を受け入れ、 エントリを 0 件処理して「0 sensitive values redacted」を成功として表示し、 元のファイルをそのまま「問題なし」として返していました。ここでは「安全になったと 告げること」が製品そのものなので、log.entries を持たない入力は受け付けません。

共有ではなく読むことが目的なら、HAR ビューア を使ってください。 画面上では秘密を伏せますがファイルは書き換えません。どちらにしても端末から 何も出ない点は同じです。