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

2. 自己紹介
Titter： abend@number3to4
Webアプリケーションのセキュリティをメインでやっています。
ときどき、お酒をInjectすることが趣味です。

3. Webアプリ診断って
Webアプリケーションに内在する脆弱性を発見するための手法の
１つ。
http://www.slideshare.net/abend_cve_9999_0001/web-
22186183
参考（Webアプリって奥が深いんです）
それ以外に
・ペネトレーション
・ソースコード診断
・ファジング
…etc

4. どうやる？
脆弱性の有無を判定
1)リクエストに攻撃パターンを付加。
2)レスポンスの内容から脆弱性の有無を判定。
診断対象
リクエスト
レスポンス
攻撃パターン付加

5. 診断対象画面
ログイン画面
ユーザ名：
パスワード：
ログイ
ン
様々な攻撃パターンを試行。
・
「"><script>alert()</alert>
」
・「'」
・「'|||'」
・記号やNull文字（空文
字）
・5000バイトの文字列
1)各項目に数十～百パターン程度試行。
2)レスポンスの内容により、攻撃パターンを修正し試行。
どうやる？２

6. ヒトがやるんだったら
「'」を入力
Webアプリ 「java.sql.SQLException:[Micro
soft][ODBC SQL Server
Driver][SQL Server]オブジェク
ト名 'xxxx' は無効です。」が出
力
リクエスト
レスポンスブラックボックス
この結果なら、次は「'+'」
にしよう。

7. ツールって１
ツールは、決まったルール（プログラム）に従い、決まった内容
をリクエスト。
敷かれたレールの上でしか動けないのです。

8. ツールって２
レスポンスの評価する手法も３つが一般的だと思う。

9. ツールって３
① grep
リクエストした内容がレスポンスにどう出力されているか。
怪しそうな文字列を探し出す。

10. ツールって４
② diff
複数のレスポンス結果にどんな差分が存在しているか。
似たような結果であったとしても、どんな差分が
出ているか差分内容を精査する必要あり。

11. ツールって５
③ 挙動のチェック
レスポンス時間など挙動にどんな差分が存在しているか。
本来のキモいほどの激しい挙動が特定リクエストで遅くなる
など動きに差分がないかを確認する。

12. ヒトとツールの違い１
ツールのダメなところ
・検出できない項目がある。
・診断できないアプリケーションがある。
4)、8)、9)がツールでは
検出が不可または困難。
○ CAPCHAなど視覚を必要とするもの
○ パラメータをクラインアント側で生成するもの
など

13. ヒトとツールの違い２
ツールのいいところ
・ヒトと違い、バグがなければミスがない。
・ヒトよりも早い。
サーバの通信状況にもよるが、
2秒あれば送信も可能。
こんなこともできるようになる

14. 適材適所
ヒトの仕事を減らすために。
ヒトのようにミスがないので定型的な箇所はツールに、それ以外
をヒトが行うようにする。

15. 想定される構成
こんな構成を想定しています。
診断対象
操作端末
開発対象
①「操作端末」から診断
対象にアクセスして、
「開発対象」に「診断
対象」の情報を蓄積。
③「開発対象」に蓄積
された情報から「診断
対象」へ診断。
「診断対象」の情報
②「診断対象」
の情報を蓄積。

16. どんなツールにするか１
・GUIで操作できるようにしたい。
・お手軽に結果が得られるようにしたい。
・Javaクライアントアプリにしたい。
・DBを使わなくてもイケるようにしたい。
どんなツールにするか考えてみた。

17. どんなツールにするか２
・診断対象取り込み機能
・診断機能
・結果分析機能
・レポート機能
・スペシャル機能
機能は、こんな感じ。

18. なので、作り始めた（と思う）
一番最初にやり始めたのは、多分2年前。途中まで作っていた
ことを最近思い出して、また再開させた。
ふと作り始めた診断ツールを命名するときに、尾崎豊のShellyを
聞いていたので、「Shelly」に命名。

19. Shelly
機能 実装状況
診断対象取り込み機能 ×
診断機能 △
結果分析機能 △
レポート機能 ×
スペシャル機能 ×
いまの現状は、というと
ほとんどできていない。

