Written by 岩井 駿弥
セキュリティエンジニアとして、Webアプリケーションやスマートフォンアプリケーション、ゲームの脆弱性診断に従事。
目 次
パスワードレス認証とは、IDやパスワードを使わずに、FIDO2やPasskeyなどの専用認証デバイスを用いて本人確認を行う方式です。
指紋認証や顔認証などの生体認証も、このパスワードレス認証に該当します。
パスワードレス認証は、認証情報が盗まれるリスクが低いセキュアな方式であるとして、近年注目を集めています。
このような変化から、認証情報の保護のためにパスワードレス認証を導入し、セキュリティ強化を図る企業が増加傾向にありますが、その一方で「認証後」のセッション情報を狙った攻撃も依然として存在します。
そのため、不正アクセスを防ぐには、認証方式を強化するだけでなく、認証後のセキュリティ対策も欠かさずに行う必要があります。
本記事では、この「認証後」を狙う攻撃に対して有効な対策方法を解説します。
はじめに
FIDO2やPasskeyなどのパスワードレスの認証方式を導入すると、ログイン時のパスワード盗難のリスクは大幅に低減できます。
しかし、多くのWebシステムでは依然として、ログイン後の状態を維持するために「セッションCookie」を利用しています。
攻撃者は、このセッションCookieの不備を悪用して、「セッションの乗っ取り」や「クロスサイトリクエストフォージェリ（以下、CSRF）」といった認証後を狙った攻撃を依然として仕掛けてくる可能性があります。
CSRFとは、Webアプリケーションへのリクエストを偽装することで、ユーザーが意図しない処理を実行させる脆弱性のことで、この脆弱性を悪用した攻撃を「CSRF攻撃」と呼びます。
こうした攻撃を防ぐ上で鍵となるのが、「Cookieの属性設定」です。
本記事では、この「Cookieの属性設定」に焦点を当てて解説します。
Cookieの基本属性
Cookieの属性設定を理解する上で、特に押さえておきたい属性は以下の3つです。
| 属性 | 内容 | 対策できる攻撃 |
|---|---|---|
| Secure | ・HTTPS通信時のみCookieを送信する | ・Cookieの窃取 |
| HttpOnly | ・JavaScriptからCookieを読めなくする | ・クロスサイト・スクリプティング（XSS） |
| SameSite | ・他サイトからのリクエストに対してCookieを同送するかを決める | クロスサイトリクエストフォージェリ（CSRF） |
Secure属性は、「HTTPS通信のときだけCookieを送る」という指定で、平文通信（HTTP）によるCookieの盗難を防ぎます。
HttpOnlyは、「JavaScriptからCookieを読めなくする」指定で、XSS攻撃によるトークン窃取を抑えることが可能です。
そしてSameSiteは、「他サイトから送られてくるリクエストに対して、Cookieを同送するか」を決めるもので、CSRF対策の要となる重要な属性です。
このほかにも、PathやDomainでCookieが適用される範囲を限定し、Max-AgeやExpiresで有効期限を短くしておくことも大切です。
Cookieの適用範囲が広かったり、有効期限が長すぎたりすると、その分だけリスクも拡大してしまいます。
SameSiteの選び方
SameSite属性は、「他サイトから送られてくるリクエストに対して、Cookieを同送するか」を決めるための設定です。
適切に設定することで、ユーザーの操作を装って、不正なリクエストを送信するCSRF攻撃への対策が可能になります。（一部ケースを除く）
SameSiteには、以下の3種類があります。
| 種類 | 属性 |
|---|---|
| Strict | ・完全に同一サイトのときだけCookieを送る設定 |
| Lax | ・基本的には同一サイトのみCookieを送る設定 ・例外として、「他サイトから自サイトのトップレベルのGETで遷移した場合」はCookieを送る（フォームPOSTやiframe/subresourceでは送らない） |
| None | ・同一、異なるサイトを問わず、あらゆるコンテキストでCookieを送信する ・CSRF耐性は下がるため、必ずSecureとセットでなければブラウザに拒否される ・CSRF耐性は下がるため、必ずSecureとセットでなければ最新ブラウザに拒否される |
Strictは、「完全に同一サイトのときだけCookieを送る」最も厳格な設定です。
CSRF耐性は高い一方で、外部サイトからのリダイレクトや、ドメインをまたぐSSO（Single Sign-On）環境では動作しない場合があります。
Laxは、「基本は同一サイトのみCookieを送るが、他サイトから自サイトへ直接遷移するGETではCookieを送る」という中間的な設定です。
多くのサイトにとって、セキュリティと利便性のバランスが良好な設定です。
Noneは、「どのサイトからでもCookieを送る」設定で、Identity Provider （IdP）と業務アプリが別ドメインのSSOや、埋め込みウィジェットなどで必要になるケースがあります。
ただしCSRF耐性は低下するため、必ずSecure属性と組み合わせることが前提です。
パスワードレス環境で起こりやすい注意点
認証をIdP（アイデンティティ基盤）、業務は別ドメインのアプリという構成は一般的です。
例えば、社内のIdP（login.company.jp）と外部SaaS（app.vendor.com）を組み合わせたシングルサインオン（SSO）の流れは、まず従業員が外部SaaSのURL（app.vendor.com）にアクセスします。
SaaS側は「このユーザーはまだ認証されていない」と判断し、社内のログイン窓口であるIdP（login.company.jp）へブラウザをリダイレクトします。
ブラウザは別ドメイン（company.jp）に移動し、IdPのログイン画面が表示されます。
ユーザーがPasskeyやFIDO2で認証すると、IdPは自ドメイン用のセッションCookieを設定し、「認証に成功した」という証拠（OIDCの認可コードなど）を添えて、元のSaaS（app.vendor.com）へブラウザを戻します。
このような構成では、SSOのリダイレクト時にドメインをまたぐため、認証関連のCookieには、「SameSite=None」の指定が必要になることがあります。
この対策として、Cookieに以下のような属性を付与する方法が挙げられます。
SameSite=None; Secure; HttpOnly
また、プロトコル標準の防御（OIDCのstateやnonce、PKCE）を必ず有効化しておくことも重要です。
| 属性 | 内容 |
|---|---|
| state | ・リダイレクト往復の「文脈の一致」を保証し、ログインCSRFや応答の取り違えを防ぐ |
| nonce | ・IDトークンが「この認証要求専用」であることを保証し、再利用・置換を防ぐ |
| PKCE | ・認可コードが「このクライアント専用」であることを保証し、コード奪取による不正トークン取得を防ぐ |
推奨されるCookieの属性設定
通常のセッションCookieでは、SecureとHttpOnlyを付与し、「SameSite=Lax」を設定するのが一般的です。
この組み合わせにより、HTTPS通信時のみCookieが送信されるようになり、JavaScriptからの参照を防ぐとともに、CSRF攻撃への対策も可能になります。
また、Pathは可能であれば「/」ではなく機能単位に絞り、Domainは親ドメインに広げ過ぎないように設定することが推奨されます。
さらに、前述の通りCookieの有効期限はできるだけ短く設定し、ログイン直後や権限昇格時にはセッションIDを再発行（ローテーション）することで、乗っ取りのリスクが大幅に低減できます。
一方、SSOなどのドメインをまたぐ認証が必要な場合に限って、必要最小限のCookieのみを「SameSite=None」で短寿命で運用することが安全です。
Cookieの属性設定に加えて行うべき補強策
Cookieの属性設定だけで、セキュリティ対策を完結させるのは十分ではありません。
XSS対策としては、エスケープ処理やContent Security Policy（CSP）の導入、サードパーティスクリプトの削減を行うことで、より強固な防御が可能になります。
またCSRF対策では、フォームにCSRFトークンを付与し、「SameSite=None」を使う箇所では特に厳格に適用することで、認証後のユーザーを狙った不正リクエストを防ぐことができます。
セッション管理においては、以下の対策を組み合わせると効果的です。
- 短い有効期限
- アイドルタイムアウト（一定時間操作がない場合、自動で接続を終了する）
- 条件付きアクセス（端末の準拠や場所に応じた許可）
さらに、「短時間で地理的に矛盾するアクセスが発生した」「失敗ログインが連続した」といった異常を検知できるように、ログの収集と監視を整えておくことも推奨されます。
このような対策を組み合わせることで、Cookieの属性設定だけでは防ぎきれない攻撃にも対応可能なセキュリティ体制の整備が期待できます。
Cookieの属性設定におけるよくある落とし穴
「SameSite=None」を設定したにも関わらず、「Secure」属性を付与し忘れてしまうと、最新のブラウザ （Google Chrome 80以降、Apple Safari 13.1以降など)ではCookieが拒否され、古い環境ではHTTP通信によってCookieが窃取される危険性が高まります。
また、むやみに「None」を指定してしまうと、前述の通りCSRFへの耐性が大幅に低下します。
さらに、Domainを親ドメインに広げすぎると、意図していないサブドメインにもCookieが送信されてしまう可能性があるため、注意が必要です。
有効期限の長いCookieは利便性が高い一方で、実質的に「半永久ログイン」の設定となっていると、万が一認証情報が漏洩した際の影響が、長期化・深刻化するリスクがあります。
また、ログインや権限昇格のタイミングでセッションIDを再発行していない場合は、乗っ取りのリスクが高まります。
ここで挙げた設定は、Cookieの属性設定をする際に見落としがちなポイントです。必ず確認・見直すようにしましょう。
まとめ
FIDO2やPasskeyなどのパスワードレス認証は、認証情報が盗まれるリスクを大幅に低減できるセキュアな認証方式です。
しかし、実際のWebサイトでは「セッションCookie」が利用されているケースも多く、認証後のセッションが攻撃者に狙われるケースも依然として発生しています。
そのため、正規セッションを不正利用されない方法として、「Cookieの属性設定」を適切に行うことが求められます。
Cookie属性の適切な設定は、「送るべきときにだけ、必要最小限で送る」という基本方針を徹底することが重要です。
基本は「Secure属性」「HttpOnly属性」「SameSite=Lax属性」を付与し、SSOなどのドメインをまたぐ認証が必要な場合に限って、必要最小限なCookieのみ、「SameSite=None」を付与し、短寿命で運用することを徹底しましょう。
この設定に加えて、「XSS・CSRF対策」やログ監視を組み合わせることで、パスワードレス環境においても、強固な認証後のセキュリティ対策が可能です。
まずは、自社のCookie設定を棚卸しし、範囲と期限を縮めるところから始めてみてはいかがでしょうか。
おすすめ記事
