Fukuoka.go#13 + Okayama.goでLTをした
Fukuoka.go#13 + Okayama.goでLTをして（もう1ヶ月前），その時の質問や感想をメモしていたので，ブログに書いておきます． 発表内容は以前のエントリに関するものです．
発表資料
作ったソフトウェア
いただいた質問・コメント
ブラックリスト方式では，既知の不正クエリのパターンを登録し，パターンに一致したものが検知されます．具体的な不正クエリのパターンとしては，TRANCATEやALTER TABLE，UNION SELECTなどが挙げられると思います．ブラックリスト方式は定義されたパターンに一致するものが検知されるので，定義から外れた未知のパターンを持つ不正クエリを検知することができません．一方で，ホワイトリスト方式では，Webアプリケーションが発行し得るクエリなどの正常なパターンを定義して，パターンと一致しないものが検知されます．そのため，未知のパターンを持った不正クエリも検知することができます．
今回の方法は未知のパターンを持った不正クエリにも対応し，不正クエリの検知漏れを引き起こさないために，ホワイトリスト方式を採用しました．
- テスト時のクエリで検知率の高いホワイトリストを作成できるのか？
テストカバレッジが68.97%でSQLインジェクションの脆弱性を持たせた，小規模なWebアプリケーションを実験対象にしました．まず，Webアプリケーションに対してsqlmapを用いてSQLインジェクション攻撃を行い，攻撃の過程で発行された265個の不正クエリを検知できるかの実験を行いました．実験の結果，全ての不正クエリを検知することができました．次に，Webアプリケーションを網羅的に操作して発行された17個の正常なクエリを誤検知しないかの実験を行いました．実験の結果，3個（全体の17.65%）を誤検知しました． このことから，不正クエリの検知精度は高いものの，正常なクエリの一部を誤検知してしまうことがわかりました．
- sqdでは不正クエリのブロッキングはやらないのか？
上述したように，正常なクエリの一部を誤検知してしまうことがわかっており，正常なクエリをブロッキングしてしまう可能性があるため，ホワイトリスト方式でのブロッキングは難しいと考えています．そこで，ブロッキングを考えた場合は，ブラックリスト方式とホワイトリト方式の併用を考えています． これは，ブラックリストとホワイトリストを両方定義しておき，ブラックリストで検知されたものはブロッキングを行い，ホワイトリストで検知されたものはWarningのクエリとして通知を行うような方法です．
発表しての感想
Fukuoka.goには，これまで何回か参加してきましたが，参加者も多く議論が活発なコミュニティだと感じています．今回の勉強会はOkayama.goとリモートでつないでの同時開催ということで，岡山側からの発表もあり，より議論が盛り上がったように感じました． さて，僕はFukuoka.go，ひいては勉強会での発表は初めてで不安だったのですが，発表後にはたくさんの質問やコメントをいただき，大変勉強になりましたし嬉しかったです．発表を聞いてくださった方々，質疑をしてくださった方々ありがとうございました．
