【図解】HTTP/HTTPSとセッション管理の仕組みを完全理解！Webセキュリティの基礎

Webアプリケーションが当たり前のように使われている現在、その通信基盤であるHTTPやHTTPS、そして利用者の状態を維持するためのセッション管理は、セキュリティを語る上で避けては通れない最重要テーマです。

これらは単なる「用語」ではなく、攻撃者がどこを狙い、防衛側がどこを守るべきかを知るための「地図」のようなものです。特にWeb系のセキュリティ問題では、通信の中身（ヘッダやボディ）を具体的にイメージできるかどうかが、正答率に直結します。

今回は、私たちが普段何気なく利用しているWeb通信の裏側で、どのようなデータのやり取りが行われているのか、そして「ログイン状態」というものがどのように維持され、守られているのかを、基本のキから徹底的に深掘りしていきます。

Web通信の基本言語、HTTPの正体

WebブラウザとWebサーバが会話をするための共通言語、それがHTTP（HyperText Transfer Protocol）です。まずは、この通信がどのような性質を持っているのか、解剖していきましょう。

ステートレスという「記憶喪失」な性質

HTTPを理解する上で最も重要なキーワードが「ステートレス（Stateless）」です。これは直訳すると「状態を持たない」という意味になります。

具体的には、Webサーバは「直前のやり取り」を覚えていません。例えば、あなたがショッピングサイトで「商品をカートに入れる」ボタンを押したとします。その直後に「決済画面へ進む」ボタンを押したとしても、HTTPの仕組みそのものだけでは、サーバは「決済画面に来たこの人」が「さっき商品をカートに入れた人」と同じ人物かどうかが判断できません。

一回一回の通信（リクエストとレスポンス）は完全に独立しており、前後の文脈を持たないのです。このシンプルさこそがWebが世界中に爆発的に普及した要因の一つですが、同時に「ログイン状態の維持」や「買い物カゴ機能」を実現するためには、後述する工夫（Cookieやセッション）が必要になる理由でもあります。

リクエストとレスポンスの構造

HTTP通信は、クライアント（ブラウザ）からの「リクエスト」と、サーバからの「レスポンス」のキャッチボールで成り立っています。セキュリティを学ぶ上では、この中身を透視できるレベルになる必要があります。

1. HTTPリクエスト

リクエストは主に以下の3つのパートで構成されます。（※重要なルールとして、ヘッダーとボディの間には必ず「空行（CRLF）」が入り、これがデータの境界線となります。この改行コードの解釈の隙を突くのが、HTTPリクエストスマグリングなどの高度な攻撃です）

• リクエストライン: 「何を（URI）」「どうしたいか（メソッド）」を伝えます。例: GET /index.html HTTP/1.1
• ヘッダー: ブラウザの種類、対応言語、Cookieなどの付加情報。例: Host: www.example.com、User-Agent: Mozilla/5.0...
• ボディ: フォームに入力したデータなど（GETメソッドの場合は空であることが多い）

2. HTTPレスポンス

レスポンスも同様に3つのパートです。

• ステータスライン: 結果がどうだったか（ステータスコード）。例: HTTP/1.1 200 OK
• ヘッダー: データの種類、サーバ情報、Cookieの発行など。例: Content-Type: text/html、Set-Cookie: session_id=xyz...
• ボディ: 実際に表示するHTMLや画像データ

メソッドとステータスコードの意味

試験対策として、以下のメソッドとコードは反射的に意味が出てくるようにしておきましょう。

主要なメソッド

• GET: データの取得。パラメータがURLに付与されるため、Webサーバのアクセスログ、プロキシのログ、ブラウザの履歴等に平文で記録されてしまうことから、機密情報の送信には不向き
• POST: データの送信。ボディ部にデータが入るため、パスワードなどの送信に使用（※注意：POST自体に暗号化機能はないため、盗聴を防ぐには必ずHTTPSと組み合わせる必要があります）
• PUT: リソースの作成・置換
• DELETE: リソースの削除
• HEAD: ヘッダー情報のみ取得

主要なステータスコード

• 200 OK: 成功
• 301 Moved Permanently: 恒久的な移動（リダイレクト）
• 302 Found: 一時的な移動
• 400 Bad Request: クライアントのリクエスト不備
• 401 Unauthorized: 認証が必要（※仕様上の名称は「Unauthorized（認可エラー）」ですが、実態は「Unauthenticated（未認証）」を指すというHTTPの歴史的な命名の罠があるため、セキュリティの「認証と認可」を考える際には注意が必要です）
• 403 Forbidden: アクセス権限がない（認証済みであっても権限が不足している場合の「認可エラー」、あるいはIP制限などによるアクセス拒否）
• 404 Not Found: 見つからない
• 500 Internal Server Error: サーバ内部のエラー
• 503 Service Unavailable: サービス利用不可（高負荷やメンテ中）

