URL チェックの開始
開始 URL チェックでは、受信要求の URL が検査され、URL が指定された基準を満たしていない場合は接続試行がブロックされます。条件を満たすには、[URL クロージャの強制] パラメータが有効でない限り、URL は開始 URL リストのエントリと一致する必要があります。このパラメーターを有効にすると、Webサイト上のリンクをクリックしたユーザーは、そのリンクのターゲットに接続されます。
開始URLチェックの主な目的は、ブックマークや外部リンクを介してWebサイト上のランダムなURLに繰り返しアクセスしようとしたり、URLを手動で入力してその部分に到達するために必要なページをスキップしたりして、ページにジャンプするのを防ぐことです。ウェブサイトの。強制ブラウジングを使用すると、バッファオーバーフローを引き起こしたり、ユーザーが直接アクセスすることを意図していないコンテンツを見つけたり、Web サーバーの安全な領域へのバックドアを見つけたりすることができます。Web App Firewall は、開始 URL として設定されている URL のみへのアクセスを許可することで、Web サイトの特定のトラバーサルまたはロジックパスを強制します。
ウィザードまたは GUI を使用する場合は、[開始 URL チェックの変更] ダイアログボックスの [全般] タブで、[ブロック]、[ログ]、[統計]、[ラーニングアクション]、および次のパラメータを有効または無効にできます。
- URL の閉鎖を強制します。Webサイトの他のページのハイパーリンクをクリックして、ユーザーがWebサイトの任意のWebページにアクセスできるようにします。ユーザーは、ハイパーリンクをクリックして、ホームページまたは指定された開始ページからアクセスできるWebサイト上の任意のページに移動できます。 注:URL クロージャ機能を使用すると、任意のクエリ文字列を HTTP GET メソッドを使用して送信された Web フォームのアクション URL に追加および送信できます。保護されたWebサイトがフォームを使用してSQLデータベースにアクセスする場合は、SQLインジェクションチェックが有効になっていて、適切に構成されていることを確認してください。
- セッションレス URL の閉鎖。クライアントの観点からは、このタイプのURLクロージャは、標準のセッション対応URLクロージャとまったく同じように機能しますが、Cookieの代わりにURLに埋め込まれたトークンを使用してユーザーのアクティビティを追跡します。セッションレス URL 閉鎖が有効になっている場合、Web App Firewall は、URL 閉鎖内にあるすべての URL に「as_url_id」タグを追加します。 注：セッションレス（セッションレス URL 閉鎖）を有効にする場合は、通常の URL 閉鎖（URL 閉鎖の 強制）を有効にする必要があります。そうしないと、セッションレス URL 閉鎖が機能しません。
-
リファラーヘッダーを検証します。別のWebサイトではなく保護されたWebサイトからのWebフォームデータを含むリクエストのRefererヘッダーを確認します。このアクションは、外部の攻撃者ではなく、WebサイトがWebフォームのソースであることを確認します。これにより、ヘッダーチェックよりも CPU を大量に消費するフォームのタグ付けを必要とせずに、クロスサイト要求フォージェリ (CSRF) から保護されます。Web App Firewall は、ドロップダウンリストで選択するオプションに応じて、次の 4 つの方法のいずれかで HTTP Referer ヘッダーを処理できます。
- Off：Referer ヘッダーを検証しません。
- If-Present—Referer ヘッダーが存在する場合は、Referer ヘッダーを検証します。無効な Referer ヘッダーが見つかった場合、リクエストはリファラーヘッダー違反を生成します。Referer ヘッダーが存在しない場合、リクエストはリファラーヘッダー違反を生成しません。このオプションを有効にすると、Web App Firewall は Referer ヘッダーを含むリクエストに対して Referer ヘッダーの検証を実行できますが、ブラウザーが Referer ヘッダーを設定していないユーザーや、そのヘッダーを削除する Web プロキシやフィルターを使用するユーザーからのリクエストをブロックすることはできません。
- 常に開始 URL を除く— 常にリファラーヘッダーを検証します。Referer ヘッダーがなく、要求された URL が startURL 緩和ルールによって免除されていない場合、リクエストはリファラーヘッダー違反を生成します。Referer ヘッダーが存在しても無効な場合、リクエストはリファラーヘッダー違反を生成します。
- 「最初の要求を除く常に必ず」—常にリファラーヘッダーを検証します。リファラーヘッダーがない場合は、最初にアクセスされた URL のみが許可されます。他のすべてのURLは、有効なリファラーヘッダーなしでブロックされます。Referer ヘッダーが存在しても無効な場合、リクエストはリファラーヘッダー違反を生成します。
[開始 URL チェックの変更]** ダイアログボックスでは、[開始 URL チェックの終了 URL を免除**] の設定は構成されていませんが、プロファイルの [設定] タブで構成されています。この設定を有効にすると、Web App Firewall が URL クロージャの条件を満たす URL に対してフォームベースのチェック（クロスサイトスクリプティングや SQL インジェクションインスペクションなど）を実行しないように指示します。
注
リファラーヘッダーチェックと開始 URL セキュリティチェックは同じアクション設定を共有しますが、開始 URL チェックに違反することなくリファラーヘッダーチェックに違反する可能性があります。差異は、開始URLチェック違反とは別にリファラーヘッダーチェック違反をログに記録するログに表示されます。
リファラーヘッダーの設定（オフ、存在する場合、常に例外開始URL、およびAlwaysExceptFirstRequest）は、最も制限の低い順に配置され、次のように動作します。
OFF:
- 参照元ヘッダーはチェックされていません。
If-Present:
- リクエストにはリファラーヘッダーがありません->リクエストは許可されています。
- リクエストにはリファラーヘッダーがあり、リファラーURLはURLクロージャにあります->リクエストは許可されています。
- リクエストにはリファラーヘッダーがあり、リファラーURLがURLクロージャに ありません ->リクエストがブロックされています。
AlwaysExceptStartURLs:
- リクエストにはリファラーヘッダーがなく、リクエストURLが開始URLです->リクエストが許可されています。
- リクエストにはリファラーヘッダーがなく、リクエストURLが開始URLではありません->リクエストはブロックされています。
- リクエストにはリファラーヘッダーがあり、リファラーURLはURLクロージャにあります->リクエストは許可されています。
- リクエストにはリファラーヘッダーがあり、リファラーURLがURLクロージャに ありません ->リクエストがブロックされています。
AlwaysExceptFirstRequest:
- リクエストにはリファラーヘッダーがなく、セッションの最初のリクエストURLです->リクエストが許可されています。
- リクエストにはリファラーヘッダーがなく、セッションの最初のリクエストURL ではありません ->リクエストがブロックされています。
- リクエストにはリファラーヘッダーがあり、セッションの最初のリクエストURLであるか、URLクロージャにあります->リクエストが許可されています。
- リクエストにはリファラーヘッダーがあり、セッションの最初のリクエストURLでもなく、URLクロージャーにもありません->リクエストはブロックされています。
コマンドラインインターフェイスを使用する場合は、次のコマンドを入力して、開始 URL チェックを設定できます。
set appfw profile <name> -startURLAction [block] [learn] [log] [stats] [none]set appfw profile <name> -startURLClosure ([ON] | [OFF])set appfw profile <name> -sessionlessURLClosure ([ON] | [OFF])set appfw profile <name> -exemptClosureURLsFromSecurityChecks ([ON] | [OFF)set appfw profile <name> -RefererHeaderCheck ([OFF] | [if-present] | [AlwaysExceptStartURLs] | [AlwaysExceptFirstRequest])
開始 URL チェックのリラックスを指定するには、GUI を使用する必要があります。開始 URL チェックを修正ダイアログボックスの「チェック」タブで、「追加」をクリックして「開始 URL チェック緩和を追加」ダイアログボックスを開くか、既存のリラクゼーションを選択して「開く」をクリックして「開始 URL チェック緩和を修正」ダイアログボックスを開きます。どちらのダイアログボックスも、緩和の設定に同じオプションを提供します。
開始 URL チェック緩和の例を次に示します。
-
ユーザーに www.example.com のホームページへのアクセスを許可します。
^http://www[.]example[.]com$ <!--NeedCopy--> -
ユーザーがすべての静的 HTML (.htm および.html)、サーバー解析された HTML (.htp および.shtml)、PHP (.php)、Microsoftの ASP (.asp) 形式のウェブページにアクセスすることを許可します。
^http://www[.]example[.]com/([0-9A-Za-z][0-9A-Za-z_-]\*/)\* [0-9A-Za-z][0-9A-Za-z_.-]*[.](asp|htp|php|s?html?)$ <!--NeedCopy--> -
www.example-español.com で非 ASCII 文字を含むパス名またはファイル名で Web ページにアクセスすることを許可します。
^http://www[.]example-espaxC3xB1ol[.]com/(([0-9A-Za-z]|x[0-9A-Fa-f][0-9A-Fa-f])([0-9A-Za-z_-]|x[0-9A-Fa-f][0-9A-Fa-f])\*/)\* ([0-9A-Za-z]|x[0-9A-Fa-f][0-9A-Fa-f])([0-9A-Za-z_-]|x[0-9A-Fa-f][0-9A-Fa-f])*[.](asp|htp|php|s?html?)$ <!--NeedCopy-->注：上記の式では、各文字クラスは文字列 x[0-9a-FA-Fでグループ化されています][0-9A-Fa-f]。これは、適切に構築されたすべての文字エンコーディング文字列と一致しますが、UTF-8文字エンコーディング文字列に関連付けられていない浮遊バックスラッシュ文字は使用できません。二重バックスラッシュ () はエスケープされたバックスラッシュで、Web App Firewall がリテラルバックスラッシュとして解釈するように指示します。バックスラッシュを 1 つだけ含めた場合、Web App Firewall では代わりに次の左角括弧 ([) が文字クラスの開始ではなくリテラル文字として解釈され、式が壊れます。
-
www.example.com ですべての GIF (.gif)、JPEG (.jpg、.jpeg)、および PNG (.png) 形式のグラフィックへのアクセスを許可します。
^http://www[.]example[.]com/([0-9A-Za-z][0-9A-Za-z_-]\*/)\* [0-9A-Za-z][0-9A-Za-z_.-]*[.](gif|jpe?g|png)$ <!--NeedCopy--> -
CGI (.cgi) および PERL (.pl) スクリプトへのアクセスを許可しますが、CGI-BIN ディレクトリでのみ許可します。
^http://www[.]example[.]com/CGI-BIN/[0-9A-Za-z][0-9A-Za-z_.-]*[.](cgi|pl)$ <!--NeedCopy--> -
ユーザーが docsarchive ディレクトリにある Microsoft Office およびその他のドキュメントファイルにアクセスすることを許可します。
^http://www[.]example[.]com/docsarchive/[0-9A-Za-z][0-9A-Za-z_-.]*[.](doc|xls|pdf|ppt)$ <!--NeedCopy-->
注
デフォルトでは、すべての Web App Firewall URL は正規表現と見なされます。
注意:正規表現は強力です。特に、PCRE形式の正規表現に精通していない場合は、記述した正規表現を再確認してください。例外として追加する URL を正確に定義していることを確認し、それ以外は何も定義しないでください。ワイルドカード、特にドットとアスタリスク ( .*) メタキャラクタとワイルドカードの組み合わせを不注意に使用すると、意図しないウェブコンテンツへのアクセスをブロックしたり、開始URLチェックでブロックされた攻撃を許可したりするなど、望ましくない結果になる可能性があります。
ヒント
URL 命名スキームの SQL キーワードの許可リストに -and- を追加できます。たとえば https://FQDN/bread-and-butterの例。