网站漏洞怎么自查?AI 渗透测试工具清单与修复优先级(2026 实战)

网站有没有漏洞,自己先查一遍比等别人来查便宜得多。本文给出完整自查流程:资产清点、端口与证书扫描、OWASP 应用层检查、WordPress 专项、报告分级与 24 小时/7 天/30 天修复顺序,并说明 AI 在哪些环节真能省事、哪些环节一定会骗你。
网站漏洞自查与 AI 渗透测试工具清单与修复优先级

前阵子刷到一个视频,标题挺冲:你的网站有没有漏洞?让 AI 黑一遍就知道了。底下评论一半在问”怎么黑”,一半在问”会不会被查水表”。

这个思路本身没错,只是说法容易被误解。绝大多数中小站点真正需要的不是”被黑一遍”,而是在自己还能控制的时候,把自己的暴露面摸清楚一遍。这两件事用的工具、看的指标、踩的坑几乎一模一样,区别只有一个:你有没有权利对这台机器动手。

我把这几年给站点做安全自查的流程整理成一套可以照抄的步骤,从资产清点、端口扫描、应用层检查,到拿到报告怎么分级、怎么排修复顺序。中间会重点讲清楚 AI 在哪些环节真能省事、哪些环节它一定会骗你。

先立个规矩:全文所有命令都只适用于你自己的服务器,或者你拿到了书面授权的资产。这一条不是免责声明,是实操前提——第 2 节会展开讲清楚边界在哪。

一、为什么”自己先查一遍”比”等别人来查”便宜得多

先看一组方向性的数字。公开的站点入侵事件里,绝大多数入口不是那种需要 0day 的高深漏洞,而是几类”老到掉牙”的问题:

  • 组件版本没升:建站程序、插件、框架的已知漏洞,公开 PoC 满天飞,扫描器一把梭就能命中;
  • 管理后台裸奔:默认路径、弱口令、没有登录失败限制、没有二次验证;
  • 敏感文件可访问:备份包、.git 目录、.env、调试日志直接躺在网站根目录下;
  • 服务不该暴露:数据库、Redis、phpMyAdmin、运维端口开在公网上;
  • 传文件的目录能执行脚本:上传目录没有禁止 PHP 解析,一张伪装成图片的脚本就能落地上线。

这几类问题有个共同点:它们全都是”可自查”的。不需要逆向、不需要挖 0day,按清单走一遍就能发现。真正的成本不在于”查不出来”,而在于”没人去查”。

而一旦被人先发现,成本结构会完全变样:站点被挂马、被做成跳转、被塞进黑帽 SEO 页面、数据库被拖走——清理、备案申诉、搜索引擎降权、客户信任损失,加起来远超一次自查投入的时间。

更现实的一层:搜索引擎和浏览器现在会主动标记风险站点。用户点进来先看到一屏红色警告,业务基本就断了。这种事发生一次,恢复期是按周算的。

二、先划红线:这件事的合法边界在哪

这一节放在前面,因为它是很多人第一脚就踩进去的地方。”给我网站做渗透测试”和”给别人网站做渗透测试”,法律上是两件完全不同的事,中间隔着《网络安全法》和《刑法》第二百八十五条。

把边界写成可以对照的清单:

场景 能不能做 说明
自己买的服务器、自己备案的域名可以完全自主,想怎么测怎么测,但别把机器测挂
公司内部系统(你在职且被授权)可以,要书面口头同意不算,要有邮件或工单;范围、时段、限速都写清楚
客户站点(签了安全评估合同)可以,按合同严格限定在授权域名和 IP 范围内,超出即违规
朋友的站、”帮他看看”必须书面授权关系好不等于有授权,出事时聊天记录救不了你
任何第三方站点不能未经授权的扫描行为本身就可能构成违法,不看结果
云主机上的站点(阿里云/腾讯云等)先看条款部分云厂商禁止主动扫描,即使扫自己实例也可能触发风控封禁

除法律边界外,还有几条纯技术性的自保原则,实测踩过才知道疼:

  • 限速:扫描并发一高,小内存 VPS 直接被自己扫挂。nmap 用 -T3 不要 -T5,模板扫描工具把速率压到 20 请求/秒以内;
  • 备份先行:开扫之前做一次完整快照。WAF 拦截、日志暴涨、数据库连接数打满,都可能需要回滚;
  • 别打生产库:涉及写操作的验证(比如上传测试、注入验证)一定放在测试环境或做了快照的实例上;
  • 选低峰时段:晚上十点以后或者周末,出问题影响面最小;
  • 不要在 WAF 规则里”顺便”关掉防护:有人为了扫得干净先把安全组全放开,扫完忘了改回来,等于自己开了后门。

