HTTPには「メソッド」という概念があり、最もよく使われるのがGET（ページやデータを取得する）とPOST（フォームのデータなどを送信する）です。CTFのWeb問題では、このGET・POSTを意図的に書き換えることで脆弱性を突くパターンが頻出します。GETのパラメーターはURLに直接見えているため、開発者ツールのNetworkタブやURLバーで確認できます。POSTはURLには現れませんが、NetworkタブのRequest Bodyとして確認可能です。

URLは単なる「サイトのアドレス」ではなく、複数のパーツが組み合わさった構造を持っています。CTFのWeb問題では、URLのどの部分を操作するかによって解き方が変わるため、各パーツの意味を理解しておくことが重要です。

CTFのWeb問題でとくに注目すべきはクエリ文字列（?key=value の形式）です。ログインフォームの入力値や検索キーワードはクエリ文字列としてサーバーに送られることがあり、ここを意図的に書き換えることでSQL Injectionのような脆弱性が生まれます。たとえば ?id=1 を ?id=1 OR 1=1-- のように改ざんするのがSQL Injectionの基本パターンです（詳細は第8話で解説）。

CTFのWeb問題でCookieが重要視される理由は2つあります。第一に、Cookieにはユーザーのログイン状態（セッションID）が入っていることが多く、これを盗んだり偽造したりすることでなりすましができてしまう場合があります。第二に、問題によってはCookieの中に直接flagが隠されているケースがあります。今回のミニチャレンジもまさにそのパターンです。

Cookieには HttpOnly や Secure などの属性を付けることで、JavaScriptからのアクセスを禁止したり、HTTPS通信時のみ送信するように制限したりできます。CTFではこれらの属性が意図的に外されている問題があり、JavaScriptで document.cookie を実行するだけでCookieの値を読み取れてしまいます。セキュリティの視点から見ると、これは非常に重大な設定ミスです。

HTTPレスポンスには必ず「ステータスコード」と呼ばれる3桁の数字が含まれています。この数字が「サーバーの返事」を表しており、CTFでNetworkタブを確認する際に必ず目にします。代表的なものを覚えておきましょう。

このページを開いた瞬間、JavaScriptが自動的にブラウザにCookieをセットしました。開発者ツールの「Applicationタブ」を開いて、そのCookieの値からflagを見つけてください。

第4話ではHTTP・URL・Cookie・ステータスコードというWebの基礎をCTF視点で整理しました。これらは次話以降の実践問題で繰り返し登場する概念です。特にCookieとクエリ文字列は、Web問題の攻撃対象として最頻出なので、仕組みをしっかり押さえておきましょう。