WordPressサイトのセキュリティ対策として、「特定のドメインのみアクセスを許可する（ホワイトリスト）」という実装はよく使われます。
一見すると安全に見えますが、この対策は条件によっては簡単に突破されます。
この記事では、Web Security Academyのラボ「SSRF with filter bypass via open redirection vulnerability」をもとに、以下を解説していきます。
- オープンリダイレクトを利用したSSRFのバイパス手法
- 実際の攻撃の流れ
- WordPressで起こり得るリスク
- セキュリティ診断時のチェックポイント
SSRFとは何か
SSRF（Server-Side Request Forgery）は、サーバーに対して意図しないURLへリクエストを送らせる攻撃です。
攻撃者は、外部からは直接アクセスできない内部リソースに対して、サーバー経由でアクセスします。
例えば以下のような対象です。
- 内部管理画面（192.168.x.x）
- クラウドのメタデータAPI
- 非公開の管理用エンドポイント
今回のラボのポイント
このラボでは、在庫確認機能が内部APIにアクセスしています。
ただし、次の制限があります。
- stockApiは、ローカルアプリのみアクセス可能
- 外部URLはブロックされる
つまり、単純に以下のようなリクエストは失敗します。
stockApi=http://192.168.0.12:8080/admin直接SSRFはできない設計になっています。
オープンリダイレクトの見つけ方
サイト内をBurp Suiteなどで観察すると、次のようなURLが見つかります。
/product/nextProduct?currentProductId=2&path=/product?productId=3この path パラメータに注目します。
外部URLで検証
/product/nextProduct?currentProductId=2&path=http://example.comこのリクエストに対して302リダイレクトが返ってきます。
つまり、任意のURLへリダイレクトできる状態です。
これはオープンリダイレクト脆弱性です。
SSRFとの組み合わせ
通常のリクエストは以下のようになっています。
stockApi=/product/stock/check?productId=2&storeId=1これをオープンリダイレクトに置き換えます。
stockApi=/product/nextProduct?currentProductId=2&path=http://192.168.0.12:8080/adminただし、このままではパラメータが壊れるため、URLエンコードします。
stockApi=%2Fproduct%2FnextProduct%3FcurrentProductId%3D2%26path%3Dhttp%3A%2F%2F192.168.0.12%3A8080%2Fadmin攻撃の流れ
- 改ざんしたリクエストを送信
- サーバーが
/product/nextProductにアクセス - オープンリダイレクトが発動
- 内部URLへ転送される
/adminにアクセス成功
このようにして、ローカル制限をバイパスできます。
最終ステップ─ユーザー削除
管理画面にアクセスすると、以下のURLが確認できます。
/admin/delete?username=carlosこれを同様にSSRFで実行します。
stockApi=%2Fproduct%2FnextProduct%3FcurrentProductId%3D2%26path%3Dhttp%3A%2F%2F192.168.0.12%3A8080%2Fadmin%2Fdelete%3Fusername%3Dcarlosこれにより、ユーザー削除が実行され、ラボ解決となります。
SSRFでは、エラーメッセージやレスポンスの変化から内部に到達しているかを判断することが重要です。
実際の見分け方については、こちらの記事で詳しく解説しています。
この攻撃の本質
重要なのは次の点です。
ホワイトリストによる制限は、最初のURLしか見ていないケースが多いということです。
今回のように、
- 許可されたドメインにアクセスさせる
- その内部でリダイレクトさせる
ことで、最終的に内部ネットワークへ到達できます。
つまり、検証すべきは「最初のURL」ではなく「最終的な到達先」です。
WordPressで起こり得るSSRFの例
この問題はWordPressでも十分に起こり得ます。
外部リソース取得機能
- OGP取得
- RSS取得
- 画像URLからの読み込み
ユーザーがURLを入力できる場合は注意が必要です。
プラグインのAPI連携
- Webhook送信
- 外部サービス連携
- 自動投稿ツール
URL指定が可能な機能はすべてSSRFの入口になります。
リダイレクト処理
- redirect_to パラメータ
- next / url / path
オープンリダイレクトが存在すると、SSRFの踏み台になります。
WordPressは公開直後からさまざまなスキャンを受けます。
実際のアクセスログから、その挙動を分析した記事はこちらです。
WordPressセキュリティ診断チェックポイント
実務で使える観点をまとめます。
URL入力機能の有無
- 外部URLを受け取る機能があるか
- API・画像・Webhookなど
存在するだけでSSRFの可能性があると考えます。
ホワイトリストの実装内容
- ドメイン制限しているか
- サブドメインの扱いは適切か
ドメイン制限のみでは不十分です。
リダイレクトの検証
- 外部URLへリダイレクトできないか
- パラメータで遷移先を操作できないか
オープンリダイレクトの有無は必ず確認します。
内部IP制御
- 127.0.0.1
- localhost
- 192.168.x.x
これらへのアクセスが拒否されているかを確認します。
リダイレクト追従設定
- HTTPクライアントが自動追従するか
追従する場合はリスクが高くなります。
URL検証の範囲
- 最初のURLのみ検証していないか
- 最終到達先まで検証しているか
ここが最大のポイントです。
なお、WordPressのセキュリティ対策は個別の対策ではなく、全体で考える必要があります。
最低限押さえておきたい基本設定はこちらでまとめています。
まとめ
ホワイトリストによるURL制限は、適切に実装されていない場合、簡単にバイパスされます。
オープンリダイレクトが存在すると、内部ネットワークへのアクセスが可能になります。
SSRF対策では、以下を徹底する必要があります。
- リダイレクト先の検証
- 内部IPのブロック
- 最終到達先のチェック
単純なドメイン制限では不十分です。