はじめに
Webセキュリティを学ぶうえで、HTTP通信の仕組みは最も基本となる知識です。
脆弱性診断の現場では、Burp Suiteなどのツールで通信内容を日常的に確認します。そのとき「リクエストの構造がわからない」「GETとPOSTの違いが曖昧」では、診断の精度に直結します。
本記事では、HTTP通信の基礎をセキュリティの視点から整理します。
結論
HTTPはWebの通信プロトコルであり、リクエストとレスポンスの1往復で完結するステートレスな仕組み。GETとPOSTの違いはパラメータの送信場所にあり、セキュリティ上はPOSTが推奨される。
HTTPとは
HTTP（Hypertext Transfer Protocol）は、Webブラウザとサーバー間でデータをやりとりするためのアプリケーション層のプロトコルです。
HTTPの最大の特徴：ステートレス
HTTPはステートレス（Stateless） なプロトコルです。これは、リクエストとレスポンスの1往復ごとに通信が独立しており、サーバーは前回の通信内容を覚えていないことを意味します。
この問題を克服するためにCookie・セッションという仕組みが存在しますが、これについては別記事で解説します。
リクエストメッセージの構造
HTTPリクエストは以下の3つの要素で構成されます。
┌─────────────────────────────────────────────┐
│ リクエストライン（1行目） │
│ メソッド ＋ URI ＋ プロトコルバージョン │
├─────────────────────────────────────────────┤
│ ヘッダ │
│ Host, Content-Type, Cookie など │
├─────────────────────────────────────────────┤
│ ボディ（メッセージボディ） │
│ POSTメソッドの場合にパラメータが格納される │
└─────────────────────────────────────────────┘
リクエストラインの例
GET /login?user=tanaka HTTP/1.1
| 要素 | 内容 |
|---|---|
| メソッド |
GET（何をしたいか） |
| URI |
/login?user=tanaka（どこに対して） |
| バージョン |
HTTP/1.1（どのバージョンで） |
ヘッダで重要なもの
| ヘッダ名 | 役割 |
|---|---|
| Host | 送信先のFQDN（ホスト名＋ドメイン名）とポート番号を指定する |
| Cookie | サーバーから受け取ったCookie値を送信する |
| Referer | 直前にいたページのURLを送信する |
| Content-Type | ボディのデータ形式を指定する |
レスポンスメッセージの構造
HTTPレスポンスも3つの要素で構成されます。
┌─────────────────────────────────────────────┐
│ ステータスライン（1行目） │
│ プロトコルバージョン ＋ ステータスコード │
├─────────────────────────────────────────────┤
│ ヘッダ │
│ Set-Cookie, Content-Type など │
├─────────────────────────────────────────────┤
│ ボディ │
│ HTMLやJSONなどのレスポンスデータ │
└─────────────────────────────────────────────┘
GETメソッドとPOSTメソッドの違い
パラメータの送信場所が異なる
| 項目 | GET | POST |
|---|---|---|
| パラメータの場所 | URL内のクエリ文字列 | メッセージボディ |
| URLに情報が載るか | 載る | 載らない |
| データ長の制限 | URLの長さに依存（上限あり） | ボディに上限なし |
| ログへの記録 | URLごとサーバーログに残りやすい | ボディはログに残りにくい |
GETメソッドで重要情報を送信するリスク
GETメソッドのURLにパラメータが含まれることで、以下のリスクが発生します。
- Referer経由の漏洩：パラメータ付きURLがRefererヘッダに載り、外部サイトに送信される
- アクセスログへの記録：URLがサーバーのアクセスログにそのまま保存される
- アドレスバーへの表示：URLバーに表示されるため、画面を覗き見される可能性がある
- URLの共有による漏洩：パラメータ付きURLをSNS等で誤って共有してしまう
- キャッシュへの残存：ブラウザやプロキシのキャッシュにURLが残る可能性がある
セキュリティ上の結論
重要情報（パスワード、トークン、個人情報など）は、GETではなくPOSTメソッドで送信すべき。
ただし、POSTだから安全というわけではなく、TLS（HTTPS）による通信の暗号化も合わせて必要です。
URLの構成要素
https://www.example.com:443/path/to/page?key=value#section
└─┬──┘ └─┬┘└───┬────┘└┬┘└─────┬─────┘└───┬───┘└──┬───┘
スキーム ホスト ドメイン ポート パス クエリ フラグメント
名 名 番号 文字列
| 用語 | 説明 |
|---|---|
| スキーム | 通信方式（http、httpsなど） |
| ホスト名 | サーバー管理者が任意で決めるコンピュータ名（wwwなど） |
| ドメイン名 | IPアドレスを人間が読みやすくしたもの（example.com） |
| FQDN | ホスト名＋ドメイン名の完全な名前（www.example.com） |
まとめ
| ポイント | 内容 |
|---|---|
| HTTPはステートレス | 1回の通信ごとに状態を忘れる |
| リクエストの1行目 | リクエストライン（メソッド ＋ URI ＋ バージョン） |
| GETのリスク | URLにパラメータが含まれるため情報漏洩リスクが高い |
| 重要情報はPOSTで | かつHTTPSによる暗号化も必須 |
| Hostヘッダ | 送信先のFQDNとポートを示す重要なヘッダ |
参考資料
この記事は脆弱性診断エンジニアとしての学習メモを兼ねています。
誤りや補足があればコメントいただけると嬉しいです。