Web Application Security Memo

ウェブセキュリティに関するメモ書き

OWASP ZAPのSession Fixation診断は何をしているのか？

※当サイトにはプロモーションが含まれています。

公開日: 更新日:

OWASP ZAP

OWASP ZAPのActive Scanで行っている脆弱性検査の1つである「Session Fixation」の診断が何をしているのか、ソースコードを読んで分かったことを解説します。(v2.2, v2.3.1)

※ まだベータ版の機能です。

検査対象の脆弱性

CWE

WASC

ソースコード

処理概要

一般的にセッションを維持する場合、Cookie もしくは URLパラメータが使用されるため、この2種類に対する処理が用意されています。どちらもやろうとしてることは同じです。Cookie に対する処理では、各ノード(URL)に対して以下の処理を行います。

  1. 診断前に対象URLに1度はアクセスしているはずなのですが、その時に送信された各Cookieパラメータに対して順番に以下の処理を行います。
    1. リクエストヘッダから対象となるCookieパラメータを削除して、対象URLに1度アクセスし、新たにクッキーを発行してもらいます。
    2. 1-1で発行されたセッションクッキーを持った状態でログインしてみます。
    3. 以下の場合、脆弱性ありと判定します。
      1. 1-2で、新たにクッキーが発行されなかった場合
      2. 1-1と1-2で同じ値のクッキーが発行された場合

処理(Cookieに対する処理のみ書きます)

  1. まず、この処理(上記のscanメソッド)が開始される時点で、以下の状況になっています。
    • ActiveScanは診断対象ノード(URL)を順番に処理しており、この時点では特定のURLが診断対象となっています。
  2. ログインURLを取得します。(136行目あたり)
  3. 対象URLがログインURLでなければ処理を終了します。(153行目)
  4. 手動アクセスもしくはスパイダリングで対象URLにアクセスした時の、クッキー(リクエスト側のみ)／フォームパラメータ／URLパラメータを取得します。(159行目あたり)
  5. 取得したパラメータ毎にループ処理を開始します。(204行目)
  6. パラメータがCookieから得た値だった場合(221行目)
    1. 手動アクセスもしくはスパイダリングで対象URLにアクセスした時のデータを使って(対象パラメータであるクッキーだけ削除して)、対象URLにアクセスします。(231行目)
      • これは、セッションクッキーを得るのが目的だと思われます。
      • セッションクッキーであるかどうかのチェックはない？
      • HTTPメソッドもそのまま使われます。(GETならGETでアクセス, POSTならPOSTでアクセス)
      • ここでログインできてしまった場合でも問題ない？
    2. リダイレクトが終わるまでアクセスを続けます。(246行目)
    3. レスポンスのステータスコードが200でなければ、次のパラメータの処理に進みます。(305行目)
    4. レスポンスにクッキーがセットされていなければ、次のパラメータの処理に進みます。(315行目)
    5. クッキーのsecure属性をチェックします。(328行目あたり)
    6. クッキーのhttponly属性をチェックします。(375行目あたり)
    7. クッキーの有効期限をチェックします。(417行目あたり)
    8. 先ほどのアクセスで得たクッキーを持った状態で、もう一度対象URLにアクセスします。
      • ログインするのが目的であると思われます。
      • ログインできなかった場合の判定処理はない？
    9. リダイレクトが終わるまでアクセスを続けます。(572行目)
    10. レスポンスのステータスコードが200でなければ、次のパラメータの処理に進みます。(635行目)
    11. 対象パラメータ名のクッキーが新たに発行されていない場合、もしくは同じ名前のクッキーが同じ値で発行された場合は脆弱性ありと判定します。(644行目)
  7. パラメータがURLから得た値だった場合(678行目)
    • 省略します。

やっている処理から分かること

  • この診断を行うには、事前にコンテキストを登録し、その中でログインURLが設定されている必要があります。
  • ログインページにCSRF対策トークンが設定されている場合は、CSRF対策トークンを事前に登録しておいた上で1度手動でログインしておく必要があります。
  • セッションクッキーを持たない状態でログイン時した場合に、200でないステータスコードが返されるアプリケーションだと正常に診断できません。
  • 通常、ログインにはPOSTアクセスを使うと思いますが、このログインURLに対してGETアクセスするノード([サイト]タブ上)に対してこの診断が行われた場合、2回目のアクセス処理のところでログインできず、且つセッションクッキーも発行されないので、脆弱性ありの判定(false positive)となってしまいます。

まとめ

  • 実際はソースコードを読んだだけでなく、デバッグして動きを追っています。
  • ベータ版の内容なので、まだこれから変わるところも多いかもしれません。
  • 動作が変だと思ったところは、なるべく zaproxy の issues に投げてみます。

[最終更新日: 2014年11月28日]

関連記事