HTTPに関するセキュリティリスクについて（その４）
前回の記事「HTTPメッセージのレスポンスヘッダによるセキュリティ対策」
■ Cookieに対するセキュリティについて
Cookieの利用目的は主にセッション管理やユーザーのページ設定の保存、ユーザーの行動記録の用途に使用され、情報はブラウザに保存されています。
しかし、Cookieの脆弱性に対するリスクやGDPRなどによる個人情報保護の観点からsafariやFirefox、iOSでトラッキング防止や事前同意などの対応が行われています。
日本でも2022年の改正個人情報保護法施行によりCookieを利用したトラッキングの事前同意が義務化される見込みとなっています。
トラッキング機能だけに限らず、Appleは2020年3月に「Safari」でのサードパーティCookieをデフォルトで全面的にブロックしています。
また、Googleの「Chrome」も2023年末にサードパーティCookieを廃止する計画をしています。
サードパーティCookieはユーザーが見ているサイト以外の他サイトのCookieを取得して利用できるものです。例えばユーザーが見ているページに貼られている広告は広告配信サイトから発行されたCookieを使って広告を選別しますが、そのCookieをユーザーが見ているページのサイトも利用してユーザーのターゲティングに活用できます。
今後は自社サイトが発行したファーストパーティCookieを活用していくことになりそうですが、Appleは「Safari」のITP2.3から「1stパーティクッキーの有効期限が7日間。トラッキング目的のトラフィックはクッキーが24時間で切れることに加えて、クッキー以外のストレージデータも最大7日間で無効となる」としました。
（JavaScriptで発行されたファーストパーティCookieは有効期限が1日以内）
Webブラウザのバージョンアップにより、ある日突然、KPIが下がったりログインできなくなったりする事態が自社の運営するWebアプリケーションで発生するかもしれません。
今後、主ブラウザの各社による対応を注視していくことが必要になってきます。
◇ Cookieの設定に対する対策
・Cookieに設定できる属性
・利用者が悪用するリスク
Cookieはテキストデータでブラウザ毎に保存されますが、利用者自身は全てのCookieを見ることができ、変更することが可能です。
重要な情報は暗号化されたテキストで保存されていますが、この暗号化のアルゴリズムの強度が弱く解析されてしまった場合は悪用されることがあります。
例えば、CookieにユーザーIDからセッションIDを生成したものを暗号化して保存しており、セッションIDの検証のみでセッションが確立できる場合は、攻撃者がユーザーのIDを取得もしくは推測できてしまえば自分でセッションIDを生成しユーザーになりすましてアクセスすることができてしまいます。
セッションIDは生成アルゴリズムに暗号論的疑似乱数生成器を用いるなどして予測困難なものにするか、セッション管理の仕組みが提供されている環境であれば自前でセッション管理を構築しようとせずにそういった仕組みを活用ことも検討したほうが良いでしょう。
・Cookieが流出するリスク
expires属性とmax-age属性
Cookieの有効期限が短いほどリスクは低くなるのでこれらの属性を使用して適切な有効期限を設定します。指定が無い場合はCookieが一時キャッシュに保存されているのでブラウザが閉じると消えます。
domain属性
domain属性は指定しない状態が最も安全です。複数サーバに生成したCookieを送信したい場合にCookieを生成したサーバのドメインを指定することで同じドメインの他のサーバとCookieを共有することができますが、情報漏えいのリスクが高くなるので指定しない方が良いでしょう。
path属性
path属性はディレクトリ毎に異なるCookieを送れるなどの場合に使用できますが、特に安全性やセキュリティリスクを高めるなどの影響はありません。
secure属性
HTTPS通信を利用していてもsecure属性のついていないCookieはHTTPS→HTTPの通信では平文で送信されるため盗聴のリスクがあります。
secure属性を指定することでHTTPS通信のときだけCookieを送ることができますが、HTTPとHTTPSが混在しているWebアプリケーションではページによっては動かなくなることもあるので注意が必要です。
サイト全体がHTTPSで作られているのであればsecure属性はデフォルトで設定しておいたが良いでしょう。
HttpOnly属性
HttpOnly属性をつけたCookieはJavaScriptから参照できなくなります。クロスサイトスクリプティングでは攻撃者がCookieに設定されたセッションIDをJavaScriptを使って盗み出すためHttpOnly属性をつけることでこの
攻撃を防ぐことができます。
セッションIDをJavaScriptから参照しなければいけないケースはあまりないので基本的にセッションIDにはHttpOnly属性を付けるようにしたほうが良いでしょう。
SameSite属性
SameSite属性はCookieを生成したサイトとは別のサイトからのリクエストによるCookie送信を制御します。
SameSite属性のパラメータ：
GoogleはChrome 80（2020年2月） からSameSite属性のデフォルトを次のように変更しました。
変更前：None
変更後：Lax
外部サイトからの全てのリクエストに対してCookieを送るようにする場合は、SameSite属性を「None」にしたうえでsecure属性を付ける必要があります。そのため外部サイトからHTTP通信でのアクセスではGETリクエスト以外はCookieが送られることがなくなりました。
Firefox 79以降、SafariではIPTの機能によりブロックされています。
（EdgeはChoromeベースなので実装済み）
サードパーティCookieは「SameSite=None」でかつ「secure属性がついている」状態でHTTPS通信により送られていなければアクセスができないということになります。
このように外部サイトからのアクセスによるCookie送信を制御することにより、CSRF（クロスサイト・リクエスト・フォージェリ）対策につながります。
Cookieに関してはブラウザ側の仕様変更によってアップデートすると挙動が変わってしまうことがあるので、主要なブラウザのリリース情報はこまめにチェックしたほうが良いでしょう。
次回：「CORS（Cross-Origin Resource Sharing）について」
その他、情報セキュリティに関する記事リンク
国家資格になった情報処理安全確保支援士を会社に所属させるメリットについて考える
情報処理技術者試験の勉強まとめ記事一覧はこちら↓
【情報処理技術者試験に役立つ！】用語と解説をまとめたリンク集（PDFデータ付き）
投稿
0 件のコメント:
コメントを投稿