まさ@ブログ書き込み中

自由に生きるための英語、プログラミング、考えごとについて色々書いています。

セッションの基本を学び直す【Web技術入門の復習】

 

こんにちは、メルカリで1万円で手に入れたiPhone5sが壊れたまさです。

一昨日画面が外れたんですよね。パカっと。

その時はカチッとはめ直して終わったと思ったんですが、ついに2時間前、電源がつかなくなりました。

 

でもさっき一瞬だけついたんですよね。

ω・`)チラ

って感じで。

 

また金がかかると思うとちょっと憂鬱です。

 

話は逸れましたが、今回は久しぶりのISUCON的な、Webの技術あたりの話をまとめていきたいと思います。

 

中でも僕がもう少し知りたかったCookieやセッション、そして『Web技術入門』の1週目で(効率的に読むために)飛ばしていた第7章の内容をまとめていきます。

 

 

セッションの理解が浅かった

僕は8ヶ月前にCookieとセッションについて一度まとめているんです。

masa-world.hateblo.jp

 

今回改めて学び直してCookieの理解は間違っていなかったのですが、セッションの理解が浅かったなと思いました。

 

Cookie

Cookieとは、Webサーバ側から渡される証のようなものです。

 

プログラムを書けば、WebサーバからWebブラウザに対してHTTPレスポンスのヘッダを利用して小さな情報を送ることができます。

 

それ以降、同じWebサーバにHTTPリクエストを送る際にはそのWebブラウザは以前受け取ったCookieも一緒にWebサーバに送るのです。そうすれば、Webアプリケーション側はリクエストを送った相手がどんな相手なのかを知ることができます。

 

このCookieを利用する仕組みがあれば、ログインをちゃんとしないでCookieをWebサーバから受け取っていない、URLを直接入力する輩はそのページにアクセスすることを防ぐことができます。

このままの理解で問題なさそうなんですが、

 

セッションについては

セッションIDとは、銀行で色々な手続きをする際に貰う受付番号のようなものです。

 

銀行の窓口の方は私の名前や口座番号などの個人情報はわかっていますが、私を呼ぶときに名前で呼ぶことはありませんし、ましてや口座番号などで呼びません。ただ受付番号で呼びます。このシステムでセキュリティが守られているのです。

 

セッションIDを渡すプログラムをWebアプリケーション側でつくっておけば、WebブラウザがCookieを受け取る際にセッションIDも一緒に受け取ります。そして、我々クライアント側から見れるのはセッションIDのみ。これで大丈夫ですね。

と、あたかもセッションはCookieの内容を露出しないためのもののようにまとめてしまいました。

 

もう一度調べ直すと、セッションIDは(銀行の窓口の例でいう)「受付番号」というプライバシーが守られ、かつユーザーを特定するためのものだけではなく、Webサーバ側がコンピュータのメモリやデータベースを使ってセッション(一連の処理の流れ)を管理するためにも必要だったんですね。

 

銀行の例で言えば受付・口座開設・手帳受け渡しなどのToDoをまとめたチェックシートみたいなやつがセッションで、受付番号がセッションIDですね。

セッションID

受付

口座開設

通帳受け渡し

Ifj302xxi

OK

OK

 

F2l0efirv

OK

 

 

 

 

セッションIDを守るには

ただ、セッションIDさえもWebインスペクタとかで簡単に見えてしまいます。そのセキュリティの部分をどうやって担保すべきなんでしょうか。

 

実際、セッションIDがバレてしまうとそのセッションIDを使ってあるユーザになりすますことは出来てしまうみたいです。これを狙ってセッションIDを盗み取ろうとする行為をセッションハイジャックと言います。

 

しかし、セッションハイジャックができるだけしづらいような対策も考えられています。本書の第7章ではそれらの対策を大きく分けて

  1. XSSクロスサイトスクリプティング)対策
  2. 通信経路の暗号化
  3. セッションタイムアウト値の変更
  4. セッションIDのランダム化

があります。1つずつ簡単に見ていきます。

 

 

XSS対策

XSSクロスサイトスクリプティング)とは「HTMLの中に悪意のある動作をするJavaScriptを埋め込む攻撃手法のこと」らしいです。JavaScriptインジェクションとも呼ばれるそうな。

 

JavaScriptはWebサーバからのレスポンス(HTML)の中に埋め込まれ、Webブラウザに実行させることができますが、悪意のあるスクリプトが実行されるとクッキーの盗難やページの改ざんなどが実行できてしまいます。

 

詳しい例は以下のサイトで紹介されていますが、要するにある攻撃者がフォーム欄などに悪意のあるスクリプトを書いた場合、Webサーバから渡されたセッションIDが攻撃者のサイトにセッションIDをクエリパラメータとしてリダイレクトさせたりするなどして盗まれてしまうみたいです。

www.websec-room.com

 

XSSの対策としてはHTMLへ文字列を出力する際に「サニタイジング(Sanitizing)」というHTMLで使用される特殊文字文字参照に置き換える処理をすれば良いみたいです。

 

このサイトがわかりやすいです。ただ、そうなるとサイト側が用意した(悪意のない)JavaScriptはどうなるのか気になりますが、今回はここで止めておきましょう・・・。

サニタイズ (sanitize)とは

 

 

通信経路の暗号化

サニタイジングをするようにして、XSS対策をしたとしてもインターネットを流れる通信を盗聴されては意味がありません。そこで通信路を「SSL(Secure Sockets Layer)」によって暗号化することが有効らしいです。

 

ちなみに、SSL/TLSとかっていう表記を見たことがあると思いますが、SSLNetscape Communications社の独自規格でしたが、後にIETF(Internet Engineering Task Force)によってTLS(Transport Layer Security)という名称に変更されました。実はCookieも同じようにNetscape Communications社の独自規格で、IETFに標準化されたとか。

 

HTTPS通信はこのSSL/TLSを通信路として使っているみたいです。

 

 

セッション・タイムアウト値の変更

セッション情報は明示的に破棄されない限り、タイムアウトが発生するまでサーバ側に保持され続けます。ログアウト操作をしたらセッションを破棄することはあると思いますが、ユーザがログアウト操作を忘れてしまった場合などは、セッション・タイムアウトが発生するまでセッションIDが有効となります。

 

これではセッションIDが何らかの方法によって盗まれる確率も高まります。

 

よって、Webアプリケーション側でセッション・タイムアウトの時間を短めに変更することがセッション・ハイジャックの対策の一つとして考えられます。

 

 

セッションIDのランダム化

この記事の前半にも言いましたが、セッションIDはただのID(英数字)でバレてしまうと簡単に悪用されてしまいます。たとえば「1, 2, 3...」というように順番に発行したら容易に推測されてしまいます。

 

なので十分な桁数でランダムに作成する方法によってセッションIDの複雑化を図ります。

 

ちなみに、「大切な情報のランダム化」と言えばパスワードをハッシュ関数にかけたpassword digestを思い浮かべる人もいるかもしれませんが、ハッシュ関数は暗号化ではなく、一方向性(パスワード(メッセージ)ダイジェストから元のデータを特定できない)といった性質を持っているそうです。

 

Railsのセッションは以下のように作られているみたいです。

通常、セッションを構成する要素は、値のハッシュとセッションidです。セッションidは32文字の文字列で、ハッシュを特定するために使用します。

Rails セキュリティガイド | Rails ガイド

 

 

 

今回はここまで。

今回の学びを通して、よりセッションについて理解が深まったと思います。

ではまた。