はじめに
Fieldwork Studio の会員は、予約したワークショップを確認し、予約確認書をダウンロードできます。チームは Sign out this browser を追加しました。サインインページに戻ると確かにサインアウトできたように見えますが、それだけでは、以前に取得したセッションがまだ使えるかどうかは分かりません。
Kali の Burp Suite Community Edition を HTTP プロキシおよび Repeater として使い、元のリクエストを保持して、サインアウト後に両方の保護されたリソースをテストします。提出物は、非公開のリクエスト・レスポンス証拠と、パスワードを含まない短い受け入れ判断です。アプリケーションを評価するのであり、サーバーを修復するわけではありません。
前提とするのは、基本的なターミナル入力とタブの切り替えだけです。この実験で HTTP レスポンス、cookie、Burp の操作を紹介します。すべての識別情報と予約は合成されたもので、用意された環境は隔離されています。指定された自分のアカウントと、このコースの対象だけを使ってください。読解と通常の入力ミスへの対応を含め、約65分を見込んでください。これは作者による見積もりであり、初学者の試行を計測した値ではありません。
実際の会員予約で通常の利用を確認する
このステップでは、サインアウトをテストする前に、通常の利用を確認します。Kali のターミナルである Auditor を開いてください。開始ディレクトリは /home/labex/project です。cat はテキストファイルを表示します。用意された認可範囲、識別情報、サービスアドレスを読みます。
cat scope.json
ベース URL は http://members.test:8080/autumn です。ユーザー名 morgan とパスワード PaperDay!47 を使ってください。会員は Morgan Reed で、Printmaking の座席 P12 を予約しています。感嘆符もパスワードの一部です。ブラウザーのフォームに入力してください。他の識別情報や外部サイトをテストしたり、対象のデータ、コード、プロセスを変更したりしてはいけません。
GUI のワークスペースに Disconnected と表示された場合は、上部の Reconnect ボタンをクリックしてください。既存のウィンドウに再接続し、ブラウザーの cookie、Burp のリクエスト、対象での進行状況を維持します。
Burp を開きます。Burp Community はインストール済みです。起動ウィザードで Temporary project を選択したまま Next をクリックします。Use Burp defaults を選択したまま、Start Burp をクリックします。Burp Suite is out of date が表示されたら、OK をクリックして、準備済みのトレーニング用バージョンで続けます。メインウィンドウが開くまで待ってください。一時プロジェクトは稼働中のワークスペースをメモリー内に保持します。このコースでは、有料のディスクプロジェクト機能ではなく、明示的な XML エクスポートを証拠ファイルに使います。
Burp はプロキシです。準備済みのブラウザーは Burp を経由して HTTP リクエストを送るため、実際のやり取りを調べられます。Burp でメインタブの Proxy、サブタブの Intercept を選択します。ボタンには Intercept is off と表示されている必要があります。Intercept is on の場合は1回クリックしてください。インターセプトが有効だとリクエストが一時停止します。ここでは、履歴を記録しながらリクエストを通常どおり通過させます。
LabEx の Browser A タブに切り替えます。これは Burp と同じ監査用コンテナー内にある、準備済みの Chromium ブラウザーです。アドレスバーをクリックし、以下の URL を入力して Enter キーを押してください。
http://members.test:8080/autumn/
公開ワークショップページを読み、View my booking を選択します。Username と Password に指定の認証情報を入力し、Sign in をクリックします。Chromium がパスワードの保存を提案したら、Never を選択してください。Your next day of making に移動し、Morgan Reed、Printmaking、座席 P12 が表示されるはずです。
Download booking をクリックします。実際の fieldwork-booking.csv には、会員、ワークショップ、座席が含まれています。Chromium の下部のダウンロードバーにダウンロードしたファイルが表示され、Show all でダウンロード一覧が開きます。公開ワークショップの閲覧、自分の予約の表示、このダウンロードが、維持すべき通常の機能です。
ダウンロードする前に、予約カードの会員、ワークショップ、座席を確認してください。
パスワードが誤っていると、Sign-in unsuccessful と try again リンクが表示されます。このリンクを開き、指定された値を再入力してください。Page not found レスポンスはパスの誤りを意味します。上記の正確なベース URL に戻ってください。ブラウザーの接続エラーは、アプリケーションのレスポンスが得られなかったことを意味します。URL を確認し、Burp のウィザードを完了させ、インターセプトが無効であることを確認してください。接続失敗をセキュリティ上の拒否として扱ってはいけません。
Browser B は次の実験で使う独立したブラウザープロファイルです。ここでは使わないでください。2つのブラウザータブと Burp は、1つの監査用コンテナー内のウィンドウであり、別々の仮想マシンではありません。LabEx のタブを切り替えても、対象や作業はリセットされません。
元のリクエストを Repeater に保持する
このステップでは、すでに成功したリクエストを保持します。Burp に切り替え、Proxy、HTTP history の順に選択します。members.test:8080 の /autumn/account への GET リクエストを探してください。リクエストはブラウザーが送るもので、レスポンスはサーバーが返すものです。GET はリソースを読み取ります。HTTP の 200 OK は、このリクエストに対して成功のレスポンスが返ったことを意味します。
アカウントの行をクリックします。そのリクエストエディターで Raw を選択し、Cookie ヘッダーを探します。サインインによって studio_session という名前のセッション cookie が発行されました。ブラウザーは、認証済みのセッションを識別するためにこの値を送信します。古い cookie を持っていることが、ここでテストする条件です。ブラウザーの cookie を消し、cookie のない新しいリクエストを試すと、別の問いを調べることになります。
アカウントの行を右クリックし、Send to Repeater を選択します。Repeater では、保持したリクエストを再送信し、新しいレスポンスを調べられます。次に /autumn/booking.csv への GET リクエストを探し、右クリックして Send to Repeater を選択します。履歴フィルターによって CSV リクエストが隠れている場合は、表の上のフィルターバーをクリックして Show all を有効にし、フィルターダイアログを閉じて正確なパスを探し直します。行の位置だけでなく、ホストとパスを使って特定してください。
メインタブの Repeater を選択します。送信した順番で、最初の番号付きリクエストタブ 1 がアカウントリクエスト、2 が予約リクエストです。1 で、対象が http://members.test:8080、リクエスト行が GET /autumn/account HTTP/1.1 であり、元の studio_session cookie が残っていることを確認します。Send をクリックします。レスポンスペインで Raw を選び、HTTP/1.0 200 OK と予約ページの内容を読みます。
2 を選択して Send をクリックします。200 OK、text/csv コンテンツタイプ、実際の予約の行が返るはずです。サーバーの HTTP バージョンはリクエストのものと異なる場合があります。重要なのはステータスと、実際の会員予約の内容です。
保持した両方のリクエストで、同じセッション cookie を使う必要があります。レポートにコピーせず、Burp 内で値を比較してください。サインアウトの間も、この2つの Repeater リクエストは変更しません。cookie の削除や置き換え、対象の置き換え、これらのタブでのサインアウトリクエストの送信はしないでください。成功した基準状態があることで、後の比較が意味を持ちます。
誤った履歴の行を送信した場合は、その Repeater リクエストタブだけを閉じ、正しい行を送信します。正しいリクエストはパスで識別してください。その場合、タブ番号は異なることがあります。リクエストタブを閉じることは、Burp を閉じることや VM をリセットすることとは異なります。
サインアウト後に古い cookie をテストする
このステップでは、ブラウザー上で見えるサインアウトと、サーバー側のセッション無効化を区別します。Browser A に切り替えます。予約ページで Sign out this browser をクリックします。ブラウザーはサインインページの Welcome back に戻ります。
このページの変化だけでは、サーバーが古い cookie を受け入れなくなったとは証明できません。Burp に切り替え、Repeater を開き、元のアカウントリクエストを選択して Send をもう一度クリックします。cookie は変更しないでください。200 OK と Morgan Reed の予約内容が返るはずです。古いセッションは、サインアウト後もアカウントへのアクセスを許可しています。
元の予約リクエストを選択し、Send をもう一度クリックします。200 OK、text/csv、同じ会員の予約の行が返るはずです。これは、古い cookie によって得られた、実際に成功したダウンロードのレスポンスです。成功したように見えるブラウザーページや、サインインフォームだけを含む HTTP 200 では、その事実を裏付けられません。
現在のブラウザーからのサインアウトが正しく動作するなら、保持した両方の保護されたリクエストは、アプリケーションがそのセッションを拒否したことを意味する 401 Unauthorized を受け取るはずです。ここでは、サーバーが両方のリソースでまだ受け入れています。観察した証拠に基づいて、サインアウトの変更を不合格と判断してください。実証したのは、この特定のセッションの不具合であり、アプリケーションにあり得るすべての弱点ではありません。
通常の利用が引き続き可能なことを確認します。Browser A に切り替え、morgan と PaperDay!47 でもう一度サインインし、予約を表示して Download booking をクリックします。これにより新しいセッションが発行され、通常の会員の操作が引き続き機能することを確認できます。元の2つの Repeater リクエストの cookie を置き換えずに、Burp に戻ってください。これらの最新のレスポンスは、次にエクスポートするサインアウト後のレスポンスのままでなければなりません。
左の Request ペインの変更されていない Cookie と、右の Response ペインの 200 OK および実際の会員の行を比較してください。成功のステータスだけでは、この予約へのアクセスを証明できません。
誤って元の cookie を上書きしたり、保持した両方のリクエストを閉じたりした場合は、完全なテストをやり直します。新しい正常なセッションで両方のリソースのリクエストを取得して保持し、そのセッションをサインアウトしてから、それらの正確なリクエストを再送信します。新たにサインインして得た cookie は、サインアウトしたセッションの cookie の代わりにはなりません。
非公開の証拠と明確な判断を提出する
このステップでは、認証情報を評価に含めずに、実際の HTTP 証拠を保存します。Auditor に切り替えてください。リクエスト・レスポンス証拠には使用可能なセッション cookie が含まれるため、保存前にアクセスを制限します。
umask 077 は、新しく作成するファイルとディレクトリを自分のユーザーだけが利用できるようにします。適用されるのはこのターミナルセッションであり、今後のすべてのシェルではありません。mkdir -p は必要に応じて指定のディレクトリを作成します。chmod 700 は所有者に読み取り、書き込み、ディレクトリ内へのアクセスを許可し、グループとその他のユーザーにはアクセスを許可しません。
umask 077
mkdir -p evidence
chmod 700 evidence
Burp に切り替え、Repeater で元のアカウントリクエストを選択します。現在のレスポンスが、サインアウト後の 200 OK の予約ページであることを確認します。Request エディター内を右クリックし、Save item を選択します。これはリクエストとレスポンスをまとめて保存します。Copy to file では異なる内容が保存されます。
Select a file ダイアログの File Name に、次の絶対パスを入力します。
/home/labex/project/evidence/account-after.xml
下部付近の File Name フィールドを使ってください。その下に、チェック済みの Base64 オプションがあります。
Base64-encode requests and responses をチェックしたまま Save をクリックします。Base64 は元のバイト列を XML 内で安全に表現しますが、cookie を暗号化するものではありません。成功通知が表示された場合は OK で閉じてください。元の予約リクエストでも Save item を繰り返し、次のパスを使います。
/home/labex/project/evidence/booking-after.xml
Auditor に切り替えます。chmod 600 は各ファイルの読み書きを所有者だけに許可します。ls -l は権限を表示します。両方の XML ファイルで -rw------- となるはずです。
chmod 600 evidence/account-after.xml evidence/booking-after.xml
ls -l evidence
以下のパスワードを含まない評価を書きます。> は指定したファイルを置き換えます。<<'JSON' はヒアドキュメントを開始し、シェルは、単独の終了行 JSON までのテキストをそのままコピーします。数値のステータス値は引用符で囲まず、JSON の true は真偽値です。このレポートに cookie、パスワード、生のリクエストを含めないでください。
cat > assessment.json <<'JSON'
{
"decision": "reject",
"account_after_logout": 200,
"booking_after_logout": 200,
"fresh_sign_in_works": true
}
JSON
通常の入力ミスを見つけるため、評価を読み直します。
cat assessment.json
提出物は、非公開の2つの XML 項目とこの評価です。XML 項目は元の cookie を持つリクエストと実際のレスポンスを保持し、レポートは秘密情報を繰り返さずに、証拠で裏付けられた判断を伝えます。検証は、これらの関係を既存のサーバー上の事実と照合します。不足しているログイン、サインアウト、再送信の通信を代わりに生成することはなく、ファイルも変更しません。通常の公開ページの維持確認リクエストによって、アクセス記録が追加される場合があります。
ファイル名が誤っている場合は、指定された絶対パスに Save item を再実行し、chmod 600 をもう一度適用します。ディレクトリを変更していた場合は、pwd で現在のディレクトリを確認し、cd /home/labex/project でワークスペースに戻ります。不足している証拠を、手書きの成功行やスクリーンショットで置き換えてはいけません。
まとめ
実際の予約で基準状態を確認し、元の cookie を持つ2つのリクエストを Burp Repeater に保持し、サインアウト後もサーバーが両方のリクエストを受け入れることを実証しました。ブラウザーがサインインページに戻るだけでは、セッション無効化の証明にはなりませんでした。通常の操作を維持し、非公開の HTTP 証拠と、パスワードを含まない不合格判断を提出しました。
次の実験では、修正済みのデプロイ先を調べます。独立したブラウザーを使うことで、現在のセッションを終了することと、同じ会員のすべてのセッションを不必要に終了することを区別します。
