Web アプリ診断ツールを作ってみようと思う。

自己紹介Titter ： abend@number3to4

Web アプリケーションのセキュリティをメインでやっています。ときどき、お酒を Inject することが趣味です。

Web アプリ診断ってWeb アプリケーションに内在する脆弱性を発見するための手法の１つ。

http://www.slideshare.net/abend_cve_9999_0001/web-22186183

参考（ Web アプリって奥が深いんです）

それ以外に・ペネトレーション・ソースコード診断・ファジング…etc

どうやる？

脆弱性の有無を判定

1)リクエストに攻撃パターンを付加。

2)レスポンスの内容から脆弱性の有無を判定。

診断対象

リクエスト

レスポンス

攻撃パターン付加

診断対象画面ログイン画面

ユーザ名：パスワード：

ログイン画面

ユーザ名：パスワード：

　

　

ログイン

様々な攻撃パターンを試行。・「 "><script>alert()</alert> 」・「 ' 」・「 '|||' 」・記号や Null 文字（空文字）・ 5000 バイトの文字列

1)各項目に数十～百パターン程度試行。

2)レスポンスの内容により、攻撃パターンを修正し試行。

どうやる？２

ヒトがやるんだったら

「 ' 」を入力「 ' 」を入力

WebアプリWebアプリ 「 java.sql.SQLException:[Microsoft][ODBC SQL Server Driver][SQL Server]オブジェクト名 'xxxx' は無効です。」が出力

「 java.sql.SQLException:[Microsoft][ODBC SQL Server Driver][SQL Server]オブジェクト名 'xxxx' は無効です。」が出力

リクエストレスポンスブラックボックス

この結果なら、次は「 '+' 」にしよう。

ツールって１ツールは、決まったルール（プログラム）に従い、決まった内容

をリクエスト。

敷かれたレールの上でしか動けないのです。

ツールって２

レスポンスの評価する手法も３つが一般的だと思う。

ツールって３①　 grep

リクエストした内容がレスポンスにどう出力されているか。

怪しそうな文字列を探し出す。

ツールって４②　 diff

複数のレスポンス結果にどんな差分が存在しているか。

似たような結果であったとしても、どんな差分が

出ているか差分内容を精査する必要あり。

ツールって５③　挙動のチェック

レスポンス時間など挙動にどんな差分が存在しているか。

本来のキモいほどの激しい挙動が特定リクエストで遅くなる

など動きに差分がないかを確認する。

ヒトとツールの違い１ツールのダメなところ

・検出できない項目がある。

・診断できないアプリケーションがある。

4)、 8)、 9)がツールでは

検出が不可または困難。

○　 CAPCHAなど視覚を必要とするもの

○　パラメータをクラインアント側で生成するもの

　　　　　　　　　　　　　　　　　　　　　　など

ヒトとツールの違い２ツールのいいところ

・ヒトと違い、バグがなければミスがない。

・ヒトよりも早い。

サーバの通信状況にもよるが、

2秒あれば送信も可能。

こんなこともできるようになる

適材適所

ヒトの仕事を減らすために。

ヒトのようにミスがないので定型的な箇所はツールに、それ以外

をヒトが行うようにする。

想定される構成こんな構成を想定しています。

診断対象

操作端末

開発対象

①「操作端末」から診断

対象にアクセスして、

「開発対象」に「診断

対象」の情報を蓄積。

③「開発対象」に蓄積

された情報から「診断

対象」へ診断。

「診断対象」の情報

②「診断対象」

の情報を蓄積。

どんなツールにするか１

・ GUIで操作できるようにしたい。

・お手軽に結果が得られるようにしたい。

・ Javaクライアントアプリにしたい。

・ DBを使わなくてもイケるようにしたい。

どんなツールにするか考えてみた。

どんなツールにするか２

・診断対象取り込み機能

・診断機能

・結果分析機能

・レポート機能

・スペシャル機能

機能は、こんな感じ。

なので、作り始めた（と思う）一番最初にやり始めたのは、多分 2年前。途中まで作っていた

ことを最近思い出して、また再開させた。

ふと作り始めた診断ツールを命名するときに、尾崎豊の Shelly

を

聞いていたので、「 Shelly」に命名。

Shelly

機能 実装状況

診断対象取り込み機能 ×

診断機能 △

結果分析機能 △

レポート機能 ×

スペシャル機能 ×

いまの現状は、というと

ほとんどできていない。

診断対象取り込み機能１

「操作端末」の Proxyとして動作させて、アクセスした「診断対

象」

の情報（リクエストとレスポンス）を保存させる。