三、AI 在这件事里到底能干什么,不能干什么

视频里”让 AI 黑一遍”这个说法,最有价值的部分其实不是”AI 会攻击”,而是AI 能把一堆散落的原始输出翻译成你能看懂的结论。这两者的差别很大。

先把能力边界摆清楚,后面所有步骤都建立在这张表上:

环节 AI 能做 现实表现
列检查清单✅ 很擅长告诉它技术栈(Nginx + PHP + MySQL + WordPress),能给出针对性清单
解释扫描结果✅ 很擅长把 nmap/nuclei 的原始输出贴进去,让它标出哪些是真风险
生成检测模板✅ 擅长按你的站写 nuclei 模板、写 curl 检查脚本、写批量核对脚本
读日志找异常✅ 擅长access.log 里的爆破特征、扫描器 UA、异常高频路径,识别度高
写修复配置⚠️ 能用但要复核nginx/php.ini 片段基本可用,但版本语法差异会出错
确认漏洞真实存在❌ 不能它看不到你的响应报文,只能根据你描述推断
给出准确 CVE 编号❌ 经常编编出不存在的 CVE、错配版本号,是幻觉重灾区
判断业务逻辑漏洞❌ 不能越权、支付逻辑、优惠券叠加,必须人按业务流走一遍
替你承担后果❌ 当然不能授权和法律责任永远在动手的人身上

一句话总结用法:让 AI 当”解读器”和”清单生成器”,别让它当”决策者”。所有”这个漏洞是不是真的”的判断,必须落到你自己看到的那一行响应上。

四、第一步:资产清点,先搞清楚自己有什么

绝大多数人漏掉的不是漏洞,而是漏掉资产。主站查得很仔细,结果三个月前建的测试站还挂在公网,用的是一年前的建站程序;或者主域名安全了,dev.xxx.com 的解析还指向一台早就没人管的机器。

清点要覆盖这几类:

  • 主域名与所有子域名:证书透明度日志是最好用的查询入口,历史上签发过的证书都能翻出来,比自己回忆靠谱;
  • 公网 IP 与开放端口:一台机器可能不止跑一个站,也可能不止开 80/443;
  • 老版本目录:/old、/bak、/test、/www2、/2024 这类,是最常见的遗留入口;
  • 备份与配置文件:backup.zip、www.tar.gz、.env、.git/、wp-config.php.bak;
  • 第三方接入:CDN 回源地址、对象存储桶权限、短信/支付回调地址、微信公众号服务器配置。

清点完做一张表,把”资产—责任人—是否还在用”三列填满。你会发现总有几行填不出来,那几行就是最该优先处理的地方。

五、第二步:外部暴露面扫描(端口 · 服务 · 证书)

这一层是纯技术活,工具成熟,命令固定。

5.1 端口与服务识别

从外部视角扫自己,才能知道外面到底能看见什么。用低速率扫描,避免把机器打挂:

nmap -sV -Pn --top-ports 1000 -T3 你的服务器IP

重点看三类结果:

  • 不该开的端口:3306(MySQL)、6379(Redis)、27017(MongoDB)、9200(ES)、11211(Memcached)出现在公网结果里,一律优先封掉。Redis 未授权访问是最经典的失守路径之一;
  • 不该露的版本号:nmap 的 -sV 会把服务版本打出来。版本号暴露本身不是漏洞,但等于把”该试哪个 PoC”直接告诉对方;
  • 运维端口:22、面板端口(8888、888、8080)、phpMyAdmin,能改成非默认端口 + IP 白名单的,就别留在公网裸奔。

把结果里所有对外开放的端口写成一张对照表,逐个回答”这个端口为什么必须对公网开放”。答不上来的,关掉。

5.2 证书与 TLS 配置

用开源脚本跑一遍 TLS 细节,比自己看配置快:

testssl.sh https://你的域名

关注三件事:是否还支持 TLS 1.0/1.1(该关)、是否启用弱加密套件、证书有效期与链是否完整。顺带看一眼证书透明日志里有没有你不知情的子域名证书。

5.3 HTTP 响应头

一行命令就能拿到,很多问题一眼可见:

curl -sI https://你的域名

对照下面这张表逐项看:

