脆弱性を直した後のセキュリティテスト（SQLインジェクションの場合）

脆弱性が報告されてから修正が完了するまでに、Webアプリケーション開発者(またはテスター)ができることをセキュリティテストを中心に書く。

1. 再現手順の確立
2. 原因究明
3. 対策の実行
4. 修正の確認
5. セキュリティテスト

セキュリティテストってどうやればいいの？というエンジニアの参考になればいいなあ。

※本記事のサンプルコードは C# + Entity Framework だが、プロセスは他の言語やフレームワークでも通用する。

1.再現手順の確立

※注意：再現行為を本番環境でやるのは危険すぎるので、検証環境でやるのがよい

脆弱性が報告されたら、通常のバグ修正と同じように、まず脆弱性を再現させる。（TDD風に言うなら、レッドになるテストを作る）

SQLインジェクションの場合、主にHTTPリクエスト（HTTP の URL、ヘッダ、本文など）が再現手順になる。あらかじめ Web サイトへのログインが必要な場合は、それも再現手順に含めておく。

再現手順を確立しておくことで、修正後に再現しなくなる（テストがグリーンになる）＝修正できたことを確認できるようになる。

また、この時点で脆弱性スキャナを実行して脆弱性が検出されることを確認しておくのもよい。理由は後述の 脆弱性スキャンに記載。

2.原因究明

SQL インジェクションの原因は、たとえば次のようなケースが考えられる。

• 自分たちが書いたコードに問題がある場合
• ミドルウェアやライブラリ、プラグイン等に脆弱性があった場合
• 脆弱なテストプログラムやサンプルプログラムが残ったままになっていた場合

原因がわかったら、報告を受けた箇所だけではなくほかにも同様の問題がないかも確認する。

今回は自分たちが書いたコードに問題がある場合を想定して話を進める。

3.対策の実行

SQLインジェクションの対策について詳しく知りたい場合は、IPA が公開している 安全なSQLの呼び出し方を参照。

たとえばこんなコードを

varsql="SELECT Id, Author, Title, PostedAt, Text From Posts";sql+=$" Where Author like '%{author}%'";returnawait_context.Posts.FromSqlRaw(sql).ToArrayAsync();

こんな感じに修正する

returnawait_context.Posts.Where(p=>p.Author.Contains(author)).ToArrayAsync();

4.修正の確認

1.再現手順の確立で確立した脆弱性の再現方法を修正箇所に試し、問題が再現しないことを確認する。

これで対策完了！ではない。

5.セキュリティテスト

4.修正の確認は「正しくできた」ことを確認するテスト。対して「正しくできていない」ことを発見するのがセキュリティテストの役割になる。「正しくできていない」とは、間違った対策や中途半端な対策のこと。

セキュリティテストは、通常のテストと同様、コストと網羅性のバランスが必要。修正完了までコードの変更とテストが何度も繰り返されることも多いので、フィードバックの早さも重要。すべてを満たすテスト手法は多分ないので、複数の手法を組み合わせるのが良い。

SQLインジェクションの問題は、コードを見ればある程度問題の有無を判断できることと、自動テストを書きやすそうなことから、次の３つの手法を採用することにする。

1. コードインスペクション
   • ○コスト安：手っ取り早く実行できる
   • ○フィードバック超早：コードが見れればできる
   • ×属人性高：セキュアコーディングのスキルが必要
2. ファジング
   • ○フィードバック早：自動化しやすく、繰り返し実行できる
   • △コスト中：入力データや自動テストを作る必要がある
   • △属人性中：適切なテストデータを作る・選ぶスキルが必要
3. 脆弱性スキャナ
   • ○属人性低：独立性が高く、かつ安定した結果が得られる
   • ×フィードバック遅：デプロイが必要
   • ×コスト高：ツールによってはお金がかかる。学習コストもあるかも。

プロジェクトによっては下記のような選択肢もあるかもしれない。

• 静的コード解析ツール(SAST)を使う（良い精度のツールがあるなら）
• sqlmap のようなツールを使って疑似攻撃を試みる（セキュリティエンジニアがいるなら）
• セキュリティベンダに診断を依頼する（超重要なシステムで、かつ、お金と時間があるなら）

コードインスペクション

コードインスペクションは静的なホワイトボックステストの１つ。あるルールに基づいて人（または機械）がコードを精査し、欠陥を発見する手法。

コードさえ見れれば、デプロイどころかコンパイラすらしなくてもテストできるため、実行コストが低くフィードバックがとても早いという利点がある。ただし精度はテスターのスキルに依存する。

