同じexploitが、失敗することを確かめる

修正後のarena-webに対して、第1章と全く同じexploitコマンドを再実行し、明示的に失敗することを確認します。正規の認証手段では引き続きflagが得られることも確認します。

第3章 / 全5章目安約8分この章のゴール: 修正後にexploitが失敗すること、正規の手段は引き続き動くことを確認できる

「直したはず」で終わらせず、第1章とまったく同じコマンドで確かめます。

旧exploit1 — 隠しエンドポイント

curl -s -w "\nHTTP:%{http_code}\n" http://127.0.0.1:4500/api/internal/debug-status

{"error":"not found"}
HTTP:404

404になりました。ルートそのものを削除したので、このパスは存在しません。

curl -s "http://127.0.0.1:4500/api/photos?role=admin"

{"photos":["public1.jpg","public2.jpg"]}

flagが返らなくなりました。サーバーはもうroleパラメータを見ていません。クライアントが何を送ろうと、無視されます。

セキュリティ修正で一番怖いのは、直しすぎて正規の機能まで壊すことです。トークンさえ持っていれば、管理者は引き続き機能を使えることを確認します。

curl -s -H "Authorization: Bearer admin-token-xyz" http://127.0.0.1:4500/api/photos

{"photos":["public1.jpg","public2.jpg"],"flag":"flag{role_now_comes_from_the_server}"}

curl -s -H "Authorization: Bearer bogus-token" http://127.0.0.1:4500/api/photos

{"photos":["public1.jpg","public2.jpg"]}

正しいトークンでは引き続きflagが得られ、でたらめなトークンではguest扱いになりました。「攻撃が失敗する」ことと「正規の利用が壊れていない」ことの両方を確認して、初めて修正が完了したと言えます。

直した、で終わらせない。同じ攻撃コマンドで、明示的に失敗を確認する。 これがsec-securecodingやsec-auditで扱った「修正の検証」の、CTFという文脈での実践でした。次でこのコースをまとめます。

卒業まであと1章です。

この章はまだ完了していません。