なぜHTTPSが必要なのか？暗号化の仕組み

HTTPは平文（ひらぶん）で通信されます。つまり、ネットワーク上の通信経路を流れるパケットをキャプチャ（盗聴）すれば、誰でもその中身を読むことが可能です。パスワードやクレジットカード番号をHTTPで送ることは、透明な封筒で現金を郵送するようなものです。

そこで登場するのがHTTPS（HTTP Secure）です。これは、HTTP通信をTLS（Transport Layer Security）というプロトコルで暗号化したものです（昔はSSLと呼ばれていましたが、現在はTLSが標準です）。

HTTPSが提供する3つの価値

HTTPSは単に「暗号化」するだけではありません。通信の保護において極めて重要な、以下の3つの機能（機密性・完全性・真正性）を提供します。※情報セキュリティの3大要素（CIA）の「A」は可用性（Availability）ですが、HTTPSが提供する「A」は真正性（Authenticity）である点に注意してください。

1. 盗聴防止（暗号化）: 暗号化技術により、通信内容を第三者が読めないようにする
2. 改ざん防止（完全性）: 通信途中でデータが書き換えられていないことをメッセージ認証コード（MAC）などで保証する
3. なりすまし防止（真正性）: デジタル証明書を用いた認証により、接続先のサーバが本物であることを証明する

特に3つ目の「真正性（サーバの認証）」が重要です。通信経路の機密性が保たれていても、その接続相手が「偽物の銀行サイト」であっては意味がないからです。

共通鍵と公開鍵のハイブリッド暗号

HTTPSの通信確立（TLSハンドシェイク）は、非常に巧妙な仕組みになっています。「公開鍵暗号方式」と「共通鍵暗号方式」のいいとこ取りをしているのです。

TLSハンドシェイクの流れ

1. 証明書の提示: サーバは、信頼できる第三者機関（認証局：CA）が発行した「デジタル証明書」と「公開鍵」をクライアントに送ります
2. 証明書の検証: クライアント（ブラウザ）は、あらかじめ持っている認証局のルート証明書を使って、送られてきた証明書が本物か検証します。これにより「なりすまし」を防ぎます
3. 共通鍵の素材の共有（方式によって異なる）:
   • TLS 1.2（RSA鍵交換の場合）: クライアントは乱数を元に「プリマスタシークレット」を生成し、サーバの「公開鍵」で暗号化してサーバに送ります。サーバは自身の「秘密鍵」で復号してプリマスタシークレットを取り出します。
   • TLS 1.2（DHE/ECDHE）およびTLS 1.3（ECDHE必須）: クライアントとサーバがそれぞれDiffie-Hellman公開値を交換し、双方が独立して同じ共通鍵を計算します。クライアントはサーバの公開鍵でプリマスタシークレットを暗号化して送るのではなく、数学的な鍵合意（Key Agreement）によって共通鍵が導出されます。なお、TLS 1.3 では RSA 鍵交換は完全に廃止され、ECDHE のみが使用されます。
4. 共通鍵の生成: 上記で得られた共通の素材（プリマスタシークレットやDH計算結果）から、実際の暗号化に使う「セッション鍵（マスタシークレット等）」が生成されます。
5. 暗号化通信の開始: これ以降のHTTP通信はこの共通鍵で暗号化されます。

TLS 1.2（RSA方式）では公開鍵暗号によって鍵素材を安全に受け渡し、TLS 1.3（ECDHE）ではDiffie-Hellman鍵合意で双方が共通鍵を導出します。いずれの方式も、実際のデータ転送には処理が高速な共通鍵暗号を使うという設計は共通です。これがWebの速度と安全性を両立させる知恵です。

デジタル証明書の役割

デジタル証明書には、サーバのドメイン名（現在は「Subject Alternative Name（SAN）」拡張領域に記載されるのが標準です）、公開鍵、証明書の有効期限、発行した認証局の情報などが含まれています。この証明書に認証局のデジタル署名が付与されることで、「この証明書は改ざんされていない」「この公開鍵は確かにSANに記載されたドメインのものである」ということが保証されます。

