[情報SEC]第８回 セッションハイジャック

第８回　セッションハイジャック

言葉からするに、セッションを乗っ取るということのようです。
セッションとは、通信のつながりのこと。
電話と同じです。

受話器とって、電話番号打って(選んで)、通信ON。
相手が出るのを待つ。
出たら、もしもし。相手が目的の人かどうか確認して(相手も確認して)お話開始。

で、終わったら、じゃあね。とお話の終わりを確認して、電話を切る。
この電話がつながって切られるまでがいわゆるセッションです。
これはTCPで使われます。

UDPの場合は送りっぱなし。
黙って帰ってくるのを待ちます。
もし、相手が返せないようなら、そんなポートないとエラーを返してきます。

って、これメールですな。
送りっぱなし。黙って返事待ち。
もし返せない(アドレスがない)なら、エラーを返してくる。

そうか、メールはUDPで、電話はTCPか。
おもろいの。
この二つの手順は通信の基本だしの。(TCP/IPだけではなく。)

そーいや、最近通信といえばTCP/IP(UDP/IPとはいわんの。)だけど、
ぼくが勉強してた頃は他にもいくつもあった。
すっかり姿を消してしまったの。ちとさみしい気もするが。ただしい気もする。

えーっと、以上前ふりです。
TCPのセッションハイジャックとはこの電話をむりやり本当の相手から奪って、
あたかも、本当の相手かのように振る舞い相手をだます。

UDPの場合も一緒で、メールの返事を本物よりも先に返すことによって、
相手との情報のやりとりを奪うもの。
おおざっぱかの。本当のところ知りたい人はちゃんと勉強してください。

でもこの話をとっかかりに通信手順の図を見れば少しは雰囲気つかめるでしょう。
あと、arpのセッションハイジャックも簡単に。
arp(あーぷ)とは、IPアドレスからMACアドレスを調べる通信手順。

けどこれいちいち調べるのもめんどくさいので、一度調べたものは、
自分自身で覚えておきます。
windowsでもコマンドプロンプトでarp -a と打てば出てきます。

で、arpのセッションハイジャックはこの情報をうその情報に書き換えるというものです。
このあたりは通信を制御するOSも対策をいろいろ凝らしているので、
最新のにしとけば、大概問題ありません。

さて、最後に今一番興味を持たれているセッションハイジャックについて。
Webのセッションハイジャック。
Webでのセッションとはこれまでのセッションとはまったく違うものです。

Webは一枚のWebページ(html)をダウンロードすると通信が終わります。
http1.1では、画像なども同一セッションで取得することもあります。が...
まあ、よいです。いずれにせよページ構成要素を取得すると通信が終わります。

セッションが切れます。
認証なんて不要だった古き良き時代はこれでよかったのですが...
例えば、銀行にログインして、振り込みページ行って、振込先選んで...

その間に何度も通信をしなければなりません。
ユーザにページが変わるたびにログインさせるわけにもいきませんので、
これを何とかする必要があります。

すでにログイン済みであることを相手(サーバ)に自動的に知らせる必要があります。
この手段として一般的なのは、cookie,URL,hiddenフィールド(form)に
これを入れておくようにする方法です。

しかしまあ、このいずれも見ようと思えば誰でも見れるので、
そのままID・パスワードを生で入れておくようなタコなシステムは作ってはいけません。
Webの初期の頃はhiddenにID・パスワードが生で入ってるタコなシステムがいくつもありましたが。

hiddenは最低です。セキュリティ的にというよりは、プログラミング的に。
かなりかっこわるいです。しかも全部のページにhidden入れねばないので面倒です。
途中にリンクでのページ移動があるとセッションが消えます！。...さいてー。

URLもブラウザの上んところに露骨に出てます。
出てるんだけど、携帯とか(今のは使えんのか？)cookieが使えないシステムの場合、
しかたなく使うこともあります。

cookieは比較的ましです。
ブラウザ閉じれば消えるようにすることができるからです。
できるというのは、ブラウザ閉じても消えないようにすることもできるということです。

現に、一度ログインしたら一週間くらいはログイン不要でつながるサイトとかもありますし。
こういうのは、ブラウザのcookieみればセッション情報とれます。

IE6.0(&WindowsXP)の場合、ここに入ってます。
￥Documents and Settings￥ユーザ名￥Cookies
テキストファイルなので、開いてみてください。山ほどあるでしょう。

で、これをごそっと持っていって、調べてみればID,パスワードが分かるかもしれません。
でも分かったらそれはかなりタコなシステムです。
通常はID・パスワードなんてcookieに入れません。上述の通り危険なので。

そもそもcookieだろうが、hiddenだろうが、インターネット上を生で通ることには変わりません。
社内システムで、性善説に立つのであれば、よいですが、
インターネット上で使うんなら、SSL入れましょう。(めんどーだけど。)

なんか、今日のは長いね。余計なこと書きすぎかの。
さて、ID・パスワードをcookieに入れずに何を入れるのだ。
セッション番号です。

ログインされたら、ランダムに見えるセッション番号をクライアントに返します。
クライアントは、そのサイトを移動するたびにcookieを送ります。(cookieとはそういうもんです。)
サーバはそのセッション番号を見て正しいものかどうか確認します。

単に正しいかどうかだけでなく、その番号からIDが分かるようでないと困るので、工夫します。
方法はいろいろあるのですが、例えばDBにセッション番号とユーザIDが対になってる一時レコードを作って、
セッション番号からユーザIDを調べたり。(DBなしの方法もあります。)

セッション番号の作り方もいろいろ。
単なるランダムだと総当たり攻撃で、運良くヒットすることもあるので、
それを回避したり、毎回違う番号を割り当てるために時間を加えたり。

水神がよく使うのは、ID+クライアントのIPアドレス+認証時刻。
この文字列を非可逆暗号化(いわゆるハッシュ)して、それをセッションIDとして使います。
これだと、IPアドレスまで偽装しないとセッション番号だけ奪っても使えないので。

ちなみにハッシュはMD5を使ってます。
MD5な理由は単にライブラリがそろってるから。
あと、かならず32文字の英数字になるので扱いやすい。(他のも一緒か？)

Webのセッションハイジャックを防ぐ方法は、なんといっても暗号化です。
SSLを使いましょう。
あとは、上述の通り、セッションIDを使い捨て＆使い回し不能＆推測不能にすること。

お疲れ様でした。
水神も疲れました。
次回はもう少し短めで行きます。