PHP request_order 配置詳解：為何 Dedecms 要求 CGP 及安全性分析

現象：Dedecms 安裝報錯

PHP 5.3 and above: Please set 'request_order' ini value to include C,G and P (recommended: 'CGP') in php.ini

預設 request_order = "GP" 導致 $_REQUEST 不包含 $_COOKIE，Dedecms 依賴 $_REQUEST 讀取 Cookie 參數，故報錯。改為 request_order = "CGP" 即解決。

request_order 作用機制

• PHP 5.3+ 新增，控制 $_REQUEST 合併順序與來源。
• 字母含義：C=Cookie、G=GET、P=POST。
• 順序決定同名鍵值覆蓋優先權（右側覆蓋左側）。

預設 GP 的安全考量

PHP 官方預設 GP（不含 Cookie）是為了防止 變量注入攻擊：

1. 攻擊者透過 Cookie 竄造 GLOBALS、_SESSION 等超全域變數。
2. 若 $_REQUEST 包含 Cookie，且程式碼直接使用 $_REQUEST['var'] 而未嚴格過濾，即可繞過 globals.php 等防護。
3. 僅合併 GET/POST 可減少攻擊面。

為何老舊系統需 CGP

早期框架（Dedecms、Discuz 早期版等）習慣用 $_REQUEST 統一讀取參數，且依賴 Cookie 傳遞某些狀態（如語言、主題）。改為 CGP 屬於相容性妥協，並非最佳安全實踐。

現代最佳實踐建議

1. 明確來源：直接使用 $_GET、$_POST、$_COOKIE，避免 $_REQUEST 歧義。
2. 輸入過濾：使用 filter_input()、驗證器、CSRF Token 等機制。
3. 配置原則：新專案維持預設 GP 或 GPC（若確需 Cookie），並審計所有 $_REQUEST 用法。

總結

request_order = "CGP" 解決相容性問題，但降低了預設防禦等級。長期應遷移至顯式超全域變數存取，並建立輸入驗證體系。