20. 診断対象取り込み機能１
「操作端末」のProxyとして動作させて、アクセスした「診断対象」
の情報（リクエストとレスポンス）を保存させる。
ローカルProxyとして動作し、Proxyした結果から「診断対象」の
リクエストやレスポンスを自動的に抽出できるようにしたい。

21. 診断対象取り込み機能２
実装するときに以下を注意する必要がある（と思ってます）。
・HTTPSの取り扱いに関して
診断対象操作端末
Shelly
暗号化された通信暗号化された通信
「診断対象」の証明書Shellyの証明書
Shellyの証明書は自己証明書で「操作端末」と通信をする必要がある。

22. 診断機能１
保存されたリクエスト情報をもとに、「診断対象」に攻撃パターン
を付加したリクエストを送信する。
リクエスト情報
・URL
・パラメータ
…etc
攻撃パターン
アドオン

23. 診断機能２
HTTPS時のProxyに関して
HTTPリクエストを送る前にCONNECTメソッドを送信し、Socket
通信できるように準備が必要となる。

24. 診断機能３
オレオレ証明書を用いたサイトへのアクセス
オレオレ証明書などの不正な証明書を使用しているサイトへの
アクセスは、NoSuchAlgorithmExceptionが発生してしまうため
initSSLContextをオーバライドさせて、オレオレ証明書のサイト
でもアクセスできるようにした方がいい。

25. 結果分析機能１
リクエストした内容に応じて、レスポンス結果を分析する機能。
分析に必要なことは前述のとおり。
grep diff 挙動のチェック
実装済み 実装済み 未実装

26. 結果分析機能２
grepに関して
XSSだけでも攻撃パターンは複数のパターンになるが、すべて
同じ文字列をgrepすればいいというわけではない。
入力例 "><script>alert(48264)</script>
特定のリクエストで出力された結果であることを確認する
ために、入力値にランダムな数値をセットして、それを
検出するようにする。
検出例 alert(48264)

27. 結果分析機能３
alert(xxxx)という文字列をgrepし、アウトする場合
過剰検知（FalsePositive）が多数検出される可能性が高い。
お問合せフォームなどフリーフォーマット（記号も入力を許可）
の場合に、脆弱性がなくても検出してしまう可能性が高い。

28. 結果分析機能４
SQLインジェクションの場合
SQL文の断片が評価されたことを検知できる仕組みが必要
だけど、それって結構むずい。

29. 結果分析機能５
たとえば、認証が通った場合にレスポンスの「$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
リクエスト レスポンス

30. 結果分析機能６
それだと、変化の割合（全体に対してどのくらい変化があったか）
のみの評価では、検知漏れ（False Negative）につながる。
「' or 'a’ = 'a」、「' or 'a’ = 'b」の真偽値の違いと
レスポンスの差分から脆弱性の有無を判定するブラインドSQL
インジェクションの場合、差分が1行しかない可能性がある。
検知漏れをなくすためには、変化の割合ではなく、変化の有無を
確認する必要があるが、時間の経過とともに、レスポンスが変化
するアプリケーションは多数存在するため、過剰検知（False
Positive）が増える。

31. 結果分析機能７
変更のあった割合と変更のあった内容をサマリ化し、ヒトが
内容を確認することで検知漏れを少なくするようにした。
ツールにすべてを任せるのは難しいので
まだまだ、改善の余地がある。。。

32. レポート機能
脆弱性を見つけた後は直す必要があるので、開発者が直しやすい
ように、どんな問題がどこにあったかをまとめる。
・検出箇所
・検出した脆弱性
・検出した際のリクエストおよびレスポンスログ

33. スペシャル機能
診断をしているときの気晴らし機能は、絶対に必要！！
例：
「↑↑↓↓→← →←AB」打つと、スレッド化されてリクエスト
が2倍出力される。
本当に2倍もリクエスト出している
と小ばかにするための機能。
性格のゆがんだ方にオススメ。
この機能は、どんどん追加していく所存です。

34. それ以外にも１
シグネチャに関して
データベースを使わないことを前提にしているので
1つのシグネチャを1つのファイルとして管理する。

35. それ以外にも２
ログの取り方に関して
すべてのリクエストとレスポンスは、自動的に蓄積される
ようにする。
それとは別に、個別に脆弱性を検出した際のログを出力させる。
理由は、膨れたログから検索するのがめんどいから。

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