PHP参数本身无漏洞,漏洞源于未经校验/转义直接使用:拼SQL导致注入、拼路径引发遍历、输出HTML引发XSS、unserialize/eval触发RCE;必须用预处理、白名单、realpath、htmlspecialchars等严格防护。
PHP 接收参数本身没有漏洞,漏洞出在「未经校验/转义就直接使用」——比如拼进 SQL、写入文件、执行系统命令或输出到 HTML。
PHP 不会对 $_GET、$_POST、$_REQUEST、$_COOKIE 做任何过滤,所有值都是字符串,且可能被篡改。攻击者可任意构造 ?id=1%27%20UNION%20SELECT%20... 或 ?file=../../etc/passwd。
$_GET['id'] 拼接 SQL 查询$_POST['template'] 去 include() 文件
$_COOKIE['theme'] 直接 echo 到页面(XSS 风险)is_numeric() ——它会接受 "123abc" 或 "+123"
用 mysql_query() 或 mysqli_query() 拼接字符串已淘汰;即使加了 mysqli_real_escape_string(),也难防多字节编码绕过或宽字节注入。唯一可靠方式是预处理语句。
try {
$pdo = new PDO($dsn, $user, $pass);
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ? AND status = ?");
$stmt->execute([$_GET['id'], 'active']); // 参数自动绑定,不参与 SQL 解析
} catch (PDOException $e) {
// 不暴露敏感错误信息
}bindValue() 和 bindParam() 区别在于类型绑定时机,日常用 execute() 数组传参更安全直观PDO::ATTR_EMULATE_PREPARES = false,禁用模拟预处理,防止绕过当参数用于 file_get_contents()、include() 或 fopen() 时,../ 可能突破目录限制读取敏感文件。
include('templates/' . $_GET['tpl'] . '.php') 是高危写法$allowed = ['home', 'about', 'contact']; if (!in_array($_GET['tpl'], $allowed)) die('Invalid template');
basename($_GET['file']) 截取文件名,再拼路径;或用 realpath() 检查是否在允许目录内:$target = realpath('/var/www/logs/' . $_GET['file']);
$allowed_root = '/var/www/logs/';
if ($target === false || strpos($target, $allowed_root) !== 0) {
http_response_code(403);
exit;
}htmlspecialchars() 能防大部分 XSS,但它只处理 HTML 实体,不防 JavaScript 事件属性、CSS 表达式或 href="javascript:" 类型的注入。
ENT_QUOTES 和字符集:htmlspecialchars($input, ENT_QUOTES, 'UTF-8')
htmlspecialchars(),要用 json_encode($input, JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS)
value="= $val ?>")时,确保 $val 已经过 htmlspecialchars(),否则闭合引号后可插入任意属性HTMLPurifier 或严格白名单解析器最常被忽略的一点:很多团队只防 SQL 和 XSS,却忘了 unserialize() 和 eval() 这类“参数驱动执行”的危险函数——只要参数可控,它们就是远程代码执行(RCE)的入口。这类调用应当彻底从生产代码中移除。