AppEngine Security Scan Toolが利用出来るようになりました。ついては、GAEウォッチャーとして取り急ぎ試してみたので、紹介記事の和訳と実際動かした感想を掲載致します。
1.和訳(原文)
新しいビルドのデプロイするときはわくわくする。
だが、リリースのたびにセキュリティ脆弱性をテストしなくてはならないのは大変である。
ウェブアプリケーションのセキュリティスキャナーは古くからあるが、これらはGoole App Engineの開発者たちにとって必ずしもふさわしいものではなかった。
これらのセキュリティスキャナーはたいていは、セットアップが面倒で、過剰検出(false positive)しすぎがちで(このためいらないものをフィルターしたり優先度の高いものを選別するのに時間を食われる)さらに、これらのセキュリティスキャナーは、開発者向けではなく、セキュリティ専門家向けに作られている。
2015/2/19に、Google Cloud Security Scannerのベータ版がリリースされた。
あなたがApp Engineを使っているならば、あなたのアプリケーションにおける
２つの基本的脆弱性(cross-site scripting(XSS)とmixed content)の診断を簡便に済ますことができる。
Cloud Security Scannerの主要な特徴は以下の3つである。
- 簡単にセットアップでき使えるツールである。
- 最も基本的脆弱性を過剰検出(false positives)を最小限に抑えて検出できる。
- ヘビーにJavaScriptを使用しているウェブアプリケーションに対応している。
これを試すには、Google Developers Consoleから Compute > App Engine > Security scans
と進んで(詳細)、Runをクリックするだけである。
仕組みはどうなっている？
多段のユーザーインターフェースを持つ、最近のJavaScriptを多用したアプリケーションをクロールして、脆弱性テストをするのは、典型的なHTMLページの場合より遥かに大変である。
これを遂行するにあたって、２つの一般的なアプローチがある。
- HTMLをパースして、ブラウザーをエミュレートする。これは、高速だが、完全なDOMや複雑なJavaScript操作を必要とするようなサイトアクションを見逃す可能性がありうるため検出の確実性が落ちる。
- 本物のブラウザーを使う。この方法は、本当のウェブサイト閲覧にもっとも近い。
しかし、イベント発生＞動的実行>DOMが生成されるのを待つなどで脆弱性スキャン実行が遅くなりうる。
Cloud Security Scannerはマルチステージパイプライン手法でこれらの両問題を克服している。
まず、スキャナーは高速にHTMLをクロールして、パースする。
そして、より詳細なサイトのセクションを見つけるために低速ではあるが
厳密なフルページレンダーを行う。
この方法は本物のブラウザーを使う方法よりは高速だが、依然として遅い。
そこで、水平方向にスケールするのである。
Google Compute Engineを使い、何百もの仮想Chromeワーカーからなるボットネットを動的に生成し、サイトをスキャンするのである。
サーバーダウンするのでは？と心配された方もいるかもしれないが、
スキャンごとのリクエスト数は20リクエスト/s以下に制限されているので心配は無用である。
そしていよいよ、あなたのサイトを攻撃する(いや。ここも心配無用)。XSSのテストをするときには、Chrome DevToolsに依存したデバッガーを動かすだけの完全に無害なテストスクリプトを用いる。
一旦、デバッガーが動くと、我々はjavascriptコードが実行されたことを知る。false positiveは(ほぼ)ない。
この方法はアプリケーション特有のバグを見逃す可能性はあるものの、多くの開発者にとって
セキュリティチェックにかかる手間が少なく、無駄情報が紛れ込むことも少ないため、評価されるのではないかと我々は考えている。
すべての動的な脆弱性スキャナーと同じく、Cloud Security Scannerによるスキャン結果が良好だからといってセキュリティバグがないとは限らない。
ウェブアプリケーションセキュリティのプロによる手動セキュリティチェックも合わせて行うことをおすすめする。
テストの準備は整ったか？(詳細) Cloud Security Scannerは現在ベータ稼働中で今後、更なる機能追加が予定されている。 ぜひ、諸君のフィードバックをもらえないか？ ツール内の”Feedback”ボタンをクリックするだけだ。
2.使ってみた
実行は非常に簡単である。
和訳にあるようにスキャン作成を選択してRunをクリックするだけである。
今回は7種類のHTMLページについてテストしてみた。
無害なページ
一番上の(Myproject)はプレーンなHTML(脆弱性は無い)。
Mixed Contentsを含むページ
2番(non ssl IFrame)目は、iframeでhttpsページにhttpのリソースを埋め込んだページ。
XSS脆弱性を含むページ
3－7番目(hrefXSS,xss by get param,post and save&xss after post,post xss)は、非常に典型的なXSS脆弱性を含むもの
- 「hrefXSS」ページはGETパラメータで渡す値が、ページ内のリンク(aタグのhref)に無害化されずに入力できるページ。
- 「xss by get param」ページはGETパラメータで渡す値を、無害化せずにhtmlタグ(もちろんjavascriptも)として表示するページ。
- 「post and save」ページおよび「xss after post」ページはセットとなるテスト用ページでpost and saveページで入力した値を、一旦データベース(データストア)に保存し、その内容をxss after postページで無害化せずにhtmlタグとして表示する。
- 「post xss」ページは、入力した内容をPOSTして、遷移先で無害化せずにhtmlタグとして表示するページ。
テスト結果
無害なページ
無駄検出(false positive)はなかった。
Mixed Contentsを含むページ
non ssl IFrameページこれは見逃してしまっているようである。ちなみに、ブラウザではちゃんとMixed Contentとでてコンテンツも表示されない。こういったものは無害とみなすのであろうか。
XSS脆弱性を含むページ
「hrefXSS」ページ、「xss by get param」ページ、「post xss」ページの”ダイレクト”なケースについてはXSS脆弱性を検出してくれた。ただ、「post xss」に関しては最近のブラウザでは直接ポストした先でスクリプトが走るとXSSとみなして実行をブロックしてくれるので、過剰検出ではある。
しかし、「post and save」「xss after post」ページの組み合わせのような、入力値を、DBに保存し、これを介して別ページにXSSを仕掛けるような”インダイレクト”なケースの脆弱性には未対応のようである。今後の対応をお願いしたいところである。
感想
驚くほど簡便に(数クリックで)使えるのが非常にうれしい。一方でまだベータ版とということもあり、XSSに限っても脆弱性検出が不完全であることは否めない。とはいえ、セキュリティプロの診断とセットで本ツールを使い、本ツールで既知のものについてはプロによるマニュアル診断は行わず、別のもっと高度な、もっとシビアなセキュリティー診断に時間を割いてもらうなどの使い道はありえるのではなかろうか。
