Awesome WAF 
Webアプリケーションファイアウォール（WAF）に関するセキュリティ観点のすべて。🔥
前書き： これは元々私自身のWAFに関するコレクションでした。ペネトレーションテスターや研究者の方々に役立つことを願い、オープンソース化しています。「コミュニティはお互いから学び合う」という言葉通りです。
簡潔な定義： ファイアウォールとは、Webアプリケーションとクライアントエンドポイントの間に配置されたセキュリティポリシーの実施ポイントです。この機能はソフトウェアまたはハードウェアで実装され、アプライアンスデバイス上、または一般的なOSが動作する標準的なサーバー上で動作します。スタンドアロンデバイスとして、または他のネットワークコンポーネントに統合される場合もあります。(出典：PCI DSS IS 6.6)
Webアプリケーションファイアウォールは、ユーザーとWebアプリケーションの間に位置し、悪意のあるアクティビティがWebアプリケーションに到達するのを防ぐ役割を担います。WAFはリクエストの悪意のある部分をフィルタリングするか、単にブロックします。
ぜひコントリビュートしてください。
目次：
はじめに：
WAFの仕組み：
- 一連のルールを使用して、正常なリクエストと悪意のあるリクエストを区別します。
- 学習モードを使用して、ユーザーの行動を学習することでルールを自動的に追加する場合もあります。
動作モード：
- ネガティブモデル（ブラックリストベース） - ブラックリストモデルは、事前に設定されたシグネチャを使用して、明らかに悪意のあるリクエストをブロックします。ネガティブモデルで動作するWAFのシグネチャは、特定のWebアプリケーションの脆弱性を悪用する攻撃を防ぐために特別に作成されています。ブラックリストモデルのWAFは、パブリックインターネットに公開されているWebアプリケーションに最適で、主要な脆弱性に対して非常に効果的です。例：
<script>*</script> 入力をすべてブロックするルールは、基本的なクロスサイトスクリプティング攻撃を防ぎます。
- ポジティブモデル（ホワイトリストベース） - ホワイトリストモデルは、特別に設定された基準に従ったWebトラフィックのみを許可します。例えば、特定のIPアドレスからのHTTP GETリクエストのみを許可するように設定できます。このモデルは、大規模な攻撃をブロックするのに非常に効果的ですが、多くの正当なトラフィックもブロックします。ホワイトリストモデルのファイアウォールは、限られたグループ（従業員など）のみが使用する内部ネットワーク上のWebアプリケーションに最適です。
- 混合／ハイブリッドモデル（包括モデル） - ハイブリッドセキュリティモデルは、ホワイトリストとブラックリストの両方を組み合わせます。設定の詳細に応じて、ハイブリッドファイアウォールは内部ネットワーク上のWebアプリケーションとパブリックインターネット上のWebアプリケーションの両方に最適な選択肢となります。良いシナリオとしては、Webアプリケーションがパブリックインターネットに面している場合（ブラックリストを使用）と、管理パネルを一部のユーザーのみに公開する必要がある場合（ホワイトリストを使用）が考えられます。
テスト手法：
チェックすべき場所：
- WAFを公開する一般的なポート（
80、443、8000、8080、8888）に常に注意してください。ただし、WAFはHTTPサービスが動作する任意のポートに簡単にデプロイできることに注意が必要です。まずHTTPサービスポートを列挙し、その後でWAFを探すのが良いでしょう。
- 一部のWAFはリクエストに独自のCookieを設定します（例：Citrix Netscaler、Yunsuo WAF）。
- 一部のWAFは別個のヘッダーに関連付けられます（例：Anquanbao WAF、Amazon AWS WAF）。
- 一部のWAFはヘッダーを変更し、文字を混同して攻撃者を混乱させることがよくあります（例：Netscaler、Big-IP）。
- 一部のWAFは
Serverヘッダーに自身を公開します（例：Approach、WTS WAF）。
- 一部のWAFはレスポンスコンテンツに自身を公開します（例：DotDefender、Armor、Sitelock）。
- その他のWAFは、悪意のあるリクエストに対して異常なレスポンスコードを返します（例：WebKnight、360 WAF）。
検出テクニック：
WAFを特定するには、それを（ダミーで）誘発させる必要があります。
- ブラウザから通常のGETリクエストを送信し、インターセプトしてレスポンスヘッダー（特にCookie）を記録します。
- コマンドライン（例：cURL）からリクエストを送信し、レスポンスのコンテンツとヘッダーをテストします（ユーザーエージェントは含めない）。
- ランダムなオープンポートにGETリクエストを送信し、WAFの正体を暴露する可能性のあるバナーを取得します。
- ログインページで、
" or 1 = 1 -- のような一般的な（簡単に検出可能な）ペイロードを注入します。
- 検索バー、問い合わせフォーム、その他の入力フィールドに
<script>alert()</script> のようなノイズの多いペイロードを注入します。
- URLの最後にあるランダムなパラメータにダミーの
../../../etc/passwd を付加します。
- URLの最後の任意のパラメータに
' OR SLEEP(5) OR ' のようなキャッチーなキーワードを追加します。
HTTP/0.9 のような古いプロトコルでGETリクエストを送信します（HTTP/0.9 はPOSTタイプのクエリをサポートしていません）。- 多くの場合、WAFは異なる種類のインタラクションに応じて
Server ヘッダーを変化させます。
- ドロップアクションテクニック - サーバーに対して生のFIN/RSTパケットを送信し、応答を特定します。
ヒント： この方法は、HPing3 や Scapy などのツールで簡単に実現できます。
- サイドチャネル攻撃 - リクエストとレスポンスコンテンツのタイミング動作を調査します。
ヒント： 詳細はこちらのブログ記事にあります。
