WAFで保護されたサイトに対してPenTestを実行する場合、Pentesterはテスト品質を向上させるために何を知っておくべきですか？

Question

私はたくさんのWebアプリケーションの前でWAFを実行しており、Appsは定期的にテストされています。テスターにある種のライブログを提示してテストを改善したいと考えています。ペンテスターに役立つ情報は、Server-Viewから何ですか？

目的はテスターを締め出すことではなく、WAFと内部保護をバイパスするための可能な方法を見つけることです。

編集：それは単なるWAFテストベッドです。アプリ内の脆弱性は既知であり、ほとんどがWONTFIX [！sic！]としてマークされています。ご存知のように、それはその「自然に成長した」ものの1つです-昔々のJavaアプリ...

Polynomial · Answer

あなたのアプローチは2つあるべきです：

技術：
以下を確認します：

さまざまなエスケープシーケンス（\ x00、％s、\など）
Unicodeトリック（例：0x22で終わり、「」を生成するマルチバイト文字）
代替XSSメソッド（例：<img src=0 onerror=alert(1) />の代わりに<script>alert(1)</script>）
CookieおよびHTTPヘッダー内のさまざまな問題（XSS、SQLインジェクションなど）-多くの場合、WAFはこれらを逃します！

助言：
WAFが単なる絆創膏であり、壊れた手足を修復できないことをクライアントが理解していることを確認します。アプリケーションが悪用可能な方法で破壊された場合、WAF mayは攻撃を防止するか、影響の一部を軽減しますが、効果的であるかどうかを確認する方法はありません。

それは、両刃の剣でもあります。WAFが悪用できないバグはalwaysは悪用できないため、修正する必要はありません（少なくとも急いで）。。ブラウザおよびHTML/CSS/JavaScript/SQL/XML /サーバー側の言語などは常に進化しているため、古いバグを悪用できる新しい悪用手法が登場する可能性があります。

私が付け加えたいもう1つのポイント：テストがweb-appを対象としていて、notが特に展開したWAFソリューションを対象としている場合、クライアントに無効にするように強く勧めますテスト期間中、ステージングサイトのWAF。そのままにしておくと、アプリケーションのセキュリティポスチャを合理的に見積もるのがはるかに難しくなります。つまり、テストから得られる価値が少なくなります。 WAFのテストに本当に関心がある場合は、追加のテスト日後でを実行して、WAFを有効にした場合と有効にしていない場合の見つかった問題の悪用可能性を比較できます。

rook · Answer

Webアプリケーションファイアウォール（WAF）の背後にあるWebアプリケーションを攻撃するには、3つの方法があります。既存のWAFバイパスエクスプロイトを見ると、2つの主要なカテゴリに分類されていることがわかります。過度に制限されている、または実際の攻撃と正確に一致しないため、一連のルールをバイパスできます。 WAFバイパスには3番目のカテゴリがあり、WAFバイパスのエクスプロイトは必要ありません。

WAFプリプロセッサ攻撃は、WAFのルールセットで処理される前に、リクエストから攻撃ペイロードを覆い隠すか削除しようとすることを目的としています。 WAFプリプロセッサ攻撃である2つのエクスプロイトは次のとおりです。

PHPIDSには安全でない「重複の削除」プリプロセッサがありましたを使用して、33回重複するペイロードを隠すことができます。（免責事項：これは私の悪用です）

IBM WebSphereには安全でない「コメントの削除」プリプロセッサーがありましたを使用して、ペイロードを隠すことができます。
WAFルールセット攻撃は、弱いルールセットを悪用して、攻撃者が有効な攻撃文字列を送信できるようにします。この場合、ルールは非常に単純化されているため、検出を回避するために攻撃を変更できます。 Webアプリケーションファイアウォールの背後にあるWebアプリケーションを攻撃するには、2つの方向があります。

1つの方向は、XSSやSQLiなどの一般的な脆弱性の悪用を試みることです。違反したルールを特定し、攻撃のペイロードを変更して、このルールを回避してみてください。ルールは Regex Debugger を使用して監査できます。RegExBuddyはこのプロセスで私のお気に入りのツールです。 SQLiを利用できるようになったら、アプリケーションのSQLiの脆弱性を検索します。たとえば、WAFで検出されずにMySQLデータベースでsleep(30)を実行する変更された文字列がある場合、この文字列を使用して、アプリケーションのブラインドSQLiをファズできます。 mod_securityをバイパスするように変更されたSQLインジェクションペイロードの例。これはブラックボックスアプローチであり、Webアプリケーション自体にはアクセスできませんが、攻撃者は常にWAFにアクセスする必要があります。

もう1つの方向は逆で、WAFなしでSQLiのような脆弱性を持つWebアプリケーションを悪用してから、WAFで検出されずにこの脆弱性を悪用する攻撃文字列を作成します。これはグレーボックスアプローチです。
WAFの背後にあるWebアプリケーションを攻撃する3番目の方法は、問題を完全に回避することです。 WAFがすべての攻撃を検出することは不可能です。 WAFで防止できないWebアプリケーションの一般的な脆弱性があります。 CSRF、 Mass Assignment 、安全でない直接オブジェクト参照、クリックジャッキング、暗号Oracle、認証/承認ロジックエラー...想像力を使用してください。