```html

网络安全常见问题隐患

上个月帮一个做跨境电商的朋友看服务器日志，发现有人用 admin/123456 这个组合在半小时内试了四千多次登录。安全他的隐患后台入口就挂在公网上，连个验证码都没加。网络问题这不是安全段子，是隐患每天都在发生的日常。很多团队把功能跑通就上线，网络问题安全的安全事等“以后再说”——可攻击者从不等人。

弱口令这件事，隐患说了十年还是网络问题头号隐患。不是安全大家不知道，是隐患总觉得“我这个小破站没人盯”。但扫描器可不管你是网络问题谁，全网段批量扫，安全撞上一个算一个。隐患我见过最离谱的是某公司内部OA，管理员密码是 admin@123，数据库端口直接暴露在公网，还开了远程桌面。这相当于把钥匙插在门上，顺便贴了张纸条写“欢迎光临”。

再说注入。别以为用了ORM就万事大吉。我审计过一个小程序后端，代码里拼接SQL的地方藏得很深——在导出Excel的功能里，因为要动态排序，开发直接用了字符串拼接。参数是前端传的 orderBy 字段。攻击者构造一个 orderBy=id,(select 1 from (select sleep(5))a)，数据库直接卡死五秒。时间盲注，数据就这么一点点被抽走。ORM防的是常规查询，但总有人绕过去写原生SQL，还偏偏忘了参数化。

文件上传也是重灾区。很多系统只在前端用JS判断后缀名，后端收到文件直接存到Web目录。你改个 .jpg 为 .php，或者上传一个包含PHP代码的图片，配合解析漏洞就能执行任意代码。更隐蔽的是，有些系统虽然改了后缀，但没改文件内容——上传一个 .htaccess 文件，把 .jpg 当PHP解析，照样拿下。这种细节，开发文档里不会写，只有踩过坑的人才懂。

我个人的判断：八成以上的入侵事件，根源不是多高深的0day，而是配置疏忽和代码里的“图省事”。安全做的其实就是细节的堆叠——每个参数校验、每个权限判断、每个日志记录，少一个都可能成为突破口。

还有一类隐患经常被忽略：第三方组件和供应链。你用了一个npm包，它又依赖了二十个包，其中某个包两年前就停止维护了，里面有个反序列化漏洞。你根本不知道。Log4j2那个事闹那么大，就是因为几乎没人能完整画出自己的依赖树。现在很多团队开始用SCA工具扫，但扫出来的高危漏洞往往因为“升级会影响业务”而被搁置。风险就这么挂着，直到被利用。

再说个日常的——日志和监控。很多系统被入侵了几个月都不知道，因为日志只记录成功登录，失败尝试根本不记，或者记了但没人看。我习惯在服务器上装个简单的 fail2ban，至少能自动封掉暴力破解的IP。但更关键的是，你得知道正常流量长什么样。某次我发现一台服务器凌晨三点向外发送大量DNS请求，一查，已经被植入了挖矿木马，正在通过DNS隧道传数据。如果只看CPU和内存，根本发现不了。

最后提一句权限。最小权限原则喊了这么多年，实际落地时经常变成“先给管理员权限，方便调试”。数据库账号用root，应用账号用sa，云平台主账号AK写死在代码里。一旦代码泄露，攻击者直接拿到最高权限。我见过一个创业公司，所有微服务共用一个数据库账号，结果一个服务被攻破，全站数据裸奔。这种架构上的偷懒，后期改起来代价极大。

安全不是产品，是过程。没有一劳永逸，只有持续盯着。今天修好一个漏洞，明天可能又冒出一个。但至少，别让 admin/123456 这种组合出现在你的生产环境里。