コードインスペクションではセキュリティの問題を発見することにのみ集中する。SQL インジェクション対策のインスペクションであれば、「パラメータを文字列操作してSQL文を作成していないこと」のようなルールをあらかじめ定めたうえで精査する。

ルールは言語やフレームワークによって異なる点に注意。C# + Entity Framework の場合、下記のようなルールになる。

varsql="SELECT * from Posts";

varsql="SELECT * from Posts";sql+=" WHERE author = 'Tanaka Ichiro'";

varsql="SELECT Id, Author, Title, PostedAt, Text From Posts";sql+=" Where Author = {0}";_context.Posts.FromSqlRaw(sql,author)...

dbContext.Posts.Where(p=>p.Author==author)...

varsql="SELECT * from Posts";sql+=" WHERE author = '"+author+"'";

varsql="SELECT * from Posts";sql+=" WHERE author = '{AUTHOR}'");sql=sql.Replace("{AUTHOR}",author);

コーディング規約がない場合はいろんなSQL発行パターンがわいてくるので、判断基準を作りながらテストするか、いっそ標準を定めて標準以外の書き方はNGとしてしまってもよいかもしれない。

コードインスペクションのアウトプットは、テスト対象となったファイルとその結果の一覧になる。（例）

この結果を受けて、例えば次のような判断ができる。

• NG がなくなるまで修正と再テストを繰り返す
• (コードの修正が困難すぎて)NGや判断不可な箇所を
  • 以降のテストでカバーする
  • 熟練セキュアコーダーにインスペクションしてもらう（人がいれば）
• この結果にかかわらず、以降のテストを全箇所実施する

どうするかは、テストの独立性やコストパフォーマンス等のバランスを見て決めればよい。

ファジング

ファジングは動的なブラックボックステストの１つで、「変なデータ」を入力しまくって欠陥を見つける手法。詳しくは IPA の 脆弱性対策：ファジングを参照。

ファジングはWebサイトに対して実行することもできるし、SQLを発行している関数・メソッドに対しても実行できる。

テストは小さい単位でやるほうがコストパフォーマンスがよくフィードバックも早いので、可能なら関数・メソッドに対してやるのがお勧め。もちろん Web サイトにやってもよい。

「変なデータ」はランダムに作っても良いが、今回は fuzzdbで公開されている SQL インジェクションを発見するための入力パターン集を使う。

ユニットテストフレームワークで実行

関数・メソッドに対してテストする場合、ユニットテストフレームワークを使うのが楽。（ユニットテストか？という疑問は気にしないことにする）

以下は C# + ASP.NET Core + SQL Server + xUnit.net の例

こんな脆弱なコードに対して