ブラウザには主要な認証局のルート証明書があらかじめインストールされており、これを使って証明書チェーン全体の検証を行います。検証に失敗した場合、ブラウザは警告画面を表示し、ユーザーに危険性を知らせます。

ステートレスを克服するCookieとセッション

話をHTTPに戻しましょう。HTTPは「記憶喪失（ステートレス）」でした。しかし、会員サイトにログインした後、ページ移動のたびにIDとパスワードを入力させられるのは実用的ではありません。

そこで、Cookie（クッキー）とセッションという技術を組み合わせて、あたかもサーバが自分を覚えてくれているかのような「ステートフル」な状態を作り出します。

Cookie：ブラウザ側のメモ帳

Cookieは、サーバからブラウザに「これを保存しておいて、次に来るときに見せてね」と渡される小さなテキストデータです。

1. ブラウザがサーバにアクセスする
2. サーバはレスポンスヘッダに Set-Cookie: data=123 を含める
3. ブラウザは data=123 を保存する
4. 次回、同じサーバにアクセスする際、ブラウザはリクエストヘッダに Cookie: data=123 を自動的に含めて送信する

これにより、サーバは「あ、さっき data=123 を渡した相手だ」と認識できます。

Cookieには有効期限、適用されるドメインやパス、後述するセキュリティ属性などを設定できます。有効期限が設定されていないCookieは「セッションCookie」と呼ばれ、原則としてブラウザを閉じると消去されます。ただし、現代のブラウザの「前回開いていたページを開く」等のタブ復元機能が有効な場合、ブラウザを閉じてもCookieが消去されずに維持されることがあるため、実務上のセキュリティ設計ではサーバ側でのセッションタイムアウト管理が極めて重要になります。

セッション：サーバ側の管理台帳

しかし、Cookieに「ユーザーID=admin」「ログイン済み=yes」などと直接書いてしまうと危険です。Cookieはブラウザ側で簡単に改ざんできるからです。「ログイン済み=yes」を勝手に書き込んで送信すれば、認証を突破できてしまいます。

そこで使われるのがセッションです。

1. ログイン成功: ユーザーがID/PASSを入力し、認証に成功する
2. セッションID発行: サーバは、ランダムで推測困難な文字列（セッションID）を発行する
3. サーバ側での保存: サーバは「セッションID: ABCxyz」と「ユーザー: 田中さん」という対応表（セッション変数）をメモリやDBに保存する
4. Cookieへの書き込み: サーバは Set-Cookie: session_id=ABCxyz をブラウザに送る
5. 以降の通信: ブラウザは Cookie: session_id=ABCxyz を送るだけ。サーバは受け取ったIDを元に、手元の対応表を見て「これは田中さんだ」と判断する

重要なデータ（誰がログインしているか等）はサーバ側に置き、その引換券（セッションID）だけをCookieでやり取りする。これが現在のWebアプリケーションの標準的なセッション管理です。

セッションIDの要件

セキュアなセッションIDは以下の要件を満たす必要があります。

• 推測困難性: 十分な長さ（128ビット以上推奨）を持ち、暗号論的擬似乱数生成器（CSPRNG）を用いて生成された予測不可能な値であること。標準ライブラリの単純な乱数関数（例: Math.random() など）は予測可能であるため、セッションIDの生成には絶対に使用してはいけません。
• 一意性: 同じIDが他のユーザーに発行されないこと
• 有効期限: 一定時間操作がない場合は無効化されること（セッションタイムアウト）
• 再利用の禁止: ログアウト後や再ログイン時には新しいIDを発行すること

セッション管理におけるセキュリティリスクと対策

この「セッションID」は、Web上の身分証明書そのものです。もし他人のセッションIDを入手できれば、IDやパスワードを知らなくても、その人になりすましてログイン後の操作ができてしまいます。これをセッションハイジャックと呼びます。

開発者や管理者は、セッションIDを守るために、Cookieに適切な属性（Attribute）を設定する必要があります。以下の3つの属性は、試験で問われる最重要ポイントです。

1. Secure属性（盗聴防止）

機能: Secure属性がついたCookieは、HTTPS（暗号化）通信の時だけ送信されます。HTTP（平文）通信の時は送信されません。

リスク: これがないと、誤ってHTTPでアクセスした際にCookieが平文で流れ、盗聴されるリスクがあります。

設定例: Set-Cookie: session_id=...; Secure

2. HttpOnly属性（XSSによる情報漏えい対策）

