☰

Htacess Helicon APE 誤検知 403 失敗

tag-icon • tag-icon iis .htaccess mod-rewrite
Htacess Helicon APE 誤検知 403 失敗

web.config書き換えルールの代わりに、私はヘリコンAPEApache の.htaccess機能をエミュレートするため。

.htaccessunion、delete などのコマンドの受け渡しへのアクセスを制限する機能の一部として、サーバー全体に適用される大きなユニバーサル ファイルがあります。

しかし、コード行が誤検知を引き起こし、適切な URL へのアクセスをブロックするという問題が発生しています。

失敗している URL は次のとおりです。http://example.com/union-contracts

で以下のコマンドを使用するとweb.config、不足しているすべての URL が にプッシュされますindex.php。

   <httpErrors errorMode="Custom" existingResponse="Replace">
        <remove statusCode="404" subStatusCode="-1" />
        <error statusCode="404" path="/index.php" responseMode="ExecuteURL" />
    </httpErrors>

403を返すhtaccessルール

RewriteCond %{QUERY_STRING} (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC]
RewriteRule . - [F,L]

最終的には、たとえば union をブロックし続けたいのですが、誤検知の行を変更するだけで済みます。ルール-contractsにハードコードすること.htaccessも望んでいないことに注意してください。

そもそも URL がどのように生成されるかを思い出した後、XAMPP の htaccess で問題を再現することができました。

ウェブサイトの訪問者側では、URL にアクセスすると、サーバーが 404 エラーを生成します。URL を最後の部分だけにフィルターし、その文字列をデータベースでチェックして、保存されている URL と一致するかどうかを確認します。一致する場合は、その 404 をブラウザーに渡さず、URL が見つからない場合にのみ渡します。

IIS が 404 エラーを生成すると、URL は次のようになります。

index.php?404;http://example.com:80/union-contracts

しかし、その形式ではブラウザに渡されません。

答え1

私はコメントで「何か他のこと」が起こっているに違いないという懸念を表明しましたが、とにかく...

そもそもトリガーされるべきではない（つまり「できない」）ルールの例外を書くのは難しい。それは完全な推測作業だ。結局のところ、なぜ例外名誉を受けるのでしょうか?

このルールは、いくつかの「大きな」理由により、すでに特定のリクエストを回避するはずです。

  1. リクエストにクエリ文字列が含まれていません。
  2. 条件内の正規表現（条件パターン) は、URL のどの部分とも一致しません (クエリ文字列内であっても)。

上記の 2 を考慮すると、正規表現にはすでに指定されたリクエストに一致しない十分な例外が含まれているので、どうすれば「別の」例外を実装できるでしょうか?

修正することができます条件パターンハイフン（-）が「union」という単語の後に続く場合を避けるために、否定先読み。 例えば：

(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union(?!-)|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode)

したがって、上記は に一致しますXunionが、 には一致しません。Xunion-ここで、 はX最初の文字列の1つです。交替グループ（つまり(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00)）。

または、次のいずれかのキーワードの後に​​ハイフンが続く場合:

(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode)(?!-)

（アップデート：次の2つの提案はおそらく機能しないでしょう。なぜなら、ディレクティブは処理されるだけだからです。後/index.phpIIS はすでに URL を書き換えています。その時点では、URL パスは ではなく になります/union-contracts。

または、RewriteRuleURL パスが で始まる場合と一致しないように を変更します/union-(ただし、これにより、ルールがブロックしようとしている XSS 試行のバックドアが提供される可能性があります)。例:

RewriteRule !^/?union- - [F]

(少なくとも Apache では、フラグが使用されるLときにフラグは必須ではなくF、暗黙的に使用されます。)

あるいは、別のルールを上を既存のルールの前に追加すると、クエリ文字列で始まりクエリ文字列を持たない URL を要求する場合に例外が作成されます/union-(ただし、他のルールを信じるなら、これは矛盾しているように見えます)。例:

RewriteCond %{QUERY_STRING} ^$
RewriteRule ^/?union- - [L]

ただし、ファイルの後半に URL を何らかの方法で書き換える必要がある他のルールがある場合、これらのルールは実行されないため、リクエストが「壊れる」可能性があります。

Helicon-APE/mod_rewriteは、ディレクトリのようなコンテキスト（例：.htaccessスタイル構文と対照的にサーバまたは仮想ホストコンテキスト)? ただし、実際には、上記のディレクティブには影響しないはずです。

アップデート：IIS が 404 エラーを生成すると、URL は次のようになります。

index.php?404;http://example.com:80/union-contracts

ああ、そうだ！そのURL意思元の条件に引っかかる。つまり、mod_rewriteディレクティブは処理されるようだ後IISのweb.configの「書き換え」！このため、これらの「セキュリティ」ディレクティブは、想定クライアントからの最初のリクエストで実行されます。そして....

URLを最後の部分だけフィルターし、その文字列をデータベースでチェックして、保存されたURLと一致するかどうかを確認します。

URL をアクティブに解析し、必要な部分だけをフィルタリングしているので、これらの「セキュリティ」チェックは、少なくともこれらの「404」リクエストに対しては冗長であると思われます。(実際、直接リクエストされる可能性のある実際のファイル (つまり、404 以外のリクエスト) によっては、この性質の悪意のあるクエリ文字列が実際にどの URL に対してもセキュリティ上の脅威となる可能性がありますか?)

上記の2つの提案は、状態ハイフンが「union」キーワードの後に​​続くインスタンスを除外する、またはどれでもキーワードはここでも適用され、当面の問題を解決すると思われます。

また、フォームの URL にindex.php?404;遭遇したとき (つまり、IIS によって書き換えられた後) にすべてのチェックを中止することもできます。 (すべての mod_rewrite ディレクティブは同様の「セキュリティ」チェックであると想定していますか?)

例えば、次のコードを上脚本の.htaccess、前に既存の指令:

RewriteCond %{QUERY_STRING} ^404;
RewriteRule ^/?index\.php - [L]

これにより、フォームの URL に/index.php?404;......遭遇したときに、それ以上の処理が行われなくなります (スクリプト内で URL を解析しているため)。

関連情報