コンテンツ・スキャンのベスト・プラクティス

テスト・ユーザー・アカウントの使用

サービスの注文が実際には行われず、アカウントが壊れた場合にはリセットできるように、追跡可能なテスト・アカウントを使用してください。さらにテスト・アカウントにより、管理者がテスト後にサイトをクリーンアップすることがより簡単になります。テスト・アカウントについては、以下を考慮してください。

• それはデータベース内のテスト・レコードだけにアクセスするようにする必要があります。これにより変更されたレコードを復元できます。
• テスト・アカウントにより作成された新規レコードは削除します。
• テスト・アカウントからの購入注文または他のトランザクションは無視します。
• サイトにフォーラムがある場合、テスト・アカウントはテスト・フォーラムだけにアクセスするようにする必要があります。これにより実際の顧客がテスト・フェーズ中にテストを表示することはできません。例えば、クロスサイト・スクリプティングのポップアップ・ウィンドウが表示されると、顧客を驚かせてしまう可能性があります。
• サイトがさまざまなアカウントに対してさまざまな特権を使用する場合は、複数のテスト・アカウントを使用します。複数のテスト・アカウントを使用すると、アプリケーションをさらに総合的にテストすることができます。

開始 URL

開始 URL に組み込まれているディレクトリーより上位でスキャンするかどうかを決定します。例えば、開始 URL として www.example.com/customers/default.aspx が指定されており、「開始ドメインで、各開始 URL のディレクトリー内およびその下のリンクのみをスキャンする」チェック・ボックスを選択しているとします。この状況では、www.example.com/partners ディレクトリー内にないため、ジョブはそれをスキャンできません。partners ディレクトリー内をスキャンするには、チェック・ボックスをクリアする必要があります。

「開始ドメインで、各開始 URL のディレクトリー内およびその下のリンクのみをスキャンする」チェック・ボックスはデフォルトで選択されています。

ジョブの「セキュリティー」ページで選択されているセキュリティー・テスト・ポリシーおよびそのサーバー・グループは、開始 URL と対応している必要があります。サーバー・グループがスキャンを許可する URL または IP アドレスが開始 URL 内にない場合、それらはセキュリティー問題についてテストされません。

それぞれのスキャン・ジョブは 1 つのサイトに限定するのが、一般的なプラクティスです。このベスト・プラクティスでは、ダッシュボードでのエグゼクティブ・レベル・レポートは向上し、通常は組織内のさまざまな基幹業務または責任領域はより適正に反映されます。レポート・メカニズムを使用して、希望する方法でさまざまなジョブからのデータを集約します。

追加ドメイン

チェックしておきたいコンテンツもある開始 URL の外部にドメインがあるかどうかを判別します。最初のスキャンでスキャン対象の十分なコンテンツがないことが分かった場合、「Web サイトのアーキテクチャー」レポート をチェックして、内部としてスキャンに追加できる追加ドメインがあるかどうかを確認します。「スキャン対象」ページを使用して、追加ドメインを追加します。

Cookie およびパラメーターの除外

除外 Cookie およびパラメーターの指定は、特定の照会ストリング値 (POST データまたは Cookie) が変更されるたびに変更される可能性があるページの 1 つのインスタンスのみを考慮する有効な方法です。例えば、ページへの URL は、「navmenuhide=」と呼ばれるパラメーターを持つことがあります。このパラメーターの値により、ページのナビゲーション・メニューを非表示にするか表示するかが決まります。このパラメーターは、0 または 1 の値を取ることができます。このページの 1 つのバージョンのみをスキャンする場合は、ジョブの「パラメーターおよび Cookie」ページで「パラメーターと Cookie の除外」として「navmenuhide=」を挿入します。この方式は、複数のページで表面的な相違しか示されていない場合に、重複コンテンツを除外するためにスキャンの有効範囲を絞り込むために役立てることができます。

静的 URL

サイト上の複数の URL が異なっていない場合、それらを区別する別の手段を使用できるように、スキャンにおいてその事実を認識しておく必要があります。サイトが異なるページを区別するためにパラメーター (照会ストリングまたは POST データ) あるいは cookie のどちらを使用するとしても、それらをドメインの正規化規則の一部として識別することができます。ドメインの正規化を構成し、すべてのジョブにそのドメインからページを同じ仕方で認識させるには、ジョブの「スキャン対象」ページに進み、ドメインをクリックしてそのプロパティーを編集します。

JavaScript™ および Flash

サイトの予備スキャンを実施する場合は、「JavaScript™を解析して URL を見つける」チェック・ボックスを選択します。オプションを理解した後に、サイトで JavaScript™ が使用される程度、およびその JavaScript™ の複雑さを判別します。

サイト上の JavaScript™ および Flash ファイルにリンクがある場合、スキャンでそれらを検出できることを確認します。検出できない場合は、それらを開始 URL に追加して、Flash ロジックを模した XRule を使用します。XRule は、ジョブの「詳細スキャン・オプション」 > 「XRule」ページに追加されます。

カスタム・エラー・ページ

一部の Web サイトでは、ブラウザーが内部リンク切れをヒットしたときにリダイレクトするために、カスタム 404 ページを使用します。これらのタイプのページのセットアップ方法にもよりますが、それはサーバーからの 200 タイプ応答という結果になり、これをスキャン・ジョブはリンク切れしていないか、または問題なしと解釈します。この誤検出を軽減するために、それらのカスタム・エラー・ページを識別し、スキャン・ジョブがそれらを検出したときにリンク切れとして認識およびレポートするようにします。