响应头 缺了会怎样 建议值
Strict-Transport-Security首次明文请求可被降级劫持max-age=31536000; includeSubDomains
X-Content-Type-Options浏览器猜类型,可能把图片当脚本执行nosniff
X-Frame-Options可被 iframe 嵌套做点击劫持SAMEORIGIN
Content-Security-PolicyXSS 少了一道关键防线按实际资源域配置,先 report-only
Referrer-PolicyURL 里的敏感参数外泄给第三方strict-origin-when-cross-origin
Server / X-Powered-By主动暴露版本信息能删就删(server_tokens off)

这些头不修不会立刻被黑,但它们是”低成本高收益”的一类动作,一个 nginx 配置文件就能补齐,优先级应该排在前面。

🔧 我整理的软件库

这些年折腾服务器、虚拟化和开发环境,装过的系统镜像、运维工具、开发套件、数据库与中间件,我都归档在自建的文件库里,持续补充新版本。没有弹窗广告,不强制注册,需要什么直接取。

进入软件库 →

常用工具随手可取 · 不定期补档

六、第三步:应用层自查,按 OWASP 的顺序走

外部扫描结束后,进入真正花时间的一层。这里不要”想到哪查到哪”,按 OWASP Top 10 的类别顺着走,不容易漏。

6.1 注入类

自查动作不是去猜 payload,而是检查代码里有没有拼接 SQL。所有数据库查询必须走参数化(预处理语句)。PHP 里 PDO 开 ATTR_EMULATE_PREPARES = false,不要用字符串拼 WHERE id = $id。

如果你用现成的建站程序或框架,这一层基本由程序本身负责,你要做的是保持版本最新,别用改过源码的”优化版”。

6.2 跨站脚本(XSS)

自查方法很简单:找一个会把用户输入回显到页面的地方(搜索框、评论、个人资料),输入一段带尖括号的文本,提交后看页面源码——如果尖括号原样出现在 HTML 里没被转义,就是存储型或反射型 XSS。

修复靠输出编码,不靠输入过滤。HTML 上下文用 htmlspecialchars($s, ENT_QUOTES, 'UTF-8'),JS 上下文用对应的 JSON 编码,别一套函数处处用。

6.3 越权(这类最容易被忽略,也最致命)

登录用户 A 改成用户 B 的 ID,能不能看到 B 的订单?普通用户直接访问管理员接口 URL,会不会返回数据?这类问题扫描器基本扫不出来,因为请求格式完全合法,只是权限判断缺失。

自查方法是人肉走一遍业务流:把所有”带 ID 参数”的接口列出来,换 ID、换角色、去掉 token 各试一次,看返回。这一层是 AI 帮不上忙的地方,必须人工。

6.4 文件上传与目录遍历

两个检查点:上传目录能不能执行脚本(.php/.jsp/.asp 是否被解析)、路径参数里加 ../ 能不能跳出限定目录。

上传目录的正确做法是禁止脚本执行,而不只是限制扩展名。nginx 里给上传目录单独一段配置直接拒绝 PHP:

location ^~ /uploads/ {
    location ~ .(php|php5|phtml|jsp|asp)$ { deny all; }
}

另外把上传文件名重命名成随机串 + 校验真实 MIME(读文件头,不看扩展名),能挡掉绝大多数上传型 getshell。这块的完整踩坑可以看站内那篇《PHP2Shell 漏洞修复指南》,讲得比这里细。

6.5 信息泄露

按这几个 URL 手工试一遍,命中任何一个都要立刻处理:

https://你的域名/.git/config
https://你的域名/.env
https://你的域名/backup.zip
https://你的域名/wp-config.php.bak
https://你的域名/phpinfo.php

.git 目录泄露是最常见的严重问题——拿到 .git 就等于拿到完整源码,里面的数据库密码、密钥一应俱全。部署时务必用 git archive 导出干净文件,或者确认 web 根目录下没有 .git。

6.6 弱口令与后台暴露

后台地址全站扫描器都知道,改成非默认路径只能降噪不能防住。真正有效的是三条:登录失败次数限制(比如 5 次锁 15 分钟)、强制强密码、能开二次验证就开。

给自己的管理账号跑一次弱口令核对(只对你自己的账号跑):确认不在常见口令列表里,且不与任何其他站点重复。后台账号泄露的后果比漏洞严重得多。

七、第四步:WordPress / 建站程序专项检查

大量中小站点跑在 WordPress 上,它有自己的一套自查清单,单独列出来。其他建站系统(织梦、帝国、Z-Blog 等)思路基本一致:版本、插件、接口、目录权限。

7.1 版本与插件

