phpEnv 默认配置存在SQL注入高危风险：magic_quotes_gpc未关闭、PDO预处理被模拟、错误信息全暴露、MySQL以root运行且权限过大；须关闭display_errors、禁用模拟预处理、限制数据库账号权限并统一utf8mb4字符集。
phpEnv 是本地开发常用环境套件，但它默认配置往往忽略数据库安全细节。直接用它跑未加固的 PHP 代码，mysqli_query() 或 PDO::query() 拼接用户输入，等于给 SQL 注入敞开大门。
为什么 phpEnv 环境下更容易中招
phpEnv 默认启用 magic_quotes_gpc（已废弃）或未禁用 PDO::ATTR_EMULATE_PREPARES，导致预处理语句“假参数化”——实际仍是字符串拼接。同时，错误信息常全量暴露（如 SQLSTATE[42000]），攻击者能靠报错反推表结构。
- phpEnv 的 MySQL 默认以
root@localhost启动，权限过大 -
php.ini中display_errors = On+error_reporting = E_ALL是常态 - 多数示例代码直接用
$_GET['id']做查询，没做类型校验
必须关闭的 phpEnv 危险配置项
打开 phpEnv 安装目录下的 php\php.ini，确认以下几项已修改：
-
display_errors = Off（生产/测试环境都该关） -
log_errors = On且error_log = "D:/phpEnv/logs/php_error.log" -
magic_quotes_gpc = Off（该配置自 PHP 5.4 起移除，若存在则必须删掉整行） -
pdo_mysql.default_socket若为空，建议显式指向mysql.sock路径，避免连接被劫持
重启 Apache/Nginx 后，用 phpinfo() 页面核对是否生效。
立即学习“PHP免费学习笔记（深入）”；
PDO 连接必须加的三个关键选项
在 phpEnv 下用 PDO，不设这三项，prepare() 就形同虚设：
-
PDO::ATTR_EMULATE_PREPARES => false：强制走 MySQL 原生预处理，禁用 PHP 模拟（否则?会被 PHP 自己拼进 SQL） -
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION：让错误抛异常，而非静默失败，便于日志捕获 -
PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"：避免因字符集不一致导致宽字节注入（如 GBK 下的%df%27绕过）
完整示例：
$dsn = 'mysql:host=127.0.0.1;dbname=test;charset=utf8mb4';
$options = [
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES => false,
PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"
];
$pdo = new PDO($dsn, 'webuser', 'pass123', $options);
phpEnv 数据库账号最小权限实操
别再用 root 连接应用。进 phpEnv 自带的 phpMyAdmin（通常是 http://127.0.0.1/phpmyadmin），执行：
- 新建账号：
CREATE USER 'app_rw'@'localhost' IDENTIFIED BY 'strong_pass'; - 仅授权当前库的读写：
GRANT SELECT, INSERT, UPDATE ON `myapp_db`.* TO 'app_rw'@'localhost'; - 立刻回收危险权限：
REVOKE DROP, ALTER, CREATE, FILE, PROCESS ON *.* FROM 'app_rw'@'localhost'; - 刷新权限：
FLUSH PRIVILEGES;
后续所有 PHP 代码里的 $username 都该换为 app_rw，密码也同步更新。哪怕注入得逞，攻击者也无法删库或写文件。
真正容易被忽略的是字符集与预处理的耦合问题：utf8mb4 不只是为了 emoji，它让 MySQL 原生预处理能正确识别多字节边界；而 PDO::ATTR_EMULATE_PREPARES => false 在 phpEnv 的旧版 PHP（如 7.2）上若未显式设置，会默认开启模拟——这时你写的 ? 全是假把式。
