製品ドキュメント
ADC
14.1 - Current Release 13.1 13.0 12.1
PDFを表示

URL チェックを開始

August 15, 2023
寄稿者: 
C

開始 URL チェックは、受信リクエストの URL を調べ、URL が指定された基準を満たさない場合は接続試行をブロックします。条件を満たすには、「URL 閉鎖の強制」パラメーターが有効になっていない限り、URL が「開始 URL」リストのエントリと一致する必要があります。このパラメーターを有効にすると、ウェブサイト上のリンクをクリックしたユーザーは、そのリンクのターゲットに接続されます。

開始 URL チェックの主な目的は、ブックマークや外部リンクを介してウェブサイト上のランダムな 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 クロージャが機能しません。
  • リファラーヘッダーを検証します。リクエストの Referer ヘッダーに、別の Web サイトではなく、保護されている Web サイトの Web フォームデータが含まれていることを確認します。このアクションは、外部の攻撃者ではなく、自分の Web サイトが Web フォームの送信元であることを確認します。これにより、ヘッダーチェックよりもCPU負荷の高いフォームのタグ付けを必要とせずに、クロスサイトリクエストフォージェリ (CSRF) を防ぐことができます。Web App Firewall は、ドロップダウンリストで選択したオプションに応じて、次の 4 つの方法のいずれかで HTTP Referer ヘッダーを処理できます。
    • オフ-リファラーヘッダーを検証しません。
    • If-Present —リファラーヘッダーが存在する場合は、リファラーヘッダーを検証します。無効な Referer ヘッダーが見つかった場合、リクエストはリファラーヘッダー違反を生成します。Referer ヘッダーが存在しない場合、リクエストによってリファラーヘッダー違反は発生しません。このオプションにより、Web App Firewall はリファラーヘッダーを含むリクエストに対してリファラーヘッダー検証を実行できますが、ブラウザーがリファラーヘッダーを設定していないユーザーや、そのヘッダーを削除するウェブプロキシやフィルターを使用するユーザーからのリクエストはブロックされません。
    • 常に開始 URL を除く-Refererヘッダーを常に検証します。Referer ヘッダーがなく、要求された URL が StartURL 緩和ルールで除外されていない場合、リクエストはリファラーヘッダー違反を生成します。Referer ヘッダーは存在するが無効な場合、リクエストはリファラーヘッダー違反を生成します。
    • 最初のリクエスト以外は常に—リファラーヘッダーを常に検証します。リファラーヘッダーがない場合は、最初にアクセスされた URL のみが許可されます。他のすべての URL は、有効なリファラーヘッダーがないとブロックされます。Referer ヘッダーは存在するが無効な場合、リクエストはリファラーヘッダー違反を生成します。

開始 URL の 1 つである「 セキュリティチェックからクロージャー URL を除外」設定は、「開始 URL チェックの変更」ダイアログボックスでは設定されませんが、プロファイルの「設定」タブで設定されます。この設定を有効にすると、Web App Firewall が URL 閉鎖基準を満たす URL に対してフォームベースのチェック（クロスサイトスクリプティングや SQL インジェクション検査など）をこれ以上実行しないように指示します。

注

リファラーヘッダーチェックと開始 URL セキュリティチェックは同じアクション設定を共有していますが、開始 URL チェックに違反せずにリファラーヘッダーチェックに違反することは可能です。違いはログに表示され、リファラーヘッダーチェック違反は開始 URL チェック違反とは別にログに記録されます。

リファラーヘッダーの設定 (OFF、If-Present、AlwaysExceptStarUrls、AlwaysExceptFirstRequest) は、制限の少ないものから最も制限の厳しいものの順に並べられており、次のように機能します。

OFF:

  • リファラーヘッダーがチェックされていません。

存在する場合:

  • リクエストにはリファラーヘッダーがありません-> リクエストは許可されています。
  • リクエストにはリファラーヘッダーがあり、リファラーURLはURLクロージャーにあります->リクエストは許可されています。
  • リクエストにはリファラーヘッダーがあり、リファラー URL は URL クロージャーに含まれていません -> リクエストはブロックされています。

スタートURL以外は必ず:

  • リクエストにはリファラーヘッダーがなく、リクエストURLは開始URLです。-> リクエストは許可されます。
  • リクエストにはリファラーヘッダーがなく、リクエストURLは開始URLではありません。->リクエストはブロックされています。
  • リクエストにはリファラーヘッダーがあり、リファラーURLはURLクロージャーにあります->リクエストは許可されています。
  • リクエストにはリファラーヘッダーがあり、リファラー URL は URL クロージャーに含まれていません -> リクエストはブロックされています。

最初のリクエスト以外は必ず:

  • リクエストにはリファラーヘッダーがなく、セッションの最初のリクエスト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 を正確に定義し、それ以外は何も定義していないことを確認してください。ワイルドカード、特にドットとアスタリスク ( .*) メタ文字とワイルドカードの組み合わせを不注意に使用すると、意図していなかった Web コンテンツへのアクセスをブロックしたり、開始 URL チェックでブロックされたはずの攻撃を許可したりするなど、望ましくない結果になる可能性があります。

ヒント

URL 命名スキームの SQL キーワードの許可リストに -and- を追加できます。たとえば https://FQDN/bread-and-butterの例。

URL チェックを開始
August 15, 2023
寄稿者: 
C
August 15, 2023
寄稿者: 
C

この記事の概要

サイトに関するフィードバック | プライバシーと法令 | Cookieの設定 | 同意設定 | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.