看点网站在源码里有没有暴露版本号(?ver= 参数、meta generator 标签),以及能不能枚举出用户和插件列表。WordPress 的 REST 接口默认就能列出作者:

curl -s https://你的域名/wp-json/wp/v2/users

如果这条直接返回用户名列表,说明用户枚举是通的,等于把爆破的一半工作量送出去了。处理方式是禁用 REST 用户端点,或者限制只对登录用户开放。

插件是 WordPress 最大的风险面——核心程序更新很勤,插件却常年不升。做法很朴素:只装必须的插件,不用就删掉(不是停用,是删除),保留的每周看一次更新。

7.2 xmlrpc 与登录保护

xmlrpc.php 是老牌的爆破入口,一次请求可以试几百个密码。不用离线发布工具的话,直接禁掉:

location = /xmlrpc.php { deny all; }

另外确认登录页有限流,后台 cookie 走 HTTPS,wp-config.php 权限收到 640 以内。

7.3 目录与文件权限

一张表说明白该设成什么:

对象 权限 原因
目录755组和其他用户不可写,避免被植入文件
普通文件644同上
wp-config.php640 或 600含数据库密码,不能让 web 进程组外可读
上传目录755 + 禁脚本执行权限管不住执行,配置才管得住
网站根目录归属非 rootweb 进程以 root 跑,等于把整机交出去

顺手把目录列表关掉(nginx autoindex off,apache Options -Indexes),否则一个没放首页文件的目录就把所有文件名摊开了。

八、第五步:报告怎么读——分级、误报与”看起来吓人”

扫描器最喜欢干的事,是把一堆”可能”报成”严重”。拿到报告先做三件事,别急着照着修。

8.1 先分真假

任何一条发现,都要能用一句具体的话回答:”它是怎么被确认的?”如果答案是”模板匹配到了版本号字符串”,那它大概率只是版本特征,不是实际可利用。真正需要立刻处理的,是那些已经拿到实际响应证据的条目——比如读到了数据库报错、返回了目录内容、拿到了不该拿的数据。

8.2 再看等级

CVSS 分数是通用参考,但对个人站点要换个算法。判断优先级用三个问题:

  • 利用门槛:需要登录吗?需要特定插件吗?还是任何人都能直接打?
  • 影响面:能读数据、能写文件、能执行命令,还是只泄露一点版本信息?
  • 暴露程度:这个入口在公网上,还是只在内网/后台上?

三个都偏”容易”的,当天就得处理;只是信息泄露且入口隐蔽的,可以排到下一轮。

8.3 让 AI 帮你做交叉核对

这一步是 AI 真正省时间的地方:把原始输出整段贴给 AI,问它”哪些条目有实际证据、哪些可能只是版本匹配”,再让它按上面的三个维度分类。它给出的分级可以作为初稿,但每一条最终结论都要你自己回查一次——尤其是它给出的 CVE 编号,一定要去官方漏洞库核对,模型编造 CVE 的概率相当高。

九、修复顺序:24 小时 / 7 天 / 30 天

清单一次性摆出来看着吓人,其实按时间窗排开就清楚了。

时间窗 要做的事 验收标准
24 小时内关掉不该开放的端口;删除/移走敏感文件(.git、备份包、.env);建站程序与插件升到最新;改掉所有复用的弱口令外部端口扫描只剩业务必需;敏感 URL 全部返回 404/403
7 天内补齐安全响应头;上传目录禁执行;关闭目录列表;后台加登录限流与二次验证;数据库/Redis 只监听本地响应头检测全绿;尝试访问上传目录里的脚本被拒绝
30 天内上 WAF 或反向代理防护;做异地备份并验证能恢复;开启日志告警;把权限最小化(web 进程非 root、数据库账号只授权必需库表)能从备份完整恢复一次;攻击特征能在日志里被看见并告警

这个顺序的逻辑是:先堵最容易被打的,再补影响面最大的,最后建长期防线。反过来做——先研究 WAF 规则再不管端口——是最常见的时间错配。

十、加固清单:一次做完能挡掉大部分自动化攻击

下面这张表是我给自己站点定型的加固项,可以直接照抄。想省事的,先把这套跑完,能拦掉互联网上绝大多数无差别扫描。

加固项 做法
安全组/防火墙只放行 80/443 和必要的运维端口,运维端口加 IP 白名单
最小权限web 进程非 root;数据库账号只授权当前库;禁用 FILE 权限
版本管理建站程序、插件、PHP 保持最新;不用”优化版/绿色版”
备份异地 + 离线各一份;定期做恢复演练,没恢复过的不算备份
WAF / 反代开源方案足够用,站内那篇《雷池 SafeLine 部署》就是干这个的
日志与告警保留 30 天以上;对 404 暴涨、登录失败激增设阈值告警
HTTPS 强制全站 301 跳转 + HSTS;混合内容清零

