その HAR ファイルを送る前に、中身を読んでください

「HAR ファイルを送っていただけますか?」は妥当な依頼です — そして日常のサポート業務で最も何気なく危険なファイルの受け渡しの 1 つでもあります。HAR ファイルはブラウザセッションの完全な記録です:すべてのリクエストとレスポンスを、それらを機能させた Cookie、認可ヘッダー、トークン、フォームの内容とともに記録します。それはサポートエンジニアがあなたの問題を再現するために必要なものそのものであり、攻撃者があなたのセッションを再生するために欲しがるものそのものでもあります。この記事では、HAR ファイルとは何か、Chrome、Edge、Firefox でキャプチャする方法、何が漏れるのか、そしてどこへ送る前に検査して墨消しする方法を説明します。

HAR ファイルとは

HAR — HTTP アーカイブ — は HTTP トラフィックを記録するための JSON 形式で、HAR 1.2 仕様で標準化され、すべての主要ブラウザの開発者ツールと mitmproxy のようなデバッグプロキシからエクスポートされます。ファイルは entries 配列を持つ log オブジェクトを含みます:リクエストごとに 1 エントリで、それぞれにメソッドと完全な URL、リクエストとレスポンスのヘッダー、双方向の Cookie、パラメータに分解されたクエリ文字列、あらゆる POST ボディ、レスポンスのステータス、サイズ、コンテンツタイプ、そしてフェーズごとに分解された時間 — DNS、接続、TLS、送信、待機、受信 — が入っています。

言い換えれば、それは問題のスクリーンショットではありません;それは問題そのものであり、再生可能です。HTTP トラフィックを扱うあらゆるものがこの形式で動作します — ブラウザツール、パフォーマンスアナライザー、サポートエンジニア、そしてますますエージェントも:AI エージェントはあなたのアプリをリバースエンジニアリングできるか? で扱った REA スタックは HAR キャプチャをネイティブに読みます。多くのアプリでは API トラフィックがコード以上に説明するからです。その有用性こそ、このファイルが送信に値する前に一読に値する理由です。

サポートチームとベンダーが求める理由

議論に終止符を打つからです。「ページが遅い」は、名前付きのリクエストと時間を持つウォーターフォールになります。「API が失敗する」は、正確なペイロードと正確なヘッダーとともに 500 を返した正確なリクエストになります。「私のマシンでは動く」は重要でなくなります。記録はあなたのマシン、ネットワーク、アカウントから、壊れたその瞬間に得られたものだからです。優れたサポートエンジニアは、1 つの正直な HAR ファイルで、1 週間分のスクリーンショットや記憶以上のことができます。

だからこそこの依頼は、考えもなしに転送されがちでもあります。チケットには「HAR を添付してください」とあり、ユーザーは 30 秒で 1 つエクスポートし、そのファイル — ログインして実際の作業をしている間に記録されたもの — は旅を始めます:チケットシステムへ、メールスレッドへ、時には公開フォーラムや共有ドライブへ、移動のたびにコピーを蓄積しながら。この連鎖の中で誰も正確に不注意なわけではありません;形式がその内容を隠しているだけです。.har ファイルは不活性な診断データに見えます。実態は鍵束に近いのです。

Chrome、Edge、Firefox でキャプチャする方法

Chrome または Edge では:ページを開き、F12 で DevTools を開いてネットワークパネルへ移動します(Chrome DevTools のネットワークリファレンスがすべてのコントロールを文書化しています)。赤い録画ボタンがオンになっていることを確認し、問題がナビゲーションにまたがる場合はログを保持にチェックします。問題を最初から最後まで 1 回再現します。その後、リスト内の任意のリクエストを右クリックしてすべて HAR(コンテンツ付き)として保存を選択します(Edge ではネットワークログの保存と表現されます)。Firefox では流れは同じ形です:DevTools → ネットワーク、再現、右クリック → すべて HAR として保存。

2 つのキャプチャ習慣は、どの設定よりも重要です。第一に、問題を示す最も短いセッションを記録すること:余分なブラウジングの 1 分ごとに、ファイル内の余分なトラフィック — そして余分な秘密 — が増え、他のタブやバックグラウンドリクエストが当時していたことも含まれます。第二に、可能なら、新しいブラウザプロファイルやプライベートウィンドウで、問題のサービスにだけサインインして問題を再現すること。クリーンなプロファイルからのキャプチャにはその 1 セッションだけが含まれ、他は何も含まれません:銀行のタブも、ウェブメールも、他のアプリのトークンの混入もありません。

何が漏れるのか

まず、あなたのセッションです。Cookie ヘッダーと Set-Cookie ヘッダー、そして Cookie リストにはセッション識別子が入っており、ほとんどのセッション Cookie は最も素朴な意味でのベアラー認証情報です:それを提示した者は、失効するか取り消されるまであなたとして扱われます。Authorization ヘッダーはベアラートークン、そして時には Basic 認証情報を追加します。形式の中では何もこれらの値を特別とマークしません;それらはただのヘッダーであり、忠実に記録されます。

