はじめに
店舗の請求書には、顧客の購入品、金額、請求先住所が記載されます。顧客が読めるのは自分の請求書か、明示的に共有された請求書だけであるべきです。ID を知っていることは閲覧の許可を意味しません。
合成データの Invoice Desk を顧客 Alex としてテストする許可が与えられています。通常のアクセスから始め、共有と非公開の請求書を比較し、非公開の応答を保存して所有者の境界の欠陥を示します。このラボは検証までで、サーバーは修正しません。提示された練習用オブジェクトだけが対象です。
通常のアクセスを確かめる
このステップでは、Alex としてログインし、別のアカウントをテストする前に自分の請求書を取得します。
このステップを始めるには、ラボ画面の Invoice Desk タブを選択してください。
Invoice Desk タブに切り替えます。図のクライアントはリクエストを送り、API サーバーは応答します。API はアプリのリクエスト用インターフェースです。API: ready は実際のヘルスチェックの結果です。表は期待されるアクセス規則を示します。
| 請求書 ID | 所有者 | 共有先 | Alex は読めるか |
|---|---|---|---|
inv-104 |
alex |
なし | はい：所有者 |
inv-208 |
morgan |
なし | いいえ：非公開 |
inv-315 |
riley |
alex |
はい：明示的な共有 |
ポータルにユーザー名 alex、パスワード shop-alex-42 を入力し、Sign in を選びます。Signed in as alex を確認します。Invoice ID に inv-104 を入力して View invoice を選びます。owner は alex になるはずです。
Client Terminal タブに切り替えます。ここは /home/student/project にある隔離された顧客の作業領域で、サーバーではありません。invoice-api:8000 は練習用ネットワーク内のサーバー名で、公開の対象ではありません。curl は端末から HTTP リクエストを送ります。HTTP はここで使う要求と応答のプロトコルで、GET はリソースの読み取りを求めます。アドレスの後のパスがリソースを指定します。-i は応答のステータスとヘッダーを表示します。
セッションがなければ 401 Unauthorized が返り、ログインが必要だと分かります。
次のコマンドを実行する前に、Client Terminal タブに切り替えてください。
curl -i http://invoice-api:8000/api/invoices/inv-104
ブラウザーのログインは curl をログインさせません。セッションはログインした人を表すサーバー側の記録で、ランダムな cookie が後続のリクエストをその記録に結び付けます。次のコマンドは名前付きフィールドの形式である JSON オブジェクトを送信します。-H は JSON を示すヘッダーを設定し、-d は認証情報を送って POST を選び、-c は返された cookie を session.txt に保存します。単一引用符は空白と二重引用符をまとめて 1 つのシェル引数にします。
curl -sS -c session.txt -H 'Content-Type: application/json' -d '{"username":"alex","password":"shop-alex-42"}' http://invoice-api:8000/api/login
-sS は進捗表示を隠し、接続エラーは表示します。account は alex のはずです。-b は保存した cookie を送信します。セッションの身元を確認します。
curl -sS -b session.txt http://invoice-api:8000/api/me
自分の請求書を要求します。
curl -sS -b session.txt http://invoice-api:8000/api/invoices/inv-104
invoice_id、owner、item、total_usd を読みます。Alex は Desk lamp を 38.00 で購入しました。空の shared_with リスト [] は、他の人には許可していないことを示します。これは通常の動作です。チェックポイントは、端末とポータルのどちらから要求しても、サーバーが Alex に返した実際の応答を確認します。
ログイン後も 401 なら、この端末でログインコマンドを繰り返し、-b session.txt で再試行します。接続エラーは別で、HTTP 応答が届いていません。アドレスと API: ready を確認してください。
別の請求書を要求する
このステップでは、ログインした身元を変えずに、明示的な共有と非公開の請求書を比較します。
このステップを始めるには、ラボ画面の Client Terminal タブを選択してください。
認証は「誰ですか」、認可は「この人はこの請求書を読めますか」に答えます。ログイン成功で分かるのは前者だけです。まず正当に共有された請求書をダウンロードします。ダウンロードも GET リクエストです。/download は同じ JSON フィールドを持つ保存用の応答を選びます。
次のコマンドを実行する前に、Client Terminal タブに切り替えてください。
curl -sS -b session.txt http://invoice-api:8000/api/invoices/inv-315/download
所有者は riley ですが、shared_with に alex が含まれます。このアクセスは許可されています。所有者が違うだけでは欠陥の証拠になりません。
次に非公開のケースを予測します。inv-208 は Morgan の所有で、誰にも共有されていないため、Alex は拒否されるべきです。通常は 403 Forbidden です。非公開オブジェクトの存在を隠すために 404 Not Found を返すサービスもあります。ここでは未知の ID にも 404 が返ります。200 OK はリクエストの成功を示し、本文から漏えいした内容が分かります。
-v は実際に送ったリクエストと受信ヘッダーを表示します。練習用セッション cookie も表示されるため、この出力をラボ外で共有しないでください。
curl -v -b session.txt http://invoice-api:8000/api/invoices/inv-208
GET /api/invoices/inv-208 と HTTP/1.0 200 OK を探します。本文は所有者 morgan、空の共有リスト、Studio microphone、請求先 82 Cedar Lane を示します。サーバーは Alex に非公開オブジェクトを渡しました。変更したのはオブジェクトのパスで、セッションの身元ではありません。予測しやすい ID はテストを容易にしましたが、漏えいの原因は権限チェックの欠落です。
Invoice Desk タブに切り替え、inv-315 に Download invoice、inv-208 に View invoice を使って両方のリクエストを繰り返します。ブラウザークライアントはダウンロード応答を同じ顧客作業領域へ保存します。チェックポイントが必要とするのは、許可された共有ダウンロードと非公開の閲覧結果で、説明ファイルではありません。
漏えいを検証する
このステップでは、実際の非公開ダウンロードを保存し、漏えいしたデータを業務への影響に結び付けます。
このステップを始めるには、ラボ画面の Client Terminal タブを選択してください。
非公開請求書に /download を使います。-o は応答バイト列を表示せずファイルへ書き込みます。現在の顧客作業領域に完全な応答を private-invoice.json として保存します。
次のコマンドを実行する前に、Client Terminal タブに切り替えてください。
curl -sS -b session.txt -o private-invoice.json http://invoice-api:8000/api/invoices/inv-208/download
cat はファイルを表示して読めるようにします。
cat private-invoice.json
同じ Morgan の請求書に、invoice_id inv-208、所有者 morgan、金額 129.00、請求先住所があるはずです。401 エラーや共有請求書を保存していたら、必要に応じて再ログインして指定の非公開請求書をダウンロードします。-o はファイルを置き換えます。
別の方法として、Invoice Desk タブに切り替えます。Alex としてログインした状態で inv-208 を入力し、Download invoice を選びます。ブラウザークライアントは実際の API リクエストを転送し、未変更の応答を /home/student/project/private-invoice.json に保存します。Client Terminal タブに戻ると読めます。どちらの方法でも同じ結果を満たせます。
チェックポイントを実行します。保存したバイト列と指定請求書を比較し、Alex のセッションでサーバーがダウンロードを記録したことを確認します。コピーした主張、作り物の請求書、許可された共有請求書、対応する顧客ダウンロードのないファイルは結果の証明になりません。
実際の影響は、他の顧客の購入内容と請求先住所の漏えいです。サーバーはダウンロードを含む各オブジェクト要求で、現在の人が所有者か明示的な共有先かを確認すべきです。リンクを隠したり ID を推測しにくくしたりしても、この確認は置き換えられません。OWASP BOLA が説明するオブジェクト単位の認可問題です。許可されたテストは完了です。サーバー修正は別の作業に任せます。
まとめ
顧客セッションを作り、自分の請求書を読み、明示的な共有と非公開アクセスを区別し、実際のアカウント間応答を保存しました。サーバーへのアクセスや被害者の認証情報を使わず、漏えいしたデータと受信した身元の両方を検証しました。
