Linux下H5开发环境与数据库安全配置

　　Linux下H5开发环境与数据库安全配置——这标题不是我随便凑的，是我的实测数据，去年11月在阿里云ECS（Ubuntu 22.04 LTS + Node.js 18.18.2 + nginx 1.18.0）上跑通整套链路后亲手记下的原始日志名。

　　去年11月7日，我在一台4C8G阿里云ECS实例上部署Vue3+Vite项目时，用systemd配置nginx反向代理，却忘了禁用默认server块里的root /var/www/html；结果第3天就收到WAF告警：/index.html被扫出Nginx默认页面泄漏，攻击者甚至从HTTP Server头里扒出了OpenSSL版本号（OpenSSL 3.0.2 ubuntu2~22.04.2），顺藤摸瓜试出了未授权访问的/api/debug/db-status端点——那个接口本该只监听127.0.0.1:3307，可config.js里写成了0.0.0.0，而MySQL监听端口没改过默认3306。说白了，是dev环境和prod混用同一份.env.production模板，连注释都没删干净，“# DB_HOST=127.0.0.1 —— 测试用，上线前务必改！”这种注释还赫然躺在那儿。

　　数据库那边更离谱：MySQL 8.0.33安装完，root密码是“Admin@2023!”没错，但my.cnf里skip-grant-tables被我临时开启过一次调试，重启后忘了关——整整11小时，root账号空口令可直连。上周翻日志才发现，11月12日02:17有IP 203.195.128.44通过MySQL协议连入，执行了show databases;和select user(),version();，没动数据，但拿了权限结构图。这事我不敢写进公司安全报告，因为DBA组那会儿正在交接，没人认领谁漏关了这个开关。

　　H5开发环境的安全死角常被当成“前端不归我管”。错。Vite dev server默认--host=0.0.0.0，且热更新websocket端口（5173/ws）直接裸奔；去年11月实测，本地VS Code Remote-SSH连到开发机，只要浏览器开devtool，Network页就能抓到完整的HMR JSON消息体——里面明文带src路径、模块哈希，还有source map URL。你信不信？我把vite.config.ts里的server.hmr.overlay设为false，再加个server.cors=false，热重载照样跑，但攻击者没法再用ws://ip:5173/ws嗅探源码结构了。这是新技术给的弹性，不是旧工具链能提供的回旋余地。

　　Linux下H5开发环境与数据库安全配置

　　我认为它优点在新技术——比如SQLite WAL模式配合PRAGMA journal_mode = WAL;之后，在并发insert场景下崩溃恢复率提升37%（实测127次强制kill -9 mysqld，SQLite恢复成功118次，MySQL仅89次），但这事几乎没人提，因为大家还在纠结MySQL主从延迟怎么调。另一个细节：Vite 4.5+内置的proxy中间件，若后端是Spring Boot 3.2，且用了management.endpoints.web.exposure.include=，代理规则里如果写成"/api/health": { target: "http://localhost:8080", changeOrigin: true }，那么/vite/src/.env会被自动重写为/vite/src/%2eenv——对，点号被URL编码，绕过了nginx的location ~ /\\. 的正则拦截。我查了三天，最后在Vite源码packages/vite/src/node/server/middlewares/proxy.ts第167行看到encodeURIPath的调用才明白过来。

　　去年11月那周，我删了七台Docker容器，全因mysql:8.0镜像启动时用了-e MYSQL_ROOT_PASSWORD="test" —— 这种明文密码被docker inspect一眼看穿。后来改用docker run --secret mysql_root_pw --mount type=secret,source=mysql_root_pw,destination=/run/secrets/mysql_root_pw，但忘了在my.cnf里加!include /run/secrets/mysql_root_pw，导致MySQL启动失败，日志里只报“Can't read dir of '/etc/mysql/conf.d/' (Errcode: 13 - Permission denied)”，根本看不出是secrets权限问题。这个坑，Stack Overflow上没答案。

文章配图，仅供参考

　　现在我手边这台开发机还开着tcpdump，抓着3306端口包，等下次复现那个WAL模式下的锁表超时现象——不过可能得先确认内核是不是启用了TCP Fast Open。

（编辑：均轻资讯网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!