はじめに
スタジオのチームは、Sign out this browser がセッションを扱う方法を変更しました。すべてのセッションを終了させれば古い cookie は使えなくなりますが、会員が引き続き使いたい別のブラウザーも中断してしまいます。受け入れ確認では、セキュリティ上の結果と、約束された通常の動作の両方を確認する必要があります。
Browser A の元のアカウントリクエストと予約リクエストを Burp Repeater に保持し、同じ会員の独立した Browser B セッションを確立してから、A のサインアウト後に両方をテストします。提出物では、非公開の HTTP 証拠と、パスワードを含まない受け入れ判断を組み合わせます。環境は独立しており、以前のファイル、セッション、Burp タブは引き継がれません。
先に サインアウト後に予約リクエストを再送信する を完了してください。Burp の一時プロジェクトの開始、インターセプトを無効に保つ操作、履歴の行の Repeater への送信、HTTP ステータスの読み取り、XML 項目の保存方法を理解している必要があります。この実験では操作の流れを繰り返し、独立セッションの比較を追加します。すべてのアカウントと予約は合成されています。読解と通常の入力ミスへの対応を含め、約60分を見込んでください。これは作者による見積もりです。
Browser A の通常の予約アクセスを確認する
このステップでは、新しいデプロイ先で通常の操作を確認します。Auditor を開き、指定された識別情報、アドレス、認可範囲を読みます。
cat scope.json
http://members.test:8080/autumn、ユーザー名 morgan、パスワード PaperDay!47 だけを使ってください。予約は Morgan Reed の Printmaking、座席 P12 です。用意された範囲、対象の設定、データ、プロセスを維持してください。
GUI のワークスペースに Disconnected と表示された場合は、上部の Reconnect ボタンをクリックしてください。既存のウィンドウに再接続し、ブラウザーの cookie、Burp のリクエスト、対象での進行状況を維持します。
Burp を開きます。Temporary project を選択したまま Next をクリックし、Use Burp defaults を選択したまま Start Burp をクリックします。Burp Suite is out of date が表示された場合は、OK をクリックして準備済みのトレーニング用バージョンで続けます。メインウィンドウで Proxy → Intercept を選択し、ボタンが Intercept is off と表示されていることを確認します。Intercept is on の場合は1回クリックし、通常のリクエストが一時停止しないようにします。
Browser A に切り替えます。Chromium のアドレスバーをクリックし、この URL を入力して Enter キーを押します。
http://members.test:8080/autumn/
View my booking を選択し、Username に morgan、Password に PaperDay!47 を入力して Sign in をクリックします。Chromium がパスワードの保存を提案したら Never を選択してください。Your next day of making で Morgan Reed、Printmaking、座席 P12 を確認し、Download booking をクリックします。実際の CSV には、その会員、ワークショップ、座席が含まれています。
認証情報に入力ミスがあると Sign-in unsuccessful になります。try again から指定の値を修正してください。パスが誤っている場合は、正確なベース URL に戻ります。ブラウザーの接続エラーは HTTP の拒否ではありません。Burp のウィザードを完了し、インターセプトと正確なアドレスを確認してから、もう一度移動してください。LabEx のタブを閉じても、環境はリセットされません。
Browser A の成功したリクエストを保持する
このステップでは、別のブラウザーを使い始める前に、Browser A の元のセッションを保持します。Burp に切り替え、Proxy → HTTP history に移動します。members.test:8080 の GET /autumn/account の行を探し、右クリックして Send to Repeater を選択します。GET /autumn/booking.csv でも同じ操作をします。履歴フィルターで CSV が隠れている場合は、フィルターバーを開き、Show all を有効にしてください。
メインタブの Repeater を開きます。最初のリクエストタブで、アカウントのパスと元の Cookie: studio_session=... ヘッダーを確認し、Send をクリックします。Raw レスポンスを読んでください。Morgan Reed の予約を含む HTTP 200 が返ります。2つ目のリクエストタブを選択し、Send をクリックします。実際の CSV の予約行を含む HTTP 200 が返る必要があります。
この2つのリクエストは、Browser A の同じ元のセッション cookie を使います。ホスト、パス、cookie を含め、変更せずに保持してください。Repeater の番号付きタブはリクエストを識別し、LabEx の Browser A と Browser B タブは独立したブラウザープロファイルを識別します。LabEx のタブを切り替えても、Repeater 内で選択されているリクエストは変わりません。
これらの成功したレスポンスが基準状態です。一度も使えなかった cookie では、サインアウトによって実際のセッションが後で無効化されたかどうかは判断できません。誤った履歴の行を選択した場合は、正しいパスを Repeater に送り、そのリクエストタブを使ってください。タブ番号を推測するのではなく、パスで特定します。
現在のセッションだけを終了する境界をテストする
このステップでは、1つのブラウザーをサインアウトすると、そのセッションだけが終了することを確認します。独立したブラウザープロファイルは、それぞれ独自の cookie ストレージを持ちます。Browser A 内の2つ目のタブは A の cookie を共有するため、この比較には使えません。
LabEx の Browser B タブに切り替えます。Chromium のアドレスバーで次に移動します。
http://members.test:8080/autumn/login
同じ会員の morgan と PaperDay!47 でサインインします。パスワードの保存を求められた場合は Never を選択します。予約を確認し、Download booking をクリックしてください。Browser B はサインインしたままにします。B のアカウントとダウンロードへの成功したリクエストは、A がサインアウトする前に行う必要があります。
識別情報を直接比較するため、Burp → Proxy → HTTP history に切り替えます。B の最新の /autumn/account リクエストを選択し、その Raw リクエストを調べます。studio_session の値は、A の元の Repeater タブに保持した値と異なります。どちらのセッションも Morgan Reed を表しますが、別々の認証状態です。どちらの cookie もレポートにコピーせず、A の保持した cookie を B のもので置き換えないでください。
Browser A に切り替え、Sign out this browser をクリックします。サインインページが表示されます。次に Burp → Repeater に切り替え、A の元のアカウントリクエストで Send をクリックします。401 Unauthorized と Sign in required が返るはずです。A の元の予約リクエストも送信してください。会員の予約 CSV を含まない HTTP 401 が返るはずです。両方の元の cookie をそのまま残してください。cookie のないリクエストでは、A の古いセッションの無効化をテストできません。
左ペインの変更されていない Cookie と、右ペインの 401 Unauthorized および Sign in required を読んでください。これは、以前は機能していた A のセッションに対する拒否です。
次に Browser B に切り替えます。アドレスバーの横にある Chromium の再読み込みボタンをクリックします。予約ページには、引き続き Morgan Reed の予約が表示される必要があります。Download booking をもう一度クリックし、実際にダウンロードされたことを確認してください。これらの新しいリクエストが、アクセスの継続を裏付けます。再読み込みせず画面に残しただけのページは、古い表示かもしれません。B もアクセスを失った場合、A の古い cookie が拒否されていても、すべてのセッションの終了は、このコースで明示された this browser の契約に違反します。他の製品では、別の「すべての場所からサインアウト」操作を意図的に提供する場合がありますが、それは別の契約です。
最後に Browser A に切り替え、指定された認証情報でもう一度サインインし、予約を表示して Download booking をクリックします。新しいセッションは引き続き機能します。A の元の Repeater リクエストを変更せずに、Burp に戻ってください。それらの最新のレスポンスは、2つのサインアウト後の HTTP 401 レスポンスのままです。
この限定された変更は、受け入れ可能と判断できます。A の古いセッションは両方の保護されたリソースで拒否され、B のすでに確立された独立セッションは引き続き機能し、新たなサインインも機能します。これはセッションセキュリティのあらゆる側面を証明するものではありません。
誤って B をサインアウトしたり、A の古い cookie を置き換えたりした場合は、新しい独立した2つのセッションを確立し、一連の手順を最初から繰り返します。両ブラウザーで両方のリソースの基準状態を確認し、A のリクエストを保持し、A をサインアウトして A のリクエストを再送信し、B で再読み込みとダウンロードを行い、最後に A で新たなサインインを確認してください。タブを開き直すだけでは、代わりになるセッションは作成されません。
受け入れ判断を裏付けるテスト証拠を保持する
このステップでは、非公開の証拠と、裏付けのある受け入れ判断を提出します。Auditor に切り替えます。開始ディレクトリは /home/labex/project です。前に学んだように、umask 077 はこのシェルの新しいファイルを制限し、mkdir -p は証拠ディレクトリを作成し、chmod 700 はそのディレクトリを所有者だけが利用できるようにします。
umask 077
mkdir -p evidence
chmod 700 evidence
Burp → Repeater に切り替えます。A の元のアカウントリクエストを選択し、最新のレスポンスがサインアウト後の HTTP 401 であることを確認します。Request エディターを右クリックして Save item を選択し、File Name にこの絶対パスを入力します。
/home/labex/project/evidence/account-after.xml
Base64-encode requests and responses をチェックしたまま Save をクリックします。成功通知が表示された場合は OK で閉じます。A の元の予約リクエストでも繰り返してください。その最新のレスポンスも HTTP 401 でなければなりません。
/home/labex/project/evidence/booking-after.xml
これらの XML 項目には A の元の cookie が含まれています。Base64 はエンコードであり、暗号化ではありません。Auditor に切り替え、ファイルのアクセスを所有者に限定します。
chmod 600 evidence/account-after.xml evidence/booking-after.xml
ls -l evidence
両方のファイルに -rw------- が表示されるはずです。パスワードを含まないレポートには、前と同じ、テキストをそのまま保存するヒアドキュメント形式を使います。> は assessment.json を置き換えます。終了の JSON は単独の行に置く必要があります。
cat > assessment.json <<'JSON'
{
"decision": "accept",
"account_after_logout": 401,
"booking_after_logout": 401,
"independent_browser_preserved": true,
"fresh_sign_in_works": true
}
JSON
cat assessment.json
元の XML のリクエスト・レスポンスのペアと、このレポートを提出し、パスワード、cookie、生のリクエストをレポートに含めないでください。B の独立したアクセスと新たなサインインは、既存のサーバー上の事実により裏付けられます。検証は、不足しているサインイン、サインアウト、再送信のリクエストを実行しません。公開ページの維持確認リクエストによってアクセス記録が追加される場合がありますが、採点を繰り返してもファイルは維持されます。
ファイル名が誤っている場合は、同じ実際のレスポンスを正しいパスにエクスポートし、chmod 600 をもう一度適用してください。シェルが別の場所にある場合は、pwd で確認し、cd /home/labex/project で戻ります。通常の公開サイトと、対象のすべてのリソースを損なわずに維持してください。
まとめ
修正された現在のブラウザーのサインアウトを、アカウントページと予約ダウンロードの両方でテストしました。古い cookie は拒否され、別の、事前に確立されたブラウザーセッションはアクセスを維持し、新たなサインインも機能しました。非公開の Burp XML のリクエスト・レスポンスのペアと、パスワードを含まない評価が、裏付けのある受け入れ判断を保持します。
独立したチャレンジでは、会員、デプロイ先アドレス、予約が変わります。同じ完全な契約を適用し、両方の実際のリソースレスポンスから判断してください。
