やる気がストロングZERO

やる気のストロングスタイル

こんなセッションIDは嫌だ

ログイン周りってだいたい既に出来上がってて自分で実装したことなかった。
知識としてはなんとなく知ってたけど「俺が考える最強の契約管理システム」でもログイン機能つけないといけないなーと思ってセキュリティを含めて改めて勉強したのでメモ。

参考)まだ前半しか読んでないけど、説明が丁寧で読みやすくて、内容自体も面白いしおすすめです。

ログイン状態はセッションIDで管理してる

ログイン状態の保持は、ブラウザではcookieとsessionを使って実現してる。

A君がログインページでログイン認証が成功したら、サーバー側のsession情報にA君のuser_idを覚えさせる。

session_id data
1 user_id = 10 (A君のid)
2 user_id = 121(他の人のid)

そして、ブラウザのcookieにsession_id = 1を覚えさせる。

A君が自分のプロフィールページにアクセスするとき、ブラウザはcookieをサーバーへ送出する。

ブラウザは受け取ったcookieの中からsession_id = 1を見つけ、それを使ってsession情報からuser_id = 10を見つける。

ブラウザはuser_id = 10のプロフィール情報を表示したページをブラウザへ返す。

セッションIDがバレるとマズい

ここで、B君が何らかの方法でA君のsession_idが1であることを知ったとする。

B君は自分のブラウザを操作してcookieにsession_id = 1をセットし、サーバーへアクセスすると、、

ブラウザは受け取ったcookieの中からsession_id = 1を見つけ、それを使ってsession情報からuser_id = 10(A君のid)を見つける。

ブラウザはuser_id = 10の(A君の)プロフィール情報を表示したページを(B君の)ブラウザへ返す。(情報漏えい)

だからセッションIDはバレてはいけない。

こんなセッションIDは嫌だ

プロトコルがHTTPだ

HTTPは暗号化されていないのでネットワーク経路上でsession_idが丸見えだ。
HTTPSであれ。

URLに付加されている

こんなやつ。
https://example.com/your_profile/?session_id=xxxxxxxxx

ブラウザをのぞき見たり、履歴からセッションIDがバレる。

他にも、B君がA君にこのurlを踏ませてログインさせることで、B君はA君のセッションIDがxxxxxxxであることを知っている状態になる。
※ただしサーバー側がログイン時点でセッションIDを変えていたら漏洩は防げる

セッションIDが連番だ

セッションIDがログイン順に連番で発行されていると、セッションIDを予測することが出来る。
例えば、B君がログインしてセッションIDが10だったので、その後ログインしたA君のセッションIDは11だろう、と予測が出来てしまう。
セッションIDは予測出来ないものでないといけない。

「予測できない」というのを自前で用意するのは難しい。
このあたりは暗号まわりと関連が深くて「自前で仕組みを作らず、用意されている仕組みを使え」という感じ。

関係ないサイトにもセッションIDが送出されている

アマゾンへ送出されるべきセッションIDが楽天へ送られてしまうと、楽天の人にセッションIDがバレてしまう。

通常はドメインで送出先が制限されているのでそんなことは起こらないが、
設定によっては、example.comへのセッションIDが、a.example.comへも送出されることはある。

仮にレンタルサーバー事業者などで、a.example.comが別の管理者のサイトになっている場合、
example.comのセッションIDがa.example.comの管理者にバレる事になる。

逆に、関係ないサイトのセッションIDを送出してしまうケースがある。
クッキーモンスターバグ」というバグが原因で、無関係のサイトのセッションIDを送出させられることで、セッションIDを強制させられ使用セッションIDがバレるというケースもある。

ログイン先サイトが脆弱だ

ログイン先のサイトのセキュリティ意識が低いと、様々な方法でセッションIDを知ることが出来てしまう。

攻撃者が用意したurlを踏ませるだけでセッションIDがバレてしまったりする。