次に、誰もヘッダーだと思わないもの。トークンは常に URL に紛れています — API キー、パスワードリセットやメール確認のリンク、署名付きダウンロード URL、OAuth コールバック — そして HAR は完全な URL に加え、読みやすく分解されたクエリ文字列を記録します。POST ボディはフォームが運んだものを運びます:キャプチャ中にログインしたパスワード、プロファイルの編集、メッセージ、個人データ。レスポンスボディは同じ種類のデータを返すことがあります。実際のセッションの HAR ファイルは、実質的にあなたのアカウントの部分的な記録です — だからこそ、ネットワーク上でトラフィックを読む PCAP Analyzer のようなツールと、ブラウザでそれを読むこのページのようなツールは、あなたが何を持っているか分かるように認証情報をはっきり表示するよう作られているのです。

送る前に検査して墨消しする

だから:他の誰よりも先にファイルを開いてください。そのためのものが、このサイトの HAR File Analyzer です — .har をページにドロップすると、ローカルで、あなたのデバイス上で解析され、決してアップロードされず、機密値はデフォルトでマスクされます:Authorization、Cookie、Set-Cookie ヘッダー、すべての Cookie 値、そして名前がトークン、キー、秘密、セッション、パスワードのように見えるヘッダー、クエリパラメータ、フォームフィールド、JSON キー。要約と最も遅く最も大きいリクエストをざっと確認し、どのホストが現れるかを確認してください — キャプチャには、あなたが見てもいなかったサイトのトラフィックが含まれることがあります — そして、本当に何が入っているか確認する必要がある場合は、自分の画面でのみ「値を表示」トグルを使ってください。

次に墨消し済み .har をダウンロードして、代わりにそれを送ってください。墨消しはサポートエンジニアが必要とする構造 — 同じエントリ、ヘッダー、形としての URL、ステータス、時間 — を保持し、認証情報の値をリテラルテキスト REDACTED に置き換えます。ヘッダー、Cookie、クエリ文字列、フォームデータ、JSON ボディのすべてにおいて同様です。制限が 1 つツールに印字され、ここでも繰り返します:JSON でも通常のフォームデータでもない POST ボディは安全に解析できないため、そのまま引き継がれます — あなたのキャプチャにそのようなボディが含まれている場合は、ファイルが旅立つ前に自分で読んでください。マスクされた CSV 要約が存在するのも同じ理由です:エンジニアが「リクエストのリストだけ」を求めたときに添付するファイルです。

墨消しにできないこと

墨消しは鍵を取り除きます;地図は取り除きません。墨消し済み HAR は、あなたのホストとエンドポイント、パラメータ名、レスポンスの形と大きさ、呼び出しの順序と時間を依然として示します — あなたのアプリケーションの API の実用的なスケッチであり、それ自体が公開していない情報である場合があります。コピーを回収することもできません:生のファイルがチケットシステムや受信箱に入ってしまったら、あなたのコピーを墨消ししても相手のコピーは何も変わりません。墨消し済みファイルは、ベンダーが提供した非公開の経路 — 公開投稿や公開ファイルリンクではなく、チケット自体 — で共有し、チケットの中で、ケースが閉じたらファイルの削除を求めてください。評判の良いサポート組織は日常的にこれを行っています;頼むことに費用はかかりません。

そして、生の、墨消しされていない HAR がすでに漏れてしまった場合 — 間違ったアドレスに送られた、公開 Issue に添付された、共有フォルダに放置された — セッションは露出したものとして扱ってください。実際に露出しているからです:サービスからサインアウトし(通常はサーバー側でセッションが無効化されます)、再びサインインし、その中に現れた API キーをすべてローテーションしてください。これは漏洩した認証情報すべてに共通するルールであり、このサイトの他のファイルツールの細則が同一である理由です — Binary File Inspector が実行ファイルをローカルで読むのは、このページがキャプチャをローカルで読むのと同じ理由です:最も検査が必要なファイルこそ、検査のためにアップロードすべきでないファイルなのです。

出典と参考資料

よくある質問

テキストエディタで手作業で墨消しできますか?

できます — HAR ファイルは JSON で、どのテキストエディタでも開けます — しかし手作業の墨消しこそ秘密が生き残る方法です:同じトークンがヘッダー、Cookie リスト、URL 文字列、クエリパラメータに現れ、1 つのコピーを見逃すと認証情報は生きたままになります。現れるすべての場所でルールによって値を置き換える自動処理が、退屈で正しい方法です。どちらの方法でやるにしても、送信前に、完成したファイルの中から、含まれていると分かっている各秘密の断片を検索してください。

墨消し済み HAR はサポートエンジニアにとってまだ機能しますか?

はい — それがエントリを削除するのではなく値を墨消しする意味です。エンジニアはリクエストの順序、メソッド、URL の形、ヘッダー名、ステータス、サイズ、時間を保持します。それが診断が実際に使うものです;失われるのは、決して必要ではなかった有効な認証情報の値だけです。エンジニアが本当に値を見る必要がある場合は、それは明示的に行う会話であり — 通常は墨消し済みファイルで十分だと同意して終わります。

すでに生の HAR ファイルを送ってしまいました。今どうすべきですか?

その中のセッションを公開されたものとして扱ってください。サービスのすべての場所からサインアウトし(ほとんどのサービスには、キャプチャされた Cookie を無効化する「すべてのセッションからサインアウト」コントロールがあります)、再びサインインし、キャプチャに現れた API キーやトークンをすべてローテーションしてください。その後、同じチケットやスレッドで返信し、添付ファイルの削除を求めてください。2 つ目の墨消し済みファイルを送って直ったとみなさないでください — 墨消しは将来のコピーを守るもので、すでに届いたコピーは守りません。