thinkphp本身不直接处理数据库弱口令，但会因配置文件硬编码密码、未限制登录尝试等加剧风险；防御关键在于移出config/database.php、用环境变量加载凭证、强化登录校验与失败锁定、禁用默认账号及危险函数。
ThinkPHP 本身不直接处理数据库弱口令，但会暴露或加剧弱口令风险——比如在配置文件中硬编码密码、未限制登录尝试、未校验密码强度。防御弱口令攻击的关键动作不在框架层“拦截密码”，而在于切断弱口令的使用路径和放大效应。
数据库连接凭证不能写死在 config/database.php
这是最常被扫描到的弱口令入口：攻击者通过访问 /config/database.php（若 Web 目录权限配置错误）直接拿到明文账号密码，再对 3306 端口暴力爆破。
- 把
config/database.php移出 Web 可访问目录，例如放到/app/config/或项目根目录外 - 改用环境变量加载数据库凭证：
env('DB_USERNAME')+env('DB_PASSWORD')，并在.env文件中配置（确保.env不可被 HTTP 访问） - Linux 下执行
chmod 600 .env，禁止组和其他用户读取
登录接口必须做密码强度校验与失败锁定
ThinkPHP 不内置密码强度规则，也不自动封禁 IP 或账户。若仅靠前端提示“请输强密码”，后端不做校验，等于形同虚设。
- 在登录前调用自定义验证器，例如：
$this->validate($data, ['password' => 'require|length:8,32|regex:/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[\W_]).+$/']) - 失败计数存 Redis，键名建议为
login:fail:{$username}，TTL 设为 3600 秒 - 每次登录失败时
INCR login:fail:{$username}，达到 5 次后返回429 Too Many Requests并拒绝后续请求 - 登录成功后立刻
DEL login:fail:{$username}，避免网络超时导致误锁
避免复用 MySQL 默认账号与空密码
很多 ThinkPHP 部署直接用 root@localhost 连接数据库，且未改默认密码——这会让 3306 扫描器 1 秒内命中。
- 创建专用数据库用户：
CREATE USER 'tp_app'@'127.0.0.1' IDENTIFIED BY '<strong>随机32位密码</strong>'; - 仅授予最小必要权限：
GRANT SELECT,INSERT,UPDATE,DELETE ON `myapp_db`.* TO 'tp_app'@'127.0.0.1'; - 禁用远程登录：
REVOKE ALL PRIVILEGES ON *.* FROM 'tp_app'@'%';（防止攻击者从外网连 3306） - 确认
mysql.user表中无空密码用户：SELECT user,host,authentication_string FROM mysql.user WHERE authentication_string = '' OR authentication_string IS NULL;
PHP 运行时需禁用危险函数并加固会话
弱口令常与会话固定、远程代码执行组合利用——比如先爆破出测试账号，再借助 system() 函数反弹 shell。
- 在
public/index.php开头插入：ini_set('disable_functions', 'exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec'); - 登录成功后立即调用：
session_regenerate_id(true)，防止攻击者预设PHPSESSID接管会话 - 强制会话 Cookie 属性：
ini_set('session.use_only_cookies', 1); ini_set('session.cookie_httponly', 1); ini_set('session.cookie_secure', 1);（HTTPS 环境下）
真正难防的不是“弱密码本身”，而是弱密码被用于横向移动——比如一个低权限后台账号被爆破后，通过模板注入或日志文件包含拿到服务器权限。所以密码强度只是第一道门，后面每道链路（会话、函数禁用、权限隔离）断掉一环，整条攻击链就崩了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
