秘密を暴露せずに電子メールテストの証拠を保存する方法
Once Email 編集部レビュー Once Email 日本語編集レビュー
記事ガイド
この記事を読む価値
- 独自分析
- 当社は欠陥の質問から逆算して、収集した証拠を最小限に抑え、複製に必要な証拠を秘密や無関係な個人データから分離します。
- トレンドの背景
- クラウドの問題トラッカーと分散チームにより、証拠の共有が容易になり、撤回が難しくなり、取り消し、トリミング、合成サンプルの価値が高まります。
- 実用的な価値
- 読者は、診断をサポートしないライブ認証情報、識別子、コンテキストを削除しながら、有用なスクリーンショット、ヘッダー、バグ レポートを作成できます。
このページの内容
スクリーンショットは、電子メールが正しくレンダリングされていないことを証明できますが、有効なリセット リンクを公開することもできます。コピーされたヘッダーは、アドレス、メッセージ ID、内部ホスト、またはテスト相関値を公開しながら配信パスを説明できます。優れた証拠とは、欠陥を再現するために必要な事実を保存し、その事実を裏付けるもの以外のものをすべて削除するものです。
検証コード、マジック リンク、パスワード リセット URL は、有効である限り資格情報として扱います。編集は、有効期限や取り消しの代わりにはなりません。実際の秘密がすでに共有されている場合は、最初にそれを無効にするかローテーションします。 リポジトリから機密データを削除する に関する GitHub の公式ガイダンスも同様に、リポジトリのクリーンアップを試みる前に、公開されたパスワード、トークン、または資格情報を取り消すかローテーションすることを推奨しています。
証拠が答えなければならない質問から始めます
何かを収集する前に一文を書いてください: 「この証拠は、…を示すはずです。」 例には、「モバイルの件名行がタイムスタンプと重なっている」、「リセット メッセージが規定の有効期間後に到着した」、「リンクがステージング ホストを指している」などがあります。
その文は収集を制限します。レイアウトに欠陥がある場合は、生のメッセージではなく、切り取られたスクリーンショットとビューポート幅が必要になる場合があります。配信遅延の欠陥には、メッセージ本文ではなく、UTC タイムスタンプと匿名化された相関値が必要な場合があります。ヘッダー解析の欠陥には、顧客の元のメッセージではなく、小さな合成ヘッダー サンプルが必要になる場合があります。
専用のテスト アカウントと架空のデータを使用して作成された証拠を優先します。実際の顧客の受信箱は、すでに問題が示されているという理由だけで使用しないでください。
何を削除するかを理解する
表示されているデータと非表示のデータの両方を確認します。一般的な機密要素には次のようなものがあります。
- 完全な送信者アドレスと受信者アドレス。
- 確認コード、ワンタイムパスワード、マジックリンク;
- クエリ文字列とフラグメントを含むすべてのリセット URL。
- パスワード、API キー、Cookie、認証フィールド、およびセッション識別子。
Message-ID、プロバイダーキュー ID およびアプリケーション相関 ID。- 内部ホスト名、プライベート IP アドレス、および非パブリック環境の URL。
- 名前、電話番号、場所、注文の詳細、および無関係なメッセージの内容。
- スクリーンショットの周囲にキャプチャされたブラウザーのタブ、ブックマーク、通知、およびデスクトップのファイル名。
- 収集ツールが保存する場合の画像メタデータ。
RFC 5322 は、メッセージの特定のバージョンに対する一意の機械可読識別子として Message-ID を定義しています。これはログの相関関係を制御するのに役立ちますが、公開レポートには通常、元の値ではなく安定したプレースホルダーが必要となるのも一意性のためです。
ボタンの後ろに URL を忘れないでください。スクリーンショットでは宛先が非表示になる場合がありますが、コピーされた HTML またはホバー ツールチップでは完全なトークンが表示されます。逆に、画像内の表示テキストをペイントしても、基礎となる HTML、PDF レイヤー、問題の説明、添付ファイル名から秘密は削除されません。
最小の安全な証拠形式を選択する
視覚的な位置、折り返し、コントラスト、または応答性の高いレイアウトには、切り取られたスクリーンショットを使用します。正確な文字または解析を行うには、短いテキストの抜粋を使用します。納期遅延については構造化されたタイムラインを使用してください。再現可能なパーサー テストには合成メッセージを使用します。
3 行で欠陥が証明されている場合は、メールボックス全体のエクスポートを添付しないでください。デフォルトでは、生の .eml ファイルを広範囲に表示される問題トラッカーにアップロードしないでください。これらのファイルには、本文全体、すべてのヘッダー フィールド、リモート リソースの URL、および添付ファイルが含まれる可能性があります。
Once Email は受信したメッセージを表示しますが、証拠のエクスポートや編集の保証は提供しません。その 電子メール ヘッダー アナライザー は、貼り付けられたヘッダー テキストをブラウザーでローカルに処理し、フィールドの識別に役立ちますが、何を共有できるかを決定するのはユーザーの責任です。
スクリーンショットを安全に編集する
コピーを作成し、編集されていないオリジナルは承認されたアクセス制御された場所にのみ保管してください。まず、関連するコンポーネントを切り取ります。次に、敏感な領域を不透明なブロックに置き換えます。ぼかし、ピクセル化、半透明のハイライト、または編集可能なコンテンツ上に移動可能な形状を配置することに依存しないでください。
編集された結果を平坦化された画像としてエクスポートします。エクスポートされたファイルを再度開き、ズームインして、レイヤーを非表示にしたり、テキストをコピーしたり、コントラストを高めたりしてもシークレットが復元できないことを確認します。画像の端と周囲のブラウザーのクロムのアドレス、タブ、通知を確認してください。
コンテキストが重要な場合は、意味のあるプレースホルダーを使用します。
[TEST_RECIPIENT]
[VERIFICATION_CODE_REMOVED]
https://staging.example/reset?[TOKEN_REMOVED]
Message-ID: <[MESSAGE_ID_REMOVED]>
2 つの値の一致が必要であることを示す場合にのみ、繰り返し出現する同じプレースホルダーを保持します。それ以外の場合は、読者が無関係なレポートを関連付けることができる安定した仮名を作成することは避けてください。
バグを破壊せずにヘッダーとリンクを編集します
最小限の関連フィールドを新しいテキスト ファイルにコピーします。機密性の高い値を置き換えます。唯一のオリジナルの証拠を編集しないでください。欠陥が解析に関するものである場合は、フィールド名、折りたたみ、区切り文字を保持します。
配送順序の問題では、ホスト、アドレス、キュー ID を置き換える際に、匿名化されたサンプルに Received タイムスタンプが保持される可能性があります。認証表示の問題の場合は、spf=pass などの結果キーワードを保持し、ドメインを sender.example などの予約された例に置き換えます。レポート内のすべての置換について説明します。
リセット URL で間違ったホスト名が示された場合は、スキームとサニタイズされたホストのみを保持し、コンポーネントに問題がない限り、完全なパス、クエリ、およびフラグメントを置き換えます。部分的な実際のトークンは絶対に保存しないでください。シークレット形式にはアカウント識別子が含まれていたり、数文字だけが非表示になった後も使用可能な状態になったりすることがあります。
公開報告書を制限された証拠から分離する
主要な問題には、再現可能な手順、期待される結果、実際の結果、環境、構築およびサニタイズされた証拠が含まれている必要があります。承認されたセキュリティまたはプライバシーのレビュー担当者がオリジナルを本当に必要とする場合は、そのオリジナルを所有者と削除日を付けて組織の承認された制限付きチャネルに置きます。チャットに気軽に添付しないでください。
制限付きコピーに誰がアクセスできるのか、およびその理由を記録します。調査が終了するか、保存期間が終了したら削除してください。一時的な検証メッセージの長期間のアーカイブは、クローズされた欠陥を改善することなくリスクを生み出します。
アップロード前に確認してください
2 パス レビューを使用します。まず、レポーターは、表示されるすべての値、リンク ターゲット、ファイル名、およびメタデータ フィールドをチェックします。次に、別の権限のある人が、エクスポートされたアーティファクトを受信者が見るのと同じようにチェックします。編集可能なソースではなく、アップロードされる正確なファイルを開きます。
次のことを確認します。
- 有効なコード、リンク、Cookie、または認証情報が残らない。
- 厳密に必要で承認されない限り、住所と個人データは削除されます。
- 識別子はプレースホルダーであるか、制限されたチャネルにのみ保存されます。
- 証拠は、記載された実際の結果を依然として証明しています。
- 再現手順ではテストデータと許可された環境を使用します。
- 問題の可視性が残りの機密性と一致します。
- 制限されたオリジナルについては、保持または削除の決定が存在します。
シークレットがすでに公開されている場合
リンクの共有を停止し、システム所有者に連絡してください。資格情報を期限切れにするかローテーションし、必要に応じて影響を受けるセッションを無効にし、レポートを制限し、リポジトリまたは発行システムのクリーンアップ手順に従います。最新のスクリーンショットやコミットを削除しても、キャッシュされたコピー、通知、フォーク、履歴は削除されない場合があります。
封じ込め後、アーティファクトを検証済みの編集済みバージョンに置き換え、組織のインシデントプロセスを通じて暴露を文書化します。目的は歴史をきれいに見せることではありません。それは、シークレットを使用不能にし、アクセスを制限し、根本的な欠陥を修正するのに十分な安全な証拠を保存することです。
この証拠を作成する完全な機能ワークフローについては、開発者電子メール テスト チェックリスト ] を使用してください。 2 つのプラクティスを組み合わせることで、レポートが 2 番目のセキュリティ インシデントに発展することなく、メール フローの欠陥を再現可能に保つことができます。