 |
|
|
| 前のページ 1 2 3 4 次のページ
|
|
| セッションIDへの攻撃
|
正規ユーザのセッションIDを攻略するには「推定」「傍受」「強制」の3通りの攻撃方法がある。ここではまず「推定」および「傍受」の2つについて解説する。
|
| セッションIDの推定
|
以前、あるサイトではHTTP CookieにユーザIDの値が入っているかどうかでセッション管理を行っていた。ユーザがログインすると、そのユーザIDをHTTP Cookieに設定することによってユーザがログイン済みであることを表していたのである。
Set-Cookie: userid=hasegawa
この方法の恐ろしいところは、誰かのユーザIDをCookieにセットしてサイトのページにアクセスに行くと、それだけでその人物専用のページを見ることができてしまう点だ。パスワードの入力を求められることもない。
これほど極端な例は少ないかもしれないが、有効なセッションIDの値について容易に見当がつく場合がある。あるサイトでは十数桁のセッションIDが使われていたが、新しく発行される値が単調に増加する値であったため、数件ないし数十件試行錯誤すれば誰かの有効なセッションIDに行き当たるという脆弱性を持っていた。
1113310000872322
1113310000872324
1113310000872328
1113310000872336
…
これらの推定が容易なセッションIDは、いずれもWebアプリケーションが自前のロジックでセッションIDを発行していた例である。
ASP、Java Servlet、PHPなどのWebアプリケーションエンジンは、アプリケーションプログラムの側で細かなロジックを組まなくても、比較的推定が困難になるランダムな値によるセッションIDの発行をサポートしてくれる。それらの機能を使った方が、たいていの場合自作よりも安全だろう。
|
| セッションIDの傍受
|
これは、ネットワーク盗聴などの手口により、現に使用しているセッションIDが傍受される問題である。
Webアプリケーションがセッションを維持している間、ブラウザからWebサーバへのセッションIDの送信が毎回行われている。もしそこでSSL（Secure Socket Layer）による暗号化通信が行われていない状況でセッションIDが通信に乗っていると、第三者にそのセッションIDを知られる怖れがある。
特に、ASPやJSPのような高機能のスクリプト系Webアプリケーションエンジンについては要注意だ。これらの処理系では、ブラウザから最初のアクセスが行われた時点で有無を言わさずセッションIDが発行される。サイトのトップページではSSLを使わないことが多いから、その時点でセッションIDがネットワークに露出する。
その後ユーザをSSLを用いたページに誘導したとしても、すでにセッションIDは一度平文でネットワークに露出してしまっており、抜け目ない攻撃者はすでにそのセッションIDを傍受しているかもしれない。
図3：非SSL区間におけるセッションIDの暴露
- 非SSLのコンテンツを提供するWebサイトとSSLのコンテンツを提供するWebサイトを完全に分ける
- 同じサイトにSSLのページと非SSLのページを混在させる場合、ユーザがログインしたらSSLのページに誘導し、そこでまったく新しいセッションIDを再発行する（図4）
図4：ログインしたらセッションIDを付け替える
Set-Cookie: 名前=値; path=/パス; domain=ドメイン; secure
|
前のページ 1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
セントラル・コンピュータ・サービス株式会社 長谷川 武
シニア・セキュリティ・スペシャリスト、IPA 非常勤研究員。2002年にはIPA ISEC『セキュア・プログラミング講座』の制作ディレクターをつとめた。これを契機に、現在は勤務先とそのパートナー企業を通じてセキュアプログラミングセミナー／実習／スキル評価テストといった教育サービスを「TRUSNET(R)アカデミー」として提供している。問い合わせE-mail：info@trusnet.com。
|
|
|
|
|
|