機能: HttpOnly属性がついたCookieは、JavaScript（document.cookieなど）からアクセスできなくなります。※注意：HttpOnlyは「XSS自体の発生を防ぐ」ものではありません。攻撃者がJavaScript（Fetch APIなど）を用いてユーザーの権限で不正なリクエストを送信することは防げないため、根本的なXSS対策（エスケープ処理など）は別途必須です。

リスク: Webサイトに脆弱性があり、悪意あるスクリプトを埋め込まれる攻撃（クロスサイトスクリプティング：XSS）を受けた場合、攻撃者のスクリプトによってCookie（セッションID）が盗み出されるのを防ぎます。

設定例: Set-Cookie: session_id=...; HttpOnly

3. SameSite属性（CSRF対策）

機能: 異なるサイト（クロスサイト）からリクエストが送信された場合に、Cookieを送るかどうかを制御します。

設定値:

• Strict: 常に送らない。最も安全だが利便性が下がる他サイトのリンクから遷移してきた際、初回リクエストにCookieが送信されないため、一時的に未ログイン状態として扱われるなど）
• Lax: 安全なトップレベルナビゲーション（リンクをクリックして画面遷移するGETリクエストなど、サーバ側の状態を変更しないSafeなHTTPメソッド）では送るが、埋め込み画像やPOST送信（状態変更を伴うリクエスト）などでは送らない。現在のブラウザのデフォルト挙動
• None: 常に送る（Secure属性が必須）

リスク: これが不適切だと、罠サイトを踏ませて意図しない操作（送金や投稿など）を行わせる攻撃（クロスサイトリクエストフォージェリ：CSRF）に対して脆弱になります。

設定例: Set-Cookie: session_id=...; SameSite=Lax

セッションフィクセーション（Session Fixation）

セッションハイジャックの手口の一つに「セッション固定化攻撃」があります。攻撃者が正規のサイトで有効なセッションIDを取得し、それを標的のユーザーに強制的に使わせます（かつてはURLパラメータに付与する手口が主流でしたが、現代ではXSSやサブドメイン経由で不正なセッションCookieを被害者のブラウザに直接書き込む手口が主流です）。ユーザーがそのIDのままログインすると、攻撃者も手元のIDを使ってログイン状態に入れてしまう攻撃です。

対策: ログイン成功時に、必ず新しいセッションIDを発行し直す（セッションIDの再生成）ことで防げます。多くのWebフレームワークでは、この機能が標準で提供されています。

セッションタイムアウトの設定

長時間放置されたセッションは、セキュリティリスクとなります。適切なタイムアウト値を設定することで、リスクを低減できます。

• アイドルタイムアウト: 一定時間操作がない場合にセッションを無効化（一般的に15〜30分程度）
• 絶対タイムアウト: ログインからの経過時間で強制的にログアウト（機密性の高いシステムでは数時間程度）

金融機関など、高いセキュリティが求められるサイトでは、より短いタイムアウト値が設定されています。

試験対策としての重要チェックポイント

HTTP/HTTPSとセッション管理は、知識問題だけでなく、ログ分析やプログラミングの問題でも頻出です。以下のポイントを整理しておきましょう。

1. 通信の流れ

TLSハンドシェイクのどの段階で証明書が渡され、どの段階から暗号化が始まるかを理解しておく必要があります。TLS 1.2では「証明書の検証」が「共通鍵の交換」より前に行われます。

一方、TLS 1.3では鍵共有（Key Share）情報がClient Helloと同時に送られるため、ハンドシェイクが1往復（1-RTT）に短縮されています。試験ではTLS 1.2の2-RTTとTLS 1.3の1-RTTの違い、およびTLS 1.3でRSA鍵交換が廃止された点が問われる場合があります。

2. Cookieの属性

Secure、HttpOnly、SameSite のそれぞれの役割と、どの攻撃を防ぐためのものかを明確に区別できるようにしましょう。

• Secure → 盗聴防止（HTTPS環境でのみ送信）
• HttpOnly → XSSによるCookie盗聴対策（JavaScriptからのアクセス禁止）
• SameSite → CSRF対策（クロスサイトからの送信制御）

3. 攻撃手法

セッションハイジャック、セッションフィクセーション、XSS、CSRFのメカニズムと対策の関連性を理解することが重要です。これらは単独で出題されることもあれば、複合的な問題として出題されることもあります。

4. ログの読み方

Webサーバのアクセスログを見て、メソッド、ステータスコード、User-Agentなどから、正常なアクセスか攻撃か（SQLインジェクションやディレクトリトラバーサルなど）を判別する力が求められます。