「一般スキャン・オプション」 > 「カスタム・エラー・ページ」ページを使用して、スキャン・ジョブにどのページをリンク切れと見なすかを通知します。カスタム・エラー・ページは、ジョブまたは「管理」タブからセットアップできます。

ブラウザーでサイトの誤った URL を入力し、それにより固有のエラー・タイトルを示すページが表示されるか、または固有 URL にリダイレクトされるかを確認することで、サイトがカスタム 404 ページを使用しているかどうかを簡単に判別できます。そのようになる場合は、結果のページ・タイトルまたは URL を「カスタム・エラー・ページ」ページに追加します。

除外

スキャン (または少なくとも予備スキャン) から除外できるすべてのリンクを識別します。これには以下のようなリンクが含まれます。

• パスワードを変更するもの。
• アカウントを無効にするもの。
• 項目を削除するもの (特に取り消しができない場合)。
• プリンター対応フォーマットで同じコンテンツを提供するもの。
• HTML プレースホルダ―として機能する、blank.gif または spacer.gif などの非存在スペーサー・イメージへのもの。一般に、これらのイメージは Web サーバー上に存在せず、レポートからクラッターを除去するために除外できます。

ショッピング・カート機能

「カートに追加」タイプのアプリケーションの結果である URL パターンを必ず除外します。複数のスレッドがそれらのアプリケーションを絶えずヒットする場合、スキャンによりそれらのアプリケーションに過度の負荷をかける可能性があります。1 つの「カートに追加」項目のマニュアル探査を実行して、それがテストされていることを確認します。

「パスおよびファイルを除外」ページを使用して、サイトのセクションをスキャンから除外します。regexp:.*addtocart.* を除外します。

カレンダー

メディア・ファイル

.wmv や .mov などのラージ・メディア・ファイルは、通常はスキャンから除外できます。それらを除外 しない 場合、サイトのスキャンにかかる時間は大幅に増大する可能性があります。

「パスおよびファイルを除外」ページを使用して、サイトのセクションをスキャンから除外します。

表内の行または列のソート

ソート可能列がある表のように、ページのコンテンツをソートできる場合は、ソートされた各ページの URL を除外することを考慮してください。例えば、レポートには 2 つの異なる URL がありますが、コンテンツは同じです。変更されているのは、「脆弱性」列のソートだけです。再ソートされた各ページから URL を除外しない場合、スキャン・ジョブは同じ内容を複数回スキャンします。「パスおよびファイルを除外」ページを使用して、サイトのセクションをスキャンから除外します。

ログインおよび段階アプリケーション

ログイン後のページのスキャンを試行する場合は、以下のいくつかの考慮すべき事柄があります。

• アプリケーションにはワンタイム・ログインが必要ですか?「ログイン管理」ページを使用して、スキャンが自動的にログインできるようにユーザー名とパスワードを入力します。
• ログイン・ページは他のドメインにリダイレクトされますか?そうであれば、他のドメインを内部としてジョブに追加します。ドメインを内部として追加するには、「スキャン対象」ページに進み、「ドメインの追加 をクリックします。
• サイトまたはアプリケーションへのログイン・ページやエントリー・ページは、一連のステップ付きフォームで構成されていますか?そのような場合は、記録されたログイン手順を使用して、コンテンツ・スキャンを開始します。「ログイン管理」ページを使用して、ログイン手順を記録します。
• サイトはセッション ID を使用していますか?その場合は、セッション ID をスキャン・ジョブ・プロパティーの一部として追加することが必要になる可能性があります。セッション ID をセットアップするには、「パラメーターおよび Cookie」ページに進みます。「パラメーターと Cookie の除外」として構成された場合、それらは URL を正規化するために追加されます。「セッション ID」として構成された場合、誤ったセッション値により中断されることなく、サイト全体のスキャンを続行できます。
• サイトはログインに Cookie を使用しますか?ログイン後のスキャンは、スキャンを実行する前に自動的にログインするように cookie を設定した場合にのみ機能します。
• ログイン・フォームの後にログアウト・リンクがありますか?ある場合には、ログアウト・リンクを除外し、コンテンツ・スキャンがそのリンクをたどってログアウトしないようにします。たいていの場合、ログアウトは「ログアウト」ボタンのフォームです。他の一般的なバリエーションとしては、「ログオフ」、「サインアウト」、および「終了」があります。特定の Web ページへのリンクにより、ユーザーが強制的にログアウトさせられるというケースも報告されています。ログアウト・ボタンがどこにあるか、またはどの条件によってセッションからログアウトさせられてしまうかがはっきりしない場合は、Web サイト開発者に問い合わせるのが最善です。

フォーム

一部のフォームには、値が変更される属性があります。これらの属性がスキャン間で異なる場合、スキャン・ジョブは各変更を固有のフォームを反映するものと見なし、変更された各フォームを報告します。つまり、レポート結果は重複フォームで増大してしまうということです。この問題を避けるために、正規化規則をスキャン対象のドメインに適用します。スキャン・ジョブにより検出される URL とフォームは、「スキャン対象」ページから、ドメインのプロパティーを編集することにより正規化できます。

共通フォームの値をスキャンに自動的に提供して、スキャンが中断なく続行できるようにします。例えば、スキャン・ジョブが Web サイトまたはアプリケーションでフォームを複数回検出する場合、検出するたびにそのフォームにコンテンツを提供する必要があります。「フォームの自動入力」ページを使用して、例えば国名または地域名などのフォームの値を追加しておけば、国名または地域名のフォームを検出するごとに個人的にそれと対話する必要はなくなります。