著者/所属機関
VaggelisAtlidakis (Columbia University) et al. (残り二人の著者はマイクロソフト)
出典
ICSE 2019 (https://patricegodefroid.github.io/public_psfiles/icse2019.pdf)
目的
- REST APIの効率的なFuzzing
問題
- 既存のREST APIツールは有効性が分かっていない
解法
- ステートフルなFuzzingツールの実現
- Swaggerの仕様で宣言されたリクエストタイプ間の関係(例えばAPI1のレスポンスをAPI2で使う＝API1→API2の順で実行するという関係)を自動推論してテスト
- テスト生成に過去のテスト実行結果からのフィードバックを使う(例えばAPI1→API3でAPI3が拒否されるなら以後のテストでこの組み合わせを使わない)
- API呼び出しのシーケンスを、1ずつ長くしながら生成していく、此のときに上記をつかって現実的なシーケンスを残すようにする
- シーケンス生成時の探索手法はいくつか考えられる(BFS, BFS-Fast, RandomWalk)ので評価実験し比較
結果
RQ1 API間依存推定とテスト結果動的フィードバックがFuzzingを効率的にするか?
- サンプルのブログアプリで実験
- 両方使う手法が最も高いカバレッジを出し、また最も早く500エラーを発見し、400エラーの数も少なかった
RQ2 RESTlerが生成したテストは、リクエスト列が長いほど深くサーバサイドのロジックを探索できるのか?
- GitLabで実験
- リクエスト列が長くなるほど、サーバサイドのRubyコードのカバレッジは一貫して増えた
- ただし単純なBFSだとシーケンスの数が膨大になり頭打ちが見える
RQ3 3つの探索手法を様々なAPIに試した場合の違いはなにか?
- GitLabで実験
- BFS-Fastは、APIの種類の多いカテゴリだと高速にカバレッジ拡大、種類の少ない場合は単純BFSの方がカバレッジ高い
- RandomWalkはリクエスト列をかなり長くして探索でき、いくつかのグループで最高のカバレッジ
- バグ発見の観点ではRandomWalkが最も多くのバツを見つけた
その他
- GitLabで実験し、28の未知バグを検出した
- AzureとOffice365でもつかって実バグを見つけた
- ツール公開済み: https://github.com/microsoft/restler-fuzzer