例えば、以下のようなアクセスログがあった場合：

192.168.1.100 - - [26/Dec/2025:10:30:15 +0900] "GET /index.php?id=1%27%20OR%20%271%27=%271 HTTP/1.1" 200 5234

このログから「GETメソッドでURLエンコードされた不自然な文字列（デコードすると 1' OR '1'='1 というSQLクエリらしき文字列になる）が渡されている」→「SQLインジェクションの可能性」と推測できる必要があります。

5. プロトコルのバージョン

HTTPのバージョンやTLSのバージョンについても、基本的な違いと、古いバージョンの脆弱性（例：SSL 3.0のPOODLE攻撃）について知識を持っておくと良いでしょう。特に最新の「HTTP/3」は、従来のTCPではなくUDPベースの「QUIC」プロトコルを採用しており、通信の高速化だけでなく、ファイアウォールやパケット監視のセキュリティ要件が根本から変わる点に注意が必要です。また、TLSは現在「TLS 1.2」および「TLS 1.3」のみが安全とされています。

実務での応用ポイント

試験対策だけでなく、実務でも以下の点に注意が必要です。

Webアプリケーション開発時

• セッションIDは必ずサーバ側で生成し、クライアント側では生成しない
• Cookie属性は必ず Secure; HttpOnly; SameSite=Lax を設定する。また、サブドメインからの不正操作（Cookie Tossing攻撃など）を防ぐため、原則としてDomain属性は指定しない（発行元ホストのみに送信されるHost-Only Cookieとして扱う）
• ログイン成功時には必ずセッションIDを再生成する
• センシティブな操作には再認証やCSRFトークンを要求する

インフラ・運用側

• HTTPSを必須とするだけでなく、HSTSヘッダー（Strict-Transport-Security）を送信してブラウザに「次回以降は絶対にHTTPSで通信すること」を記憶・強制させる（これにより、中間者攻撃によって通信をHTTPへ降格させられる「SSLストリッピング攻撃」を未然に防ぎます）
• 古いTLS/SSLバージョンは無効化する（TLS 1.2以上を使用）
• 証明書の有効期限管理を自動化する
• アクセスログを定期的に監視し、異常なパターンを検知する

セキュリティ監査時

• Cookie属性の設定状況を確認する
• セッションタイムアウトの設定が適切か検証する
• HTTPSへのリダイレクトが正しく機能しているか確認する
• セッション管理の実装に脆弱性がないかペネトレーションテストを実施する

【演習】Webセキュリティ基礎力アップ！HTTP/HTTPS・セッション管理 実戦問題10選

記事で解説したHTTP/HTTPSの仕組みやセッション管理の重要ポイントを、選択式のクイズ形式で確認しましょう。 「ステートレス性」「TLSハンドシェイク」「Cookieの属性（Secure/HttpOnly/SameSite）」など、情報処理安全確保支援士試験や実務で頻出の知識を網羅しています。 解説もその場で表示されるので、知識の定着確認や試験直前の総点検として活用してください。全問正解を目指しましょう！

まとめ

今回は、Webセキュリティの基礎であるHTTP/HTTPSの仕組みと、セッション管理について解説しました。

HTTP: ステートレスなプロトコル。リクエストとレスポンスで構成され、メソッドとステータスコードによって操作と結果を表現します。

HTTPS: HTTPをTLSで暗号化し、盗聴・改ざん・なりすましを防ぎます。公開鍵暗号と共通鍵暗号のハイブリッド方式により、安全性と効率性を両立しています。

Cookie/セッション: ステートレスなHTTP上で状態（ログイン等）を維持する仕組み。セッションIDという「引換券」をCookieで管理することで、重要な情報をサーバ側に保持します。

セッション管理の防衛: セッションIDは「鍵」です。Secure、HttpOnly、SameSite 属性で守り、ログイン時にはIDを再生成することが必須です。

Webアプリケーションへの攻撃の多くは、この「通信の仕組み」や「セッション管理の不備」を突いてきます。逆に言えば、ここを堅牢に設計・実装・運用できれば、Webサイトの安全性は飛躍的に高まります。HTTPとHTTPSの違いを理解し、適切なセッション管理を実装することが、Webセキュリティの第一歩となります。

次回は、これらの基礎知識を前提とした、より具体的なWeb攻撃手法（SQLインジェクションやXSSの詳細）について掘り下げていきます。基礎を固めて、応用へのステップアップを図りましょう。