SQL注入漏洞防护
PHP应用中最危险的漏洞之一就是SQL注入，攻击者通过构造恶意SQL语句直接操作数据库。防护的核心在于杜绝用户输入直接拼接SQL查询：
/[#'"x00]/这类破坏性字符| 危险函数 | 替代方案 | 防护等级 |
|---|---|---|
| mysql_query | PDO::prepare | ★★★★★ |
| addslashes | PDO::quote | ★★★☆☆ |
XSS跨站脚本防御
反射型XSS和存储型XSS都会窃取用户会话，防御需要多管齐下：
Content-Security-Policy: default-src 'self'限制资源加载源文件上传漏洞处置
任意文件上传可能导致webshell植入，这几个防护点必须检查：
location ~* .php$ { deny all; }CSRF跨站请求伪造
看似合法的恶意请求会冒充用户操作，防护方案要组合使用：
会话安全加固
PHP的会话机制默认存在安全隐患，需要针对性强化：
CSRF令牌放session里才是王道，你想啊，cookie这玩意儿在浏览器端就是个透明盒子，XSS漏洞分分钟就能把里头的令牌偷走。session就不一样了，数据都锁死在服务器内存里，除非黑客能黑进你的服务器，否则根本摸不着边儿。而且每个令牌最好用一次就废掉，跟银行发的短信验证码似的，转完账立马失效，这样就算被截胡了也白搭。
光靠令牌还不够狠，关键操作得再加道保险。比如改密码这种大事儿，光有CSRF令牌哪够啊，必须让用户再输一遍旧密码，或者整个短信验证码二次确认。就跟银行转账似的，输完密码还得来个手机验证，双保险才够稳。令牌生成也得讲究，不能随便整个随机数糊弄，得用加密强度够高的算法，长度至少32位以上才扛得住暴力破解。
如何判断我的PHP网站是否存在SQL注入漏洞？
最直接的检测方法是使用单引号(‘)等特殊字符测试表单输入，如果页面报错或返回异常结果，说明存在漏洞。也可以使用sqlmap等自动化工具扫描，但要注意获得授权后再测试生产环境。
为什么htmlspecialchars不能完全防御XSS攻击？
htmlspecialchars默认只转义双引号，如果HTML属性使用单引号包裹，攻击者仍可突破防御。必须添加ENT_QUOTES参数同时转义单双引号，且要确保在输出时指定正确的字符编码。
文件上传功能为什么不能仅靠扩展名验证？
攻击者可以伪造.jpg文件实际包含PHP代码，或利用Apache的解析漏洞（如test.php.jpg）。必须结合MIME类型检测和文件内容校验，同时服务器要禁用上传目录的脚本执行权限。
CSRF令牌应该存储在session还是cookie？
推荐存储在session中更安全。如果存在cookie里，攻击者可能通过XSS漏洞窃取令牌。令牌应该是一次性且绑定具体操作，重要操作还需配合二次验证机制。
PHP会话固定攻击如何防范？
在用户登录成功后必须调用session_regenerate_id()重新生成会话ID，避免攻击者提前获取有效会话。同时设置session.cookie_httponly=1防止JavaScript读取，会话超时 设为30-120分钟。