10.1 日志里该盯什么

自查不是一次性的,日常看日志比定期扫描更早发现问题。关注这几个特征:

  • 同一个 IP 在短时间内请求大量不存在的路径(典型扫描器行为);
  • /wp-login.php 或后台路径的 POST 频率异常(爆破);
  • 访问 .env、.git、phpmyadmin 这类”探测性”路径;
  • UA 是空字符串或明显伪造的(curl 默认、python-requests 等);
  • 上传目录下出现新文件,尤其是扩展名可执行的文件。

把 access.log 按 IP 和路径统计一下,最前面的几条通常就能看出有没有人正在扫你。这活让 AI 做很合适——贴几百行日志进去,问”哪些 IP 的行为像自动化扫描”,比人眼翻快得多。

如果你已经中招、或者自查发现的东西超出预期(比如上传目录里有陌生脚本、数据库出现不认识的账号),不确定该按什么顺序处置,可以直接找我:微信/手机 17712677007。先在消息里说清三件事——站点用的什么程序、异常是什么时候发现的、有没有可用备份,比笼统问”我被黑了怎么办”能快很多。手上有备份的情况下,多数情况当天能处理完。

十一、六个常见误区,比漏洞本身更容易坑人

误区一:把”扫过”当成”安全了”。扫描器只覆盖已知特征的已知问题,覆盖不到业务逻辑,也覆盖不到 0day。扫完没报警,只说明”没有常见的那些问题”。

误区二:照 AI 给的 CVE 编号去修。AI 编 CVE 不是偶发,是高频。所有编号必须去官方漏洞库核对版本区间,否则你可能在修一个不存在的漏洞,同时漏掉真实存在的那个。

误区三:把安全当一次性项目。漏洞是会随版本更新、插件安装、配置改动重新出现的。最低频率也该做到季度一次自查,重大改动之后单独跑一次。

误区四:只查首页。真正的入口往往在后台、上传接口、API、老版本目录。只扫一个首页 URL,等于只检查了大门锁没锁,窗户全开着。

误区五:为了”扫干净”临时关防护。关 WAF、放开安全组、关掉限流,扫完忘了恢复。这类”自己制造的风险”比被攻击还常见。

误区六:备份和站点在同一台机器上。勒索类攻击最先加密的就是同机备份。异地或离线至少占一样,而且必须验证过能恢复。

十二、写在最后

回到开头那个视频标题。”让 AI 黑一遍”这个说法抓眼球,但真正落地的姿势其实是三层:

  • 工具干体力活:端口、证书、响应头、版本、目录,这些用现成工具跑,别手工翻;
  • AI 干翻译活:把原始输出变成”哪些该修、按什么顺序修”,写修复配置和验证脚本;
  • 人干判断活:授权边界、真伪确认、业务逻辑、修复后的复核,这些只能自己来。

三层里前两层能省掉七八成时间,最后一层省不掉,也不该省。一个能跑通的流程,比一份看起来很吓人的扫描报告有用得多——毕竟报告是给别人看的,漏洞是给自己留的。

站内还有几篇相关的,串起来看会更完整:《群晖 NAS 勒索病毒防护与应急响应指南》讲的是中招之后的处置顺序,《雷池 SafeLine 怎么部署》补的是 WAF 这一层,《PHP2Shell 漏洞修复指南》是升级 PHP 之后必须做的那步验证。

你自己踩过哪种坑,或者自查时遇到过”报告说很严重但看不懂”的条目,欢迎评论区说说,我挑典型的单独写一篇拆解。

✍️ 关于作者

IT 峰哥,互联网技术从业者。日常折腾服务器、虚拟化、数据库与企业级应用,关注开源系统的二次开发与基础设施落地。这里记录的是踩过的坑和验证过跑得通的方案,不是转述文档。

交流:微信 / 手机 17712677007(注明来意,看到会回)

文中方案如有疏漏,欢迎在评论区指正 · 技术问题欢迎交流

默认

Agent2API 深度拆解:17 家 AI 客户端聚合成一个 OpenAI 兼容网关,原理、部署与风险红线

2026-11-3 14:51:22

默认

Immich 自建相册怎么部署?手机照片自动备份到私有云,告别网盘年费

2026-11-7 22:35:22

❯
搜索