脆弱性コラム - 第8回
サイト脆弱性をチェックしよう！ -- 第8回：セッション管理における脆弱性
前回は、情報漏えいにつながる可能性の高い脆弱性について説明した。今回は、セッション管理における脆弱性について説明していく。推測可能なセッションID
HTTPはステートレスなプロトコルであるため、複数の画面遷移を行うアプリケーションでは、セッション管理機能を開発者が作成する必要がある。このセッション管理機能は、以下のようにセッション識別情報（セッションID）を用いて、現在のアプリケーションの状態を把握する。- セッションIDは、ログインなどのタイミングでサーバ側で作成され、ブラウザに送信されます。
- ブラウザはサーバから受け取ったセッションIDをリクエストに含めて、サーバに送信します。
- サーバは、ブラウザから受け取ったセッションIDを元に、現在の状態を把握（セッションを維持）し、適切な処理を行います。
セッションIDが連番など簡単なものである場合、攻撃者は試行錯誤で現在有効なセッションIDを推測し、セッションを乗っ取ることが可能になる。
検査方法
この脆弱性の検査方法は、大量のセッションIDを取得し、その関係を推測する必要があるため、少々大変だ。たとえば、セッションIDに連番やミリ秒単位の時間を基にした数値をそのまま使っていた場合は直ぐに推測がつく。しかし、これらの数値をMD5などでハッシュ化したものを使用している場合は、知識がないと、ただセッションIDを複数取得しただけでは推測できない。
このため、一見すると連番をMD5ハッシュ化した値などは安全のように思えるが、知識があれば直ちに推測可能なので注意が必要になる。セッションID解析ツールには、WebScarabなどがあります。
対策
最も簡単な方法は、セッション管理機能を自作するのではなく、フレームワークやライブラリなどが用意している機能を利用することだ。これらは検証が十分されており、セッションIDの推測が容易ではないので、セッション管理機能を自作することと比較すると安全だ。しかし、セッションIDの推測が可能な脆弱性が発見されることもあるので、使用しているフレームワークやライブラリの脆弱性情報を常に知っておく必要がある。
セッションフィクサーション
セッションフィクサーションとは、ログイン（セッション開始）前に使用されていたセッションIDが、ログイン（セッション開始）後にも同じ値で使用されている脆弱性だ。この脆弱性を利用した攻撃手法は次のようになる。
- 悪意あるサイトやスパムメールにあるリンクをクリックすると何らかの方法を用いてセッションIDを設定する。
- セッションIDを設定した後、ログイン画面を表示する。
- 被害者がログインを行う。
- 被害者がログイン中に攻撃者が1.で設定したセッションIDを使用して、脆弱性のあるサイトにアクセスする。この結果、攻撃者が被害者に成りすまして脆弱性のあるサイトを悪用できる。
検査方法
この脆弱性の検査でも、第5回で説明したHTTP Proxyのような検査ツールを使用する。ログイン前に指定したセッションIDが、ログイン後のセッションIDと同じものが使われているかを確認することで、この脆弱性の有無が判断できる。この検査では、以下のような手順で確かめる。
- ログイン画面にアクセスする。
- ログイン画面で取得したセッションIDを記録する。たとえば、セッションIDを示すCookieの「sessionid」が「12345678」と設定されてHTTPレスポンスに含まれているとする。
- 他のPC（他のIPアドレスをもつPC）で、セッションIDに2で記録したセッションIDの値を設定して（たとえば、sessionidを12345678と設定)、ログインを行う。
- ログイン後に取得したセッションIDを確認する。3.で設定したセッションIDの値と同じであれば、脆弱性がある可能性が高い。たとえば、ログイン後の「sessionid」が「12345678」であれば、設定した値と同じであるため、この脆弱性がある可能性がある。
- 実際にセッションハイジャックが可能であることを確認するために、2.で使用したPCで、取得したセッションIDを設定後、ログイン後の画面にアクセスする。アクセス可能であれば、脆弱性があると判断できる。
対策
この脆弱性は、ログインの前後でセッションIDが同じであることが原因だ。そのため、最も簡単な対策はログイン前とログイン後でセッションIDを変更することだ。しかし、アプリケーションの仕様によってはログイン前に格納したセッション変数をログイン後にも使いたいために、セッションIDを変更したくない場合がある。このような場合には、セッションIDとは別にログイン成功時に認証したことを表す秘密情報を発行する。そして、発行された秘密情報をサーバ側で記録しておき、ログイン状態の確認には、発行した秘密情報とブラウザから受け取った秘密情報が一致するかどうかで行います。
クロスサイトリクエストフォージェリ
クロスサイトリクエストフォージェリ（CSRF）は、対象のアプリケーションでセッションを維持しており、かつ他のサイトを閲覧していた時などに、そのサイト内にあるリンクをたどると、ユーザーの意図には関係なく、対象のアプリケーションでの商品の購入やパスワードの変更といった処理を勝手に行ってしまう問題だ。たとえば、以下のような画面遷移を行うアプリケーションがあるとする。
ログインしている（セッションを維持している）状態では既に「画面A→画面B」のリクエストaが送信される。この状態で、ユーザーが別のサイトを閲覧する。このときに別サイトにあるリンクをクリックするなどにより、リクエストdを送信すると（ログインしている状態であるため）リクエストdで実行される処理をユーザーが意図せず実行してしまう。その結果、パスワードが変更されたり、商品が購入されるという被害が発生する。
検査方法
CSRFの検査は、実際にセッションが有効な状態で、実際に処理を実行するリクエストを送信し、想定どおり処理が行われているかどうかを確認することだ。先の例であれば、ログインしている状態で、リクエストdを送信し、パスワードの変更や商品の購入などの処理が行われているかどうかを確認します。これらの処理が行われている場合、脆弱性があると判断できます。対策
CSRF対策の基本は、実際に処理を行うリクエスト（例ではリクエストdとなる）が、ユーザーが意図したとおりに行われたものかどうかをアプリケーションで判断することだ。その判断は、攻撃者が推測できない情報をリクエストに付加することで可能になる。具体的には、以下のいずれかを正しく行うことだ。詳細については、「開発者のための正しいCSRF対策」に詳しく書かれている。
- ワンタイムトークンを使用する。
- パスワード認証を行う。
- CAPTCHAを使用する。
たとえば、10個のURLと各URLにパラメータが10個ずつあるとすると、10×10＝100個の検査をひとつの検査パターンについて実施しなければならない。このため、検査パターンが10個（検査パターンはURLエンコードなどを含めると非常に多く存在します)あったとすると、100×10＝1000パターンの検査を実施しなければならないため、人の手による検査では非常にコストがかかってしまう。
そこで、検査コストを抑えるために、AppScanのような自動検査ツールが必要になる。次回は、AppScanを例とした自動検査ツールによる検査手法について説明する。
イベント・セミナー
ニュース・キャンペーン
AppScanに
関するお問い合わせ
テクマトリックス株式会社
東京本社ネットワークセキュリティ事業部
第3営業部
セキュリティプロダクツ営業2課03-4405-7814
- メールでのお問い合わせ
- watchfire@techmatrix.co.jp