脆弱性診断でwp_unslash() に関する検出が34件あったけど修正が必要なのかお問い合わせを受けました。
wp_unslash() は “地味だけど超重要”
wp_unslash() の未使用は、WordPress以外のPHP開発者にとっては盲点です。
一般的なPHPフレームワークでは不要な処理のため、
WordPress独自の仕様を知らないと当然のように見落とされます。
WordPress では、$_POST や $_GET の入力に対して自動的にバックスラッシュを追加する処理があるため、それを回避して正しい動作をさせるための関数がwp_unslashです。
私たちの診断ツールでは、この wp_unslash() の未使用による
「不正なスラッシュ付き入力処理」もASTベースで精密に検出しています。
// ✗ wp_unslash() がない → スラッシュ残留リスク
$name = sanitize_text_field($_POST['name']);
// ✓ 正しい処理
$name = sanitize_text_field(wp_unslash($_POST['name']));直接的な「脆弱性」ではないのですが、セキュリティ的・機能的な問題やバグの原因になります。特に WordPress の入力処理においては重大です。
wp_unslash() が抜けていると起こる 4 つの主なセキュリティ・動作リスク
❶アクセス制御・機能判定の不整合
起こること
- 入力値が意図しないスラッシュ付きで比較され、if ($val === ‘admin’) 等の判定に失敗
- フォームやAPIでの「選択肢一致」や「認可処理」が壊れる
影響
- 「正しいユーザーなのに制限される」
- 本来「管理者のみ許可する処理」が、誰でも通過してしまうという深刻な問題が発生する可能性
❷データ不整合・UI表示の崩れ
起こること
- O’Reilly が O\’Reilly として保存
- 比較、検索、フィルタ処理が正常に動作しない
影響
- 管理画面や検索結果で「思った通りに出ない」
- 意図しない文字列がDBや画面に残る
➌二重エスケープによる XSS 誘発の可能性
起こること
- スラッシュ入りの入力が sanitize→escape→decode の流れで意図せず復元
- 場合によっては
<script>タグが復元されて実行される
影響
- 特定状況下で XSS が発生（例：
htmlspecialchars_decode()などと併用時）
❹アップロード制限のバイパス
起こること
- バックスラッシュが MIME チェックや拡張子バリデーションに影響
- 偽装ファイル（例：
image.jpg.php）の判定に失敗する可能性
影響
.phpや.svgなどの危険ファイルが画像として保存される可能性- 特に画像アップロードフォームで致命的リスク
まとめ
wp_unslash() を使わないと、「正しく受け取れない・正しく保存できない・正しく守れない」という3拍子のリスクがあります。
これらはすべて、表面には現れにくいけれど、深刻な脆弱性やバグの温床になります。
このようなリスクは他の脆弱性診断では検出されないので34件も検出できてリスク回避につながったのではないかと思います。
Leave a Reply