6.2主要プロトコルとネットワーク応用

ネットワーク応用プロトコルの多くは1980-90年代に「性善説」を前提として設計されたため、プロトコルの標準動作そのものに攻撃面が内在しています。DNSの再帰問い合わせはキャッシュポイズニングの温床になり得ますし、cookieによるセッション管理はセッションハイジャックの対象になり得ます。この節では各プロトコルの動作を理解した上で、「どこに攻撃面があり、どう設計すればリスクを下げられるか」を判断する力を養います。

6.2.1HTTP/HTTPS

• HTTP＝Webのアプリケーション層プロトコルで、それ自体は平文通信のため通信内容の盗聴・改ざん（中間者攻撃）に無防備。HTTPSはHTTPをTLSで暗号化した方式で、通信の機密性（盗聴防止）・完全性（改ざん検知）・サーバ認証（正当なサーバへの接続確認）を提供する。
• HTTPSを導入していても、証明書の検証を省略する実装や古いTLSバージョン(SSLv3/TLS1.0等)を許容する設定では中間者攻撃のリスクが残る。SSL/TLS暗号設定ガイドラインに沿って推奨暗号スイート・プロトコルバージョンのみを許可する設計判断が必要。

6.2.2DNS（名前解決・再帰問い合わせ・キャッシュ）

• DNS＝ドメイン名とIPアドレスを対応付ける名前解決の仕組み。クライアントからの問い合わせを受けたキャッシュDNSサーバが、権威DNSサーバへ順にたどって解決する再帰問い合わせと、権威DNSサーバ同士が答えられる範囲だけ答える反復問い合わせがある。
• 解決結果をキャッシュすることで再問い合わせの負荷を減らせる一方、偽の応答をキャッシュに注入するDNSキャッシュポイズニングの対象になる。対策は問い合わせIDのランダム化・送信元ポートのランダム化に加え、応答の正当性をデジタル署名で検証するDNSSECの導入が根本対策。
• メール送信ドメイン認証で使うSPF・DKIM・DMARCもDNSのTXTレコードを使う仕組みであり、DNSインフラ自体の堅牢性（キャッシュポイズニング対策・ゾーン転送制限）がこれら認証の信頼性の前提になる。

6.2.3メールプロトコルとプロキシ

• SMTP＝メール送信プロトコル。認証なしのSMTPはメール中継の悪用（第三者中継）や送信ドメイン詐称の温床になるため、SMTP-AUTH（送信時のユーザー認証）やOP25B（ISPが25番ポート宛の直接送信を遮断しサブミッションポート587番経由に誘導）で対策する。POP3・IMAPはメール受信プロトコルで、IMAPはサーバ上でメールを管理しマルチデバイス利用に向く。
• フォワードプロキシ＝クライアント側に立ち、クライアントの代わりに外部へリクエストするプロキシ。URLフィルタリングやアクセスログ取得などクライアント側のセキュリティポリシー適用に使う。リバースプロキシ＝サーバ側に立ち、外部からのリクエストを受けて背後のサーバへ振り分けるプロキシ。WAF機能の集約・実サーバのIPアドレス秘匿・負荷分散に使う。

6.2.4REST・cookie・セッションID

• REST＝HTTPメソッド（GET/POST/PUT/DELETE等）とURLでリソースを操作する設計原則。HTTPは本来ステートレス（1リクエストごとに独立）なため、ログイン状態などのセッションを維持するには別途仕組みが要る。
• cookieにサーバが発行したセッションIDを保持させることで、以降のリクエストにセッションIDを自動送信しログイン状態を維持する。セッションIDが盗まれるとセッションハイジャック（正規利用者になりすましての乗っ取り）が成立するため、推測困難な十分な長さのランダム値であることに加え、cookieにSecure属性（HTTPS限定送信）・HttpOnly属性（JavaScriptからのアクセス禁止でXSS経由の盗用を防ぐ）・SameSite属性（CSRF対策）を付与する設計が必須。

あるWebサービスのシステム設計者が、ログイン機能とメール通知機能を含む新規サービスのセキュリティレビューを行う場面を想定します。まずセッション管理では、ログイン後にサーバがセッションIDを発行しcookieに格納する設計になっていますが、レビューの結果、cookieにSecure・HttpOnly両属性が未設定であることが判明しました。この状態だと、サイトにXSS脆弱性が1つでも存在すればdocument.cookie経由でセッションIDが窃取されセッションハイジャックが成立してしまいます。対策としてHttpOnly（JavaScriptからの読み取り禁止）とSecure（HTTPS限定送信で通信路上の盗聴を防止）を付与し、CSRF対策としてSameSite=StrictまたはLaxも設定します。次にDNS設計では、社内のキャッシュDNSサーバが問い合わせIDを固定値で運用していたことが判明し、DNSキャッシュポイズニングでこのサービスのドメインが偽のIPアドレスに解決されるリスクがあると判断し、問い合わせIDと送信元ポートのランダム化、可能なら権威側でのDNSSEC対応を推奨します。最後にメール通知機能では、SMTP認証なしで外部へメール送信していたため、第三者中継に悪用されるリスクがあり、SMTP-AUTHを必須化し、あわせて送信ドメイン認証（SPF/DKIM/DMARC）をDNSに設定してなりすましメールの拒否率を高めます。このように、各プロトコルの「標準の動作」を理解した上で、その動作のどこに攻撃面があるかを1つずつ潰していくのがセキュリティレビューの実務です。

6.2.5この節のまとめ

• DNSキャッシュポイズニング対策は問い合わせID/送信元ポートのランダム化＋DNSSEC（真正性のみ・暗号化ではない）
• セッションIDを格納するcookieにはSecure・HttpOnly・SameSite属性を必ず設定し、盗聴・XSS窃取・CSRFを防ぐ
• フォワードプロキシはクライアント側のポリシー適用、リバースプロキシはサーバ側のIP秘匿・負荷分散・WAF集約に使う