ローカル Proxyとして動作し、 Proxyした結果から「診断対

象」の

リクエストやレスポンスを自動的に抽出できるようにしたい。

診断対象取り込み機能２

実装するときに以下を注意する必要がある（と思ってます）。

・ HTTPSの取り扱いに関して

診断対象操作端末Shelly

暗号化された通信暗号化された通信

「診断対象」の証明書Shellyの証明書

Shellyの証明書は自己証明書で「操作端末」と通信をする必要がある。

診断機能１

保存されたリクエスト情報をもとに、「診断対象」に攻撃パター

ン

を付加したリクエストを送信する。

リクエスト情報・ URL・パラメータ…etc

攻撃パターン

アドオン

診断機能２

HTTPS時の Proxyに関して

HTTPリクエストを送る前に CONNECTメソッドを送信

し、 Socket

通信できるように準備が必要となる。

診断機能３オレオレ証明書を用いたサイトへのアクセス

オレオレ証明書などの不正な証明書を使用しているサイトへの

アクセスは、 NoSuchAlgorithmExceptionが発生してしまう

ため

initSSLContextをオーバライドさせて、オレオレ証明書のサイ

ト

でもアクセスできるようにした方がいい。

結果分析機能１

リクエストした内容に応じて、レスポンス結果を分析する機能。

分析に必要なことは前述のとおり。

grep diff 挙動のチェック

実装済み 実装済み 未実装

結果分析機能２grepに関して

XSSだけでも攻撃パターンは複数のパターンになるが、すべて

同じ文字列を grepすればいいというわけではない。

入力例　 "><script>alert(48264)</script>

特定のリクエストで出力された結果であることを確認する

ために、入力値にランダムな数値をセットして、それを

検出するようにする。

検出例　 alert(48264)

結果分析機能３alert(xxxx)という文字列を grepし、アウトする場合

過剰検知（ FalsePositive）が多数検出される可能性が高

い。

お問合せフォームなどフリーフォーマット（記号も入力を許可）

の場合に、脆弱性がなくても検出してしまう可能性が高い。

結果分析機能４SQLインジェクションの場合

SQL文の断片が評価されたことを検知できる仕組みが必要

だけど、それって結構むずい。

結果分析機能５たとえば、認証が通った場合にレスポンスの「 $flg」が 1に

セット

され、それ以外は 0にセットされるようなアプリケーションでは

～～省略～～

<script>

var flg = $flg;

if(flg == 1){

location.href='http://xxx/ok'

}else{

location.href='http://xxx/ng'

}

</script>

～～省略～～

POST /login HTTP/1.0

Id=1&pass=secret

リクエスト レスポンス

結果分析機能６

それだと、変化の割合（全体に対してどのくらい変化があったか）

のみの評価では、検知漏れ（ False Negative）につながる。

「 ' or 'a’ = 'a」、「 ' or 'a’ = 'b」の真偽値の違いと

レスポンスの差分から脆弱性の有無を判定するブラインド SQL

インジェクションの場合、差分が 1行しかない可能性がある。

検知漏れをなくすためには、変化の割合ではなく、変化の有無を

確認する必要があるが、時間の経過とともに、レスポンスが変化

するアプリケーションは多数存在するため、過剰検知（ False

Positive）が増える。

結果分析機能７

変更のあった割合と変更のあった内容をサマリ化し、ヒトが

内容を確認することで検知漏れを少なくするようにした。

ツールにすべてを任せるのは難しいので

まだまだ、改善の余地がある。。。

レポート機能脆弱性を見つけた後は直す必要があるので、開発者が直しやすい

ように、どんな問題がどこにあったかをまとめる。

・検出箇所

・検出した脆弱性

・検出した際のリクエストおよびレスポンスログ

スペシャル機能診断をしているときの気晴らし機能は、絶対に必要！！

例：

「↑↑↓↓→← →← AB」打つと、スレッド化されてリクエスト

が 2 倍出力される。

本当に 2 倍もリクエスト出している

と小ばかにするための機能。

性格のゆがんだ方にオススメ。

この機能は、どんどん追加していく所存です。

それ以外にも１シグネチャに関して

データベースを使わないことを前提にしているので

1つのシグネチャを 1つのファイルとして管理する。

それ以外にも２ログの取り方に関して

すべてのリクエストとレスポンスは、自動的に蓄積される

ようにする。

それとは別に、個別に脆弱性を検出した際のログを出力させる。

理由は、膨れたログから検索するのがめんどいから。

さいごに

いつ完成するか不明だが、完成したら公開しようと思ってます。