kansiho's memo

ruby, python, javascript. Rails, wordpress, OpenCV, heroku...

cookieとsessionとセッションハイジャック

f:id:serendipity4u:20170417172047p:plain

前提

HTTPはステートレス(=ステートがない)プロトコル.

一気に与えられた情報に対して返却するだけで、記憶というものがない.

いま接続してるのがさっきの接続と同じ人物なのか

今までどういう行動(カートに商品入れるとか)をしていたのか 

もうログインしたのかどうか

サーバー側はな〜んもわからない.

ということで

クライアント側で記憶の部分を担うようになった

のがcookie.

サーバーは、レスポンスのさい、ヘッダに Set-Cookiを付与することで、「クライアント側の君が、これを覚えておいてくれよ」と指示する

そして次から、クライアント側は同じサーバーにアクセスするときそのcookieを一緒にリクエストに含める.

その固有な値を見てようやくサーバー側は, ああ昨日も来てたあいつね〜, となる.

cookieとは何か

  • クライアント側(ブラウザ)で保持する情報.
  • つまりクライアント側で改変可能.

ログインする際に毎回パスワードを入力する必要がなくなるという仕組みは、cookieによって実現している.

セッションとは何か

  • ブラウザを閉じるまで保存される

  • サーバー側に値は保存されている

  • sessionのIDをサーバーに渡すことでサーバーがクライアントに値を返す

  • セッションのIDはcookieでクライアント側が保持する

  • クライアントはサーバにアクセスする際に、このセッションIDをヘッダ情報として送信

  • クライアント側から改変することはできない

セッションハイジャック

  • 通信の当事者でない第三者(攻撃者)が何らかの手段でセッションIDを知ることにより、セッションを乗っ取る攻撃手法.
  • ユーザがログインした後に攻撃者がセッションIDの奪取に成功すれば、攻撃者がユーザのパスワードを知らなくともセッションを乗っ取って不正をはたらく事が可能.

以下, セッションIDの方法3つ.

セッションIDの推測

連番、メールアドレスなどからセッションIDを推測する.

セッションIDの盗難

セッションIDがURLに埋め込まれている場合:標的ユーザーの使っているSNSのセッションを抜きたい時, SNSから自分の管理するサイトに飛ばすことができれば, request.refererからその直前にいたSNSのセッションIDが判明する.

セッションID固定化攻撃

何らかの不正な手段を用いて(cookie書き換えたり)被害者のブラウザに攻撃者が用意したセッションIDを保存する. 例えば古いシステムで, ログインする前にセッション ID を発行し, ログイン後もセッションIDを変更しないものがたまにある. そういうシステムのもとで, 攻撃者が発行したセッションIDを利用しながら被害者がログインしてしまうと, 攻撃者はそのセッションIDを使って被害者の権限を利用できる.

じぶんのcookieを確認する

今いるページのなら, コンソールで, document.cookieで表示できる.

ブラウザのが全部見たかったら, chromemacの場合, ~/Library/Application Support/Google/Chrome/Profile 1/Cookie とかから見れる.