URLのエンコード疑問符(%3F)による403 Forbiddenエラー

問題の説明

Apacheサーバーを最新版に更新した後、以下のような現象が発生しています：

GETパラメータにエンコードされた「?」（%3F）を含むURLへのアクセスで「403 Forbidden」エラーホが頻発
PHPのrawurlencode()関数で「?」をエンコードすると確実に発生する
特にユーザー入力をもとに生成するURLで問題が表面化

発生条件の例

php

<!-- PHPコード例:「?」が含まれると403エラー発生 -->
<a href='test?a=<?=rawurlencode($test);?>test</a>

この現象は、2024年7月以降のApache更新（2.4.59/2.4.60以降）でセキュリティ対策が強化されたことに起因します。サーバーログに「AH10508: Unsafe URL with %3f URL rewritten without UnsafeAllow3F」が記録されている場合、本問題に該当します。

背景：セキュリティ脆弱性(CVE-2024-38474)

Apacheの更新によるこの挙動変更には重大な背景があります：

CVE-2024-38474という深刻な脆弱性が発見された（スコア9.1/10）
改ざんされた%3Fを含むURLを介した攻撃を防ぐため
Apacheがエンコードされた?を含むリクエストをデフォルトでブロック
この対策が一部アプリケーションの正常動作を妨げる結果に

実装可能な解決方法

方法1: UnsafeAllow3F フラグによる一時的対処（非推奨）

最も簡単ですがセキュリティリスクが高い方法です。

.htaccess ファイルの修正例：

apacheconf

# 変更前
RewriteRule (.+) index.php?p=$1 [QSA,L]

# 変更後 - UnsafeAllow3Fフラグ追加
RewriteRule (.+) index.php?p=$1 [QSA,L,UnsafeAllow3F]

注意

この方法は脆弱性を再び開放することになります。公式ドキュメントでも「一時的な回避策」と明記されており、恒久的な解決策としては推奨されません。

方法2: RewriteRule の修正（推奨）

最も安全で一般的な対処法です。クエリ文字列（?）を使わないようにルールを修正します。

apacheconf

# 変更前（問題の原因）
RewriteRule ^(.+)$ index.php?url=$1 [L]

# 変更後（安全なバージョン）
RewriteRule ^(.+)$ index.php [L]

ポイント

主要フレームワークの最新版（Symfony, CraftCMSなど）ではすでにこの対応がされています。使用しているFWのアップデートを確認しましょう。

方法3: HTMLエンティティ置換法

コード修正のみで対処したい場合の選択肢：

php

<?php
// 「?」をHTMLエンティティ(&#63;)に予め変換
$safeParam = rawurlencode(str_replace('?', '&#63;', $userInput));
?>

<a href="test.php?param=<?= $safeParam ?>">リンク</a>

特徴：

サーバーサイドの変更が必要ない
クライアント側で自動的に?が?に復元される
URL構造を変えずに済む

方法4: GETパラメータ設計の見直し（根本的解決）

長期的に安全なアーキテクチャを構築する方法です：

markdown

# 改善前の問題のある設計
https://example.com/search?query=画像%3Fcategory=cat

# 改善後の安全な設計
https://example.com/search/画像?category=cat

改善ポイント	具体的な変更方法
パスパラメータの活用	`/user/{id}`のようにURLパスを使う
連続パラメータの回避	`%3F`の連鎖を発生させない
パラメータ構造の簡素化	ネストしたクエリ構造を平坦化する

ベストプラクティスと推奨解決策

公式推奨手順

Apacheを最新版(2.4.61+)に更新
apt upgrade apache2 (Ubuntu)
yum update httpd (CentOS/RHEL)
最新版には改良パッチが含まれます
UnsafeAllow3F依存回避
下位互換を維持しながらセキュリティ強化
URL設計のリファクタリング
${パスパラメータ}?${クエリパラメータ}形式の採用

緊急時の対応フロー

開発者向け重要アドバイス

rawurlencode()の代替検討
RFC3986準拠のurlencode()との違いを理解し、状況に応じて使い分け
ホスティング環境の注意
Stratoなどの特定ホスティングでは独自設定が存在
ブラックハット期限への備え
2024年中に攻撃詳細が公開予定のため急ぎ対応が必要

bash

# Apacheバージョン確認コマンド（重要）
apachectl -v

修正後は必ず「/%3Fを含むURL」の動作テストを行い、脆弱性状態を確認してください。セキュリティと機能性のバランスを考慮した実装が求められます。

関連記事

URLのエンコード疑問符(%3F)による403 Forbiddenエラー ​

問題の説明 ​

発生条件の例 ​

背景：セキュリティ脆弱性(CVE-2024-38474) ​

実装可能な解決方法 ​

方法1: UnsafeAllow3F フラグによる一時的対処（非推奨） ​

方法2: RewriteRule の修正（推奨） ​

方法3: HTMLエンティティ置換法 ​

方法4: GETパラメータ設計の見直し（根本的解決） ​

ベストプラクティスと推奨解決策 ​

緊急時の対応フロー ​

開発者向け重要アドバイス ​