*本ブログは Atlassian Blogs を翻訳したものです。本文中の日時などは投稿当時のものですのでご了承ください。原文 : 2012 年 2 月 22 日、Mark Hrynczak 投稿 “13 Steps to Learn & Perfect Security Testing in your Org”
今回のゲスト ブログは、QA コミュニティ内でのテスティング改革に関する関心を高めることを目的とした Atlassian ブログ シリーズの一環です。また、このシリーズの他の記事については、QA 改革タグ付きの記事を参照してください。
はじめに
ソフトウェア アプリケーションが Web 技術を使用して作成され、ユーザーがインターネット接続を使用してどこからでもそのアプリケーションにアクセスしたいと願う傾向がますます高まっています。ブラウザー ベースのセキュリティは、従来のシック クライアント アーキテクチャでの仕組みとはまったく異なります。オペレーティング システムの制御の下、コンピューター上で実行されるさまざまなコード片間の隔たりよりも、ブラウザー内のさまざまな Web サイト間での隔たりの方がはるかに少ないといえます。そのため、セキュリティ テストは Web アプリケーションのテストの重要な部分であり、こうしたスキルが QA チームにますます求められていることになります。経験豊富なテスターであっても、Web アプリケーションのセキュリティは手ごわい相手です。こうしたスキルはどうすれば養うことができるでしょうか？また、どこで情報を見つければよいでしょうか？
事実、セキュリティ テストは多くの意味で機能テストに似ています。リスクを特定し、予想される動作を定義して、予想外の事態が起こらないことを実証することでリスクを軽減するためのいくつかのテストを行います。たとえば、テスト対象のシステムがインターネット接続を行う Web アプリケーションで、データベースを使用しているとします。リスクとして、インターネット上に潜む攻撃者がフロントエンドを使用してバックエンドに保存されている機密データにアクセスすることが挙げられます (これを SQL インジェクションと呼びます)。この場合に期待される動作は、アプリケーションがこの発生を防ぐことです。ユーザーの入力内容はデータベースで実行される SQL ステートメントに直接貼り付けられることはありません。これをテストするには、アプリケーションを混乱させてコマンドを実行させると考えられる文字列を手動で入力するか、同じ作業を実行する自動化ツールを使用するか、または入力文字列がどのように処理するかを確認するためにコード インスペクションを実行します。
セキュリティ テストを行う際の主な違いは考え方の違いです。機能テストの場合、機能がエンドユーザーにとって正しく機能するか、つまり予想どおりの動作をするか、ユーザーが作業を完了する上で妨げにならないかを証明しようとします。おそらくそれに合わせて優先付けを行い、より頻繁に使用される機能、より多くのユーザーが使用する機能、最も重要とみられる機能などに重点的に取り組みます。セキュリティ テスターとして、この 'エンドユーザー' をアプリケーションに侵入しようとしている攻撃者と見立てます。テストの目標は、特定の攻撃シナリオがあらゆる場面において成功しないことを証明することです。ここで非常に難しいのは、機能が動作することを証明することは、特定の機能がいかなる方法でもハッキングされないことを証明するよりもずっと簡単であることです。ここでは機能テストと似たような優先付けの手法を使用することもできます。つまり、各機能について最もありがちな攻撃、最も簡単な攻撃、または最も頻繁に行われる攻撃のセットのみをテストします。他に注意すべき点は、"ユーザーはこれを行わないと思われる" または "ほとんど使用されない機能のため修正せず" といったバグ レポートへの開発者のありがちな対応は、セキュリティの問題が絡む場合はまったく有効ではないということです。攻撃者は攻撃を成功させるためにあらゆる手を使うためです。
今回の記事では、セキュリティ テストに対するチーム スキルを育てるためのヒントをいくつか紹介します。
基本事項
1. アプリケーションの理解
リスクがどこに存在するかを評価できるようにテスト対象のアプリケーションをよく理解することは重要です。アプリケーションが使用する技術、さまざまなユーザーのプロファイル、異なるアクセス レベルで持つべき権限/持つべきでない権限、およびアプリケーションに保存される可能性のあるデータなどの知識を持っていることが前提とされます。インターネット上で匿名のサイト利用者に猫の写真を単に見せる Web サイトと、猫の写真を売るためにログイン ユーザーにクレジット カード情報の入力を求める Web サイトでは、行うテストはまったく異なります。
2. セキュリティ規定と定義の理解
OWASP を参照していただくのが最適です。一見、規定やコンセプトの量に圧倒されるかもしれませんので、一部の規定、できれば自分のアプリケーションに最も関連すると思われる規定のみ重点的に確認します。例として XSS、XSRF、SQL インジェクション、およびパス トラバーサルなどが挙げられます。CWE/SANS トップ25 には脆弱性を引き起こす最も広範かつ重大なエラーが表示されています。既知の攻撃方法すべてを網羅したリストについては、CAPEC を参照してください。
知識の養成
3. オンライン トレーニング ツールの使用
学習を始める最適な方法は、既知の脆弱性があり、それを見つける方法を記した指示書が提供されているアプリケーションをテストしてみることです。私のお勧めは各コンセプトを網羅するレッスンが個別に用意されている Google の Gruyere です。脆弱性を見つけたり、必要に応じて正解を見つけるのに役立つヒントを確認できます。
他の候補として、OWASP の WebGoat や Damn Vulnerable Web App なども挙げられます。
4. 他人から学ぶ
自分の勤め先の開発者の中でセキュリティの問題に詳しい人が何人かいるはずです。自分とペアを組んでアプリケーションの動作を調査するよう頼んでみましょう。たとえば、開発者は SQL インジェクション文字列がデータベース サーバーで実行されていないこと、およびなぜそうであるかを実証できる必要があります。実行されている場合、双方にとって教育上ためになります。また、アプリケーションの設計や攻撃から守るための仕組みについて開発者から説明してもらうこともできます。セキュリティについて学びたい人が多い場合はプレゼンを実施してもらうこともできます。
5. 自動脆弱性スキャナーの使い方を学ぶ
有料のものとしては Burp Scanner がお勧めです。OWASP の ZAP や Google の RatProxy など、無料のものもあります。これらはプロキシを通してアプリケーション間で HTTP トラフィックをルーティングし、元の値を置き換えるさまざまな攻撃試行でもってリクエストを再送信することで動作します。これは短い時間で特定のクラスの脆弱性を見つける効率的な方法ですが、特効薬ではない点を理解すること (さらに関係者に理解してもらうこと) が大切です。ツールはアプリケーションのビジネス ロジックに関する知識を持たず、単にリクエストを中継して反応を確認するだけです。この方法で見つからない、または見つけることができない脆弱性の種類は数多くあり、スキャン ツールの使用は手動によるセキュリティ テストを置き換えるものでは決してありません。
自動ツールはいかに高額なものであっても比較的シンプルな脆弱性しか検出せず、"ノイズ" (つまり誤検出) が大量に見つかることがよくあります。自動ツールが検出した内容それぞれについて評価できるように、セキュリティの脆弱性についての十分な知識を持っている必要があります。スキャナー レポートを作成して未検証のまま開発者に渡すことは最もやってはならないことです。
知識の共有
6. 学んだことを他の人へ
知識を蓄えていく中で、他の人たちもその恩恵を受けられるようにしましょう。基本的なセキュリティ コンセプトに関するプレゼンを実施したり、自動スキャナーの使い方に関する講義を行いましょう。開発者もテスターもあなたから学ぶことができ、自身もそのトピックに対する理解を強固にできます。
7. セキュリティの重要性を説く
セキュリティの問題をよく知らない、または気に掛けない人たちと作業を共にすることがあると思います。新卒者であったり、ソフトウェアがファイアウォールで保護されている環境で以前働いていた人たちなどがそうです。彼らの啓蒙に努める価値はあります。ユーザーの情報を消失してしまった大企業に対する風当たりについて再認識させましょう。テストでアプリケーションの脆弱性が検出された場合、結果として発生する潜在的な悪用方法と共に実際にデモを行います。デモを行う際の有用なツールは BeEF です。このツールは、シンプルな XSS 脆弱性がいかに他のユーザーやその人たちのブラウザーを強力に支配するかを示してくれます。
8. コンテキスト内でセキュリティの問題を伝える
発見したセキュリティ脆弱性はすべてアプリケーションのコンテキストの中で評価することが重要です。不透明な条件下でのみ悪用可能なクロス サイト スクリプト脆弱性の重要性は、他人が自分の Web サーバー上でコードを実行できてしまう脆弱性の重要性よりもずっと低くなります。検出された脆弱性に対する評価システムの構築をお勧めします。一般的な評価手法の 1 つとして CVSS が挙げられます。評価に加えて、攻撃が成功した場合の業務上の影響を考慮します。一般的な話として、猫の写真の消失は企業の事業記録の改ざんよりも影響度が低いといえます。何を修正すべきかを優先付けする必要がある場合は、影響度に基づいて行う方が通常はうまくいきます。
維持
9. 優良な既定のテスト データを使用
機能をテストする場合、おそらくテスト データを作成していると思います。'test1′、'test2′ や漫画のキャラクター名を使用するのではなく、攻撃文字列を使用する癖を付けましょう。こうすることで、機能を使用するだけで偶然に脆弱性が見つかることがあります。自動化ツールまたはテスト データを提供するインポート ファイルがある場合は、同じことを行います。他のテスターや開発者とこのデータを共有することで、セキュリティ テストを行っているという認識なしに問題に遭遇する可能性があります。
10. 練習、練習、また練習
どんなスキルにも言えることですが、練習を積むことでうまくなっていきます。アプリケーションの脆弱性を見つけ始めると、今後どこで発生する可能性があるかを感覚的につかみ、前もって問題提起できます。コードに対して定期的にスキャンを実行することで、効果的にスキャナーを使用できるようになっていきます。コード レビューに参加し、アプリケーションを実際に使用する前からどこに脆弱性が潜んでいるかを指摘できます。
11. 自動プロセスを適宜使用
セキュリティ テストで自動プロセスが有効かを検討しましょう。こうした目的では既存の機能テストが再利用できることがよくあります。
改善
12. 書籍を読む
Web アプリケーションのセキュリティに関する良著がいくつかあります。最近のものでは Burp スキャナーの作者 Dafydd Stuttard 氏による『Web Application Hacker Handbook 第 2 版』や、Google 社の Michal Zalewski 氏による『The Tangled Web: A Guide to Securing Modern Web Applications』などがあります。
13. 社外トレーニング
今回の記事ではチームでセキュリティ テストを開始する際の基本事項を紹介しました。学ぶべきことはもっと多く、有用なオンライン資料も豊富に存在します。SANS などのトレーニング提供企業による多彩なコースなど、もっと的を絞ったトレーニングが必要だと判断するかもしれません。QA スタッフ向けのセキュリティ トレーニング コースは非常に少ないため、Web 開発者向けのセキュリティ コースを探してみましょう。いわゆる "侵入テスト" コースはネットワークのハッキングに的を絞っている傾向がありますが、Web アプリケーションへの侵入に特化したセクションがあることが多いのでコースの内容を前もって確認してみるといいでしょう。
(翻訳：go2group 株式会社)