publicclassBlogPostsController:Controller{privatereadonlyBlogDbContext_context;publicBlogPostsController(BlogDbContextcontext){_context=context;}publicasyncTask<BlogPost[]>SearchByAuthor(stringauthor){// 危険なコード！varsql="SELECT Id, Author, Title, PostedAt, Text From Posts";sql+=$" Where Author like '%{author}%'";returnawait_context.Posts.FromSqlRaw(sql).ToArrayAsync();}// 省略...

こんなテストコードを書く

publicclassUnitTest1{// fuzz.txt の１行を１テストケースとして定義// ※後述の Parameters プロパティを参照[Theory][MemberData(nameof(Parameters))]publicasyncTaskSqlInjectionTest(stringparam){// * Arrangeusing(vardb=newBlogDbContext()){// テーブルを空にしておくdb.Posts.RemoveRange(db.Posts.ToArray());// SQL が正しく実行されれば、この Entity が帰ってくるはずdb.Posts.Add(newBlogPost(){Author=param,Title="test"});// こっちは帰ってこないはずdb.Posts.Add(newBlogPost(){Author="Dummy",Title="Dummy"});db.SaveChanges();}using(vardb=newBlogDbContext()){varcontroller=newBlogPostsController(db);varsw=Stopwatch.StartNew();// * Actvarresult=awaitcontroller.QueryPosts(param);// * Assert// 実行に5秒以上かかったら Blind な SQL Injection が成功してるのでNGAssert.True(sw.ElapsedMilliseconds<5000,"Blind SQL Injection");// 正しいSQL文が発行されていれば１件の結果が返ってくるはずAssert.Equal(param,result.Single().Author);}}// SqlInjectionTest で使う入力データ列publicstaticIEnumerable<object[]>Parameters{get{varf=Path.Combine(AppDomain.CurrentDomain.BaseDirectory,"fuzz.txt");varr=File.ReadAllLines(f).Where(l=>!string.IsNullOrWhiteSpace(l)).Select(l=>newobject[]{l}).ToArray();returnr;}}}

ユニットテストの入力データに使う fuzz.txt はこんな感じ。

;--'; --
');--'; exec master..xp_cmdshell 'ping10.10.1.2'--
'grantconnecttoname;grantresourcetoname;--' or 1=1 -- 
'union(select@@version)--' union (select NULL, (select @@version)) --
'union(selectNULL,NULL,(select@@version))--' union (select NULL, NULL, NULL,  (select @@version)) --
'union(selectNULL,NULL,NULL,NULL,(select@@version))--' union (select NULL, NULL, NULL, NULL,  NULL, (select @@version)) --

';ifnot(substring((select@@version),25,1)<>0)waitfordelay'0:0:5'--'; if not(substring((select @@version),25,1) <> 5) waitfor delay '0:0:5' --
';ifnot(substring((select@@version),25,1)<>8)waitfordelay'0:0:5'--'; if not(substring((select @@version),24,1) <> 1) waitfor delay '0:0:5' --
';ifnot(selectsystem_user)<>'sa'waitfordelay'0:0:5'--'; if is_srvrolemember('sysadmin') > 0 waitfor delay '0:0:5' -- 
';ifnot((selectserverproperty('isintegratedsecurityonly'))<>1)waitfordelay'0:0:5'--'; if not((select serverproperty('isintegratedsecurityonly')) <> 0) waitfor delay '0:0:5' --

上記の例では BlogPostsController クラスの SearchByAuthor メソッドに対してファジングしているが、同様に他のテスト対象のメソッド・パラメータに対してもテストを作り、実行すればよい。SQL 文を正しく作れている（脆弱性が無い）ならすべてのテストがグリーンになるはず。

テスト実行結果の例（脆弱性を修正する前）

Webサイトに対して実行

ユニットテストが困難な場合や、ミドルウェア・フレームワークのバグも心配な場合は、稼働している Web サイトを対象にファジングする。ファジングの方法は IPA が公開している ファジング実践資料 第2版を参照。

ただし Web サイトを対象とする場合、ユニットテストと比較すると下記の点で不利。

• デプロイしないとテストできない
  • テスト環境が必要（本番環境を使うのは超危険！）
  • フィードバックが遅い
• ファジングツールが必要（自前でスクリプトを書いてもいいけど）

脆弱性スキャン

最後に独立性の高いテストとして、脆弱性スキャンを実行する。上2つのテストが成功していればこのテストも成功する可能性が高いが、万が一の抜け漏れを見つけてくれるかもしれない。

注意点は、スキャナの性能や設定値によっては脆弱性を検出できないことがあること。そのため、次の2点を確認するのがよい。

1. 修正前のWebサイトをスキャンして脆弱性が報告されること
2. 修正後のWebサイトをスキャンして脆弱性が報告されないこと

下記は Nessus を使った例。Nessus の使い方は説明しない。

※Nessus を選んだ理由はたまたま手元にあったから、というだけで、Nessus を推奨しているわけではない。

修正前：CGI Generic SQL Injection という脆弱性が報告されている

修正後：SQL Injection とそれに関連する脆弱性の報告が消えている

このテストの成功をもって脆弱性対策を完了とする。ただし↓

退行テスト

脆弱性を修正したら機能が使えなくなった、では意味がないので忘れずに。
（セキュリティテストではないけど）

まとめ

SQLインジェクションが発見されてから修正完了まで、Webアプリケーション開発者（またはテスター）ができることの流れを書いた。

1. 再現手順の確立：脆弱性の再現方法を確立する
2. 原因究明：脆弱性の原因を特定する
3. 対策の実行：原因に対応した方法で対策する
4. 修正の確認：1で確立した再現方法を使い、問題が解消されたことを確認する。
5. セキュリティテスト：コスト、網羅性、独立性、使えるリソース等を考えて、適切なテスト手法を選択する。

参考

IPAが公開しているガイドライン。開発者以外（PM/POとかセキュリティ担当とか）にも役立つ情報あり。

• 脆弱性対応ガイドライン
• 安全なSQLの呼び出し方
• 脆弱性対策：ファジング

Entity Framework 関連

• RawSQLクエリ
• セキュリティに関する注意事項 (Entity Framework)