WordPressのセキュリティというと、SQLインジェクションやXSSなどの技術的な脆弱性が注目されがちです。
しかし実際の攻撃では、仕様や設計のミスによって発生する「ビジネスロジック脆弱性」も多く利用されています。
これらはコードのバグではなく、本来想定していない使い方をされたときに成立する脆弱性です。
本記事では、PortSwigger Web Security Academy（WSA）のラボをもとに、
- WordPressで起こり得るビジネスロジック脆弱性のパターン
- 実際にどのように悪用されるのか
を整理して解説します。
ビジネスロジック脆弱性とは
ビジネスロジック脆弱性とは、アプリケーションの「仕様や処理の流れ」に起因するセキュリティ上の問題です。
例えば、
- 本来は1回しか使えないクーポンが何度も使える
- 認証の手順を飛ばしてログインできる
- 不正な値でもそのまま処理されてしまう
といったケースが該当します。
これらはSQLインジェクションのような技術的な攻撃とは異なり、正しい機能の組み合わせでも成立してしまうのが特徴です。
そのため、WAFやプラグインだけでは防げず、設計段階での考慮が重要になります。
これらの脆弱性に共通する設計ミスのパターン
- クライアントを信頼している
- 状態（state）を正しく管理していない
- 入力値の扱いが統一されていない
- ビジネスルールがサーバー側で保証されていない
WordPressで起こるビジネスロジック脆弱性一覧
▼ 気になるジャンルから読むこともできます。
認証・アカウント系
2段階認証の認証コードの突破
2FAがあっても、検証処理に抜けがあると認証コードを突破されることがあります。実装の甘さがセキュリティを無効化する典型例です。
2段階認証の簡易バイパス
認証コードを入力しなくてもログインできてしまうケースがあります。「ある前提」で作られた処理が崩れると、認証は簡単に突破されます。
パスワードリセットトークンが検証されない脆弱性
パスワードリセット機能は、トークンの検証が不十分だと第三者に悪用されます。安全なはずの機能が攻撃経路になる例です。
パスワード変更機能の設計ミス
パスワード変更機能などで、ユーザー間の処理が適切に分離されていないと、他人のアカウントに影響を与える可能性のある脆弱性です。
必要な認証をスキップできてしまう脆弱性
ログイン処理の順序が崩れると、本来必要な認証をスキップできてしまいます。状態管理のミスが直結する脆弱性です。
暗号オラクルで認証の回避
暗号処理の挙動を利用することで、認証をバイパスできるケースがあります。一見安全そうな仕組みでも、使い方次第で脆弱性になります。
入力値・データ処理系
メールアドレスの長さの制限ミス
入力値の扱いが統一されていないと、想定外のデータが通過し、権限チェックをすり抜ける可能性がある脆弱性です。
メール変更だけで管理画面に入れてしまう設計ミス
同じ機能でもチェックの厳しさが場所によって異なると、弱い箇所が突破口になります。
メールアドレスの解釈のズレ
メールアドレスの仕様差や解釈の違いを利用すると、本来の制限を回避できてしまうケースがあります。
EC・金額・クーポン系
価格改ざん
価格をフロント側で制御していると、リクエストを書き換えるだけで不正な価格が通ってしまいます。
カート改ざん・マイナス数量
数量にマイナス値を入れることで、意図しない価格計算が行われることがあります。単純な入力でも危険です。
大量注文で価格がマイナスになる脆弱性
注文数や計算ロジックの不備により、合計金額がマイナスになるケースがあります。基本的な計算でも油断できません。
クーポン割引が無限に使えるロジック脆弱性
本来制限されるべきクーポンが何度でも使えると、ビジネスルール自体が崩壊します。
クーポンと残高が増殖するロジック脆弱性
クーポンと残高処理の組み合わせ次第で、資金が無限に増える状態が発生します。
ワークフロー・状態管理系
ECサイト購入フローの脆弱性
本来の手順をスキップできると、前提となるチェックが無効化されます。
まとめ
ビジネスロジック脆弱性は、コードのバグではなく「設計の前提」が崩れることで成立します。
そのため、WAFやプラグインだけでは防げず、アプリケーション全体の処理や流れを見直す必要があります。
今回紹介したように、
- 認証の流れ
- 入力値の扱い
- クーポンや価格の計算
- 購入フロー
といった一見問題なさそうな機能でも、組み合わせや想定外の使い方によって脆弱性になります。
まずは、自分のWordPressサイトで同じような問題が起きていないかを確認してみてください。
下のチェックリストから簡単に確認できます。
WordPressビジネスロジック脆弱性チェックリスト
このチェックリストは、WordPressサイトにおける仕様や設計のミスによる脆弱性を簡易的に確認するためのものです。
すべて満たしていても安全とは限りませんが、1つでも該当する場合は、ロジックの見直しが必要です。
認証・アカウント系
- ログイン後の状態はサーバー側で管理しているか
- 認証コード（2FA）は必須チェックになっているか
- パスワードリセットトークンは一度しか使えないか
- 他ユーザーの情報にアクセスできない設計になっているか
入力値・データ処理系
- メールアドレスの形式チェックは統一されているか
- 入力値の長さ・形式はサーバー側でも検証しているか
- フロントとバックエンドで処理の差がないか
EC・金額・クーポン系
- 価格や数量はサーバー側で再計算しているか
- マイナス値や異常値を拒否しているか
- クーポンは使用回数・条件が正しく制御されているか
- 割引後の価格が0円未満にならないか
ワークフロー・状態管理系
- 購入フローは順序通りにしか進めないか
- 必須ステップをスキップできないか
- セッションやカート情報は正しく管理されているか
ビジネスロジック脆弱性は、仕様の理解がないと見つけにくい領域です。
個別記事では具体例を詳しく解説しているので、気になるテーマから確認してみてください。