注意
僕は少しセキュリティ についてかじり出した初心者です。
間違った情報を書いている可能性があるので、コメントで教えていただけると幸いです。
ちなみに徳丸本を参考にしています。
はじめに
当たり前のことなのですが勉強も兼ねてアウトプットします。
本題の前にクッキーとセッション変数についてそれぞれ簡単に説明します。
クッキー
クッキーの中にはデータを保存しておくことができる。しかし値の個数や文字列の長さに制限がある。さらに利用者本人から参照、変更可能ということもあり、クッキーは秘密情報の格納に向かない。
セッション変数
上記で説明した通りクッキーは秘密情報の格納に向いていません。
そこでwebサーバー上でセッションidを生成し、セッション変数に保存します。
そのセッション変数をクッキーに保管するという形でweb ブラウザに状態を持たせます。
セッション管理安全でないところ
それは漏洩してしまう可能性があるという事です。
その原因は主に5つあります。
- クッキー発行の際の属性に不備
- セッションidの盗聴
- クロスサイト・スクリプティングなどアプリの脆弱性による漏洩
- プラットフォームの脆弱性により漏洩
- セッションidをURLに保持している場合はRefererヘッダから漏洩する
#それぞれの対策
今回は一つ目のみの対策を書きます。
二つ目以降は正しく理解したのちに執筆します。
クッキー発行の際の属性に不備
クッキーにはいくつか属性をつけることができ、その中のDomain属性とHttpOnly属性、加えてSameSite属性が漏洩の原因につながりやすいです。
Domain属性
まず一つ目のDomain属性ではサーバーを指定することができます。何も指定していなければクッキーをセットしたサーバーでしか使えないのでこれが安全です。サーバーを指定することでそのサーバーでもクッキーを利用できます。（複数指定可）不用意に多くのサーバーを指定してしまうと脆弱性の原因になるので気をつけましょう。
HttpOnly属性
二つ目HttpOnly属性ではJavaScriptからアクセスできないクッキーを設定する事です。
格納されたセッションidを盗み出すにはクロスサイトスクリプティングという攻撃手法を使います。
HttpOnly属性をつけておくとクロスサイトスクリプティング攻撃を難しくすることができます。
SameSite属性
三つ目はSameSite属性はcsrfの脆弱性対策で追加されました。
これをLaxと指定することでそのクッキーは他のサイトから遷移した場合は送信されなくなる。
しかしこれは根本原因の対策にならない。
そちらの対策も別途記事にする。
感想
完璧に安全を確保するというのはできない。でも脆弱性対策をすることで少しでも安全なアプリケーションにすることで安心してユーザーが使えるようになるのでしっかり理解してものにしていきたい。そう思った。