企业官网建设流程全解析

做网站安全评估或者攻击面梳理的时候，我经常要回答一个看起来很基础的问题：这个网站到底“长什么样”？这里说的不是页面好不好看，而是它背后的技术栈、服务器、域名解析、证书签发、CDN归属、WAF防护、框架指纹、子域名分布这一大堆公开信息。以前想把这些信息凑齐，得在好几个工具之间来回切换，费时费力还容易漏。最近GitHub上热度很高的开源项目Web-Check，就是专门把这堆事情做成一次“体检”的工具，有人调侃说它是“一键扒掉网站的底裤”——说通俗点，它是利用完全公开的数据，把一个网站暴露在外的信息全部翻出来整理成报告，属于典型的开源情报（OSINT，Open Source Intelligence）应用。

这个工具适合谁？安全工程师、渗透测试人员、做资产梳理的运维、搞威胁情报的分析师，甚至只是想保护自己站点的个人站长，都能从中找到价值。它最吸引人的点在于：开源、可自托管、检测维度非常全面，而且界面直观，不需要你去记一堆命令。这篇文章我就从信息收集的思维讲起，把Web-Check的核心能力、部署方式、实战用法和合规边界一次说清楚。

1. 为什么需要这样一把“透视镜”：从信息收集到OSINT的思维转变

1.1 传统信息收集的笨办法

我早期做网站评估时，流程大概是这样：先开一个终端查WHOIS，再换一个窗口查DNS解析记录，接着用curl看响应头，手动猜测站点用的什么框架；想看证书就得上第三方在线工具；想找子域名得再开爆破工具；最后还要把favicon下载下来，拿去搜索引擎里反查图标，试图发现同一主体的其他站点。一套下来，两三小时过去了，得到的信息还是零散的，没有统一保存，也没法直接整理成报告。

这是很多人的真实状态：不是不愿意做信息收集，而是收集本身太琐碎。更麻烦的是，有些信息之间是有联动关系的——比如证书的SAN列表里可能藏着没写进DNS枚举结果的其他域名；favicon的哈希值可能关联到同一个主体的十几个站点；robots.txt里可能写着后台路径，但没有上下文根本不知道怎么用。单看一条信息，价值不高；把多条信息串起来，才能形成“情报”。OSINT的核心恰恰是“对公开信息进行收集、关联、分析和推理”，而不是简单的“查一下”。

1.2 Web-Check的定位：把散装步骤收敛成一条流水线

Web-Check能火起来，本质原因是它解决了“信息孤岛”问题。你只需要输入一个域名，它就会自动并行地执行几十项检测：域名注册信息、DNS记录、TLS证书、HTTP响应头、安全头配置、robots.txt、security.txt、CMS指纹、Favicon哈希、Cookie属性、重定向、页面元数据、子域名枚举、常见端口开放情况，甚至页面引用了哪些第三方资源，都会汇总到一张结果页里。

它的定位非常清楚：不是漏洞扫描器，不做暴力破解放，也不主动攻击目标，只“看”目标主动暴露在公网上的信息。这种被动属性，决定了它的使用门槛低、合规风险相对可控，也正因为它不做主动攻击，很多安全团队愿意把它放进日常的侦察流程里作为第一步。

从项目形态上看，Web-Check基于SvelteKit开发，前端界面和后端逻辑都开源，支持本地运行、Docker部署和在线Demo。这意味着你可以完全自托管：把工具部署在自己的服务器或内部网络中，输入的目标域名、查询结果、关联关系都保留在自己手里。对于需要保密侦察目标的企业级安全团队来说，“数据不出门”这个特性比任何花哨功能都重要。

1.3 读了这篇文章能学到什么

接下来我会重点拆解三件事：第一，Web-Check到底能检测哪些内容，哪些检测项最有实战价值；第二，怎么把它部署起来并且配好数据源，让它发挥完整能力；第三，怎么把一堆检测结果串成资产情报图，用于攻击面管理、护网前自查或者日常的资产监控。最后我也会聊一下信息收集的合规边界，以及如何用这个工具反向检查自己的网站暴露面。

2. Web-Check到底能查出什么：核心检测维度拆解

2.1 一张表看清主要检测维度

以下是我个人实际使用中觉得最有信息量的一批检测项，整理出来方便你对照：

2.2 几个特别“出活”的检测项

光看表格可能还感受不到价值，我单独挑三个最容易被忽视、但实战效果极好的检测项来展开。

证书SAN列表是资产测绘的黄金入口。很多团队做子域名枚举只依赖DNS爆破或字典，却忽略了“证书”这张地图。当一个组织申请HTTPS证书时，经常会把多个域名写进SAN字段里，比如主站域名、邮件域名、登录域名、测试域名。Web-Check把证书的SAN列表直接展示出来，等于别人把自己的资产清单放到了你面前。我在实际项目里，靠这一条就发现过五个没有出现在任何DNS字典里的内部系统域名。这个检测项属于纯被动信息收集，只要目标网站开启了HTTPS，基本都是必拿信息。

Favicon哈希的关联能力非常强。网站的图标文件（favicon.ico）看起来不起眼，但它往往在同一组织内部被反复沿用。Web-Check会算出这个图标的哈希值，有了哈希值，你就可以去公共指纹库或搜索平台反查“还有哪些网站用了同一图标”，从而把彼此独立的域名关联到同一个主体下。这在识别钓鱼团伙的域名组、发现影子IT资产的时候特别好用。很多JS文件里的指纹信息可以混淆，但图标哈希很难让人想起来去改。

robots.txt是泄露路径的“说明书”。很多站长以为robots.txt只是给搜索引擎爬虫看的，却不知道它同时也在给攻击者画地图。Web-Check会把robots.txt内容完整呈现，你需要做的只是把里面Disallow的路径拆开，逐个拼接成URL去访问。我见过不少站点的robots.txt里写着/admin、/backup、/internal/api这样的路径，其中不少还没做IP白名单限制。这个检测项零成本，但产出往往比端口扫描还直观。

2.3 HTTP安全头、重定向和第三方资源：细节里的攻防信号

HTTP响应头是另一个信息密集区域。如果目标站点没有配置Content-Security-Policy，说明CSRF与XSS的缓解层少了一层；如果Strict-Transport-Security缺失，就需要考虑中间人劫持的可能。Web-Check把Server、X-Powered-By、Via头列出来，你很快能分辨前边是不是有CDN或WAF在挡，如果存在Via头或CF-Ray头，后续扫描时就要注意绕过缓存节点直接探测源站。

第三方资源列表常常被忽略，但其实它是判断“供应链风险”和“追踪画像”的关键。页面加载了哪些外部JS、字体、分析工具，Web-Check会一并整理。这些域名里如果出现不在预期内的海外统计平台，或者某个已经很长时间没人维护的公共库，就要留个心眼了。

3. 从零跑起来：部署方式与数据源配置

3.1 两种常用部署方式

Web-Check整体的部署思路很清晰，本质上是一个Node.js应用加上一组可选的第三方接口。最省事的方式是用Docker。我把命令写在下面，实际操作时建议以项目仓库的README为准，因为版本更新可能会调整镜像名或端口映射：

docker run -d -p 3000:3000 --name web-check lissy93/web-check

跑起来之后，浏览器访问http://localhost:3000就能看到输入框。如果你有一台长期在线的服务器，我更推荐用Docker Compose，把容器配置固定成文件，后面升级、重启都方便，同时还能把数据卷挂载出来保存配置。

另一种方式是从源码运行，适合需要改界面或者做二次集成的同学：

git clone https://github.com/lissy93/web-check.git cd web-check cp .env.example .env npm install npm run dev

开发模式默认也在3000端口监听。需要注意的是，源码模式下会启动本地的API服务，所有检测逻辑都跑在你自己机器上，这比直接用在线版更私密。

3.2 数据源API Key怎么配

Web-Check的大部分检测项，比如DNS查询、HTTP头、证书信息、robots.txt，都靠自身逻辑就能完成，不需要任何Key。但有几个检测项的“信息深度”取决于第三方数据源：比如子域名枚举、端口指纹、威胁情报关联。如果你希望这些检测项返回更丰富的数据，就需要去对应的第三方平台申请API Key，然后把Key填进.env文件或Docker环境变量里。

我建议这样配置：先不配任何Key跑一遍，看看基础结果能不能满足日常需求；确定缺什么数据，再去申请对应的Key。不要一上来就填一堆Key，某些Key的调用次数是有限额的，滥用反而影响正常业务。把Key配置完成后，记得重启服务让环境变量生效。

这里提醒一句：如果部署在公网服务器上，一定要给面板加访问控制（比如反向代理加Basic Auth或限制IP白名单），否则你的Web-Check实例会变成别人免费使用的“情报查询台”。这不仅浪费资源，还可能因为目标域名被其他人查询而产生安全隐患，等于把你自己变成了一个泄露信息的中转站。

3.3 使用中容易踩的小坑

我实际使用中踩过的坑主要有三个。第一，DNS解析结果可能因为本地网络环境而变化，如果你的机器在国内，解析海外站点会拿到一个被污染或延迟很高的结果，建议部署在海外的VPS上再用于海外站点的分析。第二，部分目标站点对一次请求中大量并发查询有风控机制，导致结果页面出现超时项，这种情况下可以把检测超时参数调大，或者分多轮查询。第三，在线Demo版虽然方便，但你把查询目标输进去的那一刻，等于把“你的侦察目标”关联关系记录到了公共服务器上，对保密要求高的项目，千万不要图方便用在线版。

4. 把检测结果变成线索：拼出一张资产情报图

4.1 场景一：从主域名摸出“影子资产”

我模拟一个典型场景：某组织找我们做外部攻击面评估，只给了官网域名example.com。传统思路是先去爆破子域名，但这样做既慢又容易漏。用Web-Check，我第一件事是看证书的SAN列表，通常能直接拿到一批关联域名；第二件事是算favicon哈希，拿去反查同类站点，如果发现某个域名挂着同样的图标但用的是非标准端口，那大概率是被遗忘的测试系统。

接下来看DNS记录。如果dev.example.com直接解析到内网IP段，或者test.example.com解析到一个公网IP但没套CDN，这些就是典型的影子资产。影子资产的问题在于它们往往没有纳入统一的安全策略，TLS没配好、管理后台直接暴露、安全头完全缺失——这是攻防演练中最容易突破的薄弱环节。

Web-Check提供的子域名枚举结果也需要结合上下文看：枚举出来的子域里，哪些是常用的邮箱入口、哪些是OA系统、哪些是API网关，再结合HTTP响应头的差异，很快就能区分出哪些资产值得深入测。这一步做完，整个组织的外部暴露面基本都有了轮廓。

4.2 场景二：给网站做一次“攻击者视角体检”

假设你是站点的运维人员，想从攻击者视角看看自己家是否存在明显的鼻子外露。用Web-Check跑一下自己域名，重点检查四件事：第一，robots.txt里有没有把不该公开的内部路径写上去；第二，HTTP安全头是否齐全，CSP能不能再收得更紧一点；第三，CRT证书的SAN列表里有没有包含与你无关的域名，如果有多余域名，说明证书申请时可能把不该捆绑的域名一起绑进来了；第四，意外开放的端口是不是没有做任何ACL限制。

我自己用这套流程自查过一个内部系统，发现FTP服务意外暴露在公网，而且使用的还是旧协议版本。这个问题如果靠人工巡检，可能很久都不会被发现。Web-Check的价值在于它把“检查暴露面”这个动作变成了一个可以随时随地重复执行的自动化巡检。

4.3 把结果导出成报告，与其他平台联动

Web-Check本身支持导出检测结果为JSON格式，这一点很实用。你可以把每次检测的JSON存档，写个定时任务定期跑一遍，然后对比两次结果的差异，比如新增的子域名、新出现的端口、证书突然变了——这些变化往往是新系统上线、配置变更或者有人做了异常操作的重要信号。把JSON结果导入到自建的情报中心或资产管理系统里，再配合其他工具做长期追踪，就能把一次性的侦察动作变成可持续的资产监控机制。

这种“把单点结果串成变化趋势”的思路，才是信息收集真正值钱的地方。单个时间点的快照只是数据，连续时间线上的变化才是情报。

5. 信息收集的边界：合规、隐私与自检建议

5.1 什么能查，什么不能碰

Web-Check做的是被动公开信息收集，这本身是合法且常见的，但它收集得到的信息也可能被进一步用来做未授权扫描、暴力破解等越界行为。我想强调一下从业者都应该遵守的底线：做信息收集前，先确认你是否有授权。如果是对自己的资产做演练，或者乙方在合同范围内对甲方做评估，才算有明确授权；否则，只停留在被动收集层面，不要用收集到的路径去“顺手试一下”，更不要把这些路径交给自动化扫描器去攻击。

不同地区对信息收集的监管要求不同，网络空间测绘、资产识别这类行为在一些场景下有严格的合规限制。最稳妥的姿势是把Web-Check用在自检、防护优化、以及已经获得授权的项目中。另外，做分析时不要主动去挖别人的敏感目录内容，看到robots.txt里暴露了路径，可以记录下来在授权范围内验证，但不要越界下载和利用。

5.2 反向自检：把Web-Check当作自己的安全镜子

我见过不少团队花了大量精力做业务功能，却从来没以攻击者视角看一眼自己的暴露面。实际上，你只需要一个域名输入框，花一分钟，就能知道自己的安全配置在“外人”眼里长什么样。这个动作建议至少每季度做一次，特别是在新系统上线、CDN切换、证书更新之后。

自检的时候可以对照这个清单来逐项确认：

• 证书SAN列表里有没有多余域名暴露，证书是否存在快到期的情况；
• robots.txt是否意外泄露了后台或备份路径，如果不希望被收录就加上认证；
• 安全响应头是否齐全，特别是CSP、HSTS、X-Frame-Options；
• 邮件相关DNS记录如SPF、DKIM配置是否生效，防止被用于伪造钓鱼邮件；
• 子域名枚举结果里有没有长期无人维护、解析到已注销CNAME的“僵尸域名”，这类最容易发生子域名接管；
• 常见端口是否有非预期开放，开放的端口是否有防火墙或ACL限制。

5.3 隐私考量：自托管与数据安全

最后聊聊隐私。如果你在别人的在线服务里输入了一个目标域名，理论上这个在线服务方就获得了“你在查这个域名”的关联信息。对于安全研究和企业防御场景，这种关联信息本身就是敏感数据。因此我强烈建议安全团队在内部自建一套Web-Check，让所有查询请求只走自己的服务，检测结果也不经过第三方中转。

我在实际项目中的习惯是：准备一台专用服务器部署Web-Check，只保留必要端口，面板加访问控制，检测结果以JSON格式存档加密保存；需要和别人协作时，再按需导出脱敏后的报告。这样做既能发挥这个开源神器的作用，又最大程度减小了侦察信息的扩散面。

再分享一个小经验：如果对某个网站的分析结果需要长期跟踪，不要每次都只保存截图，一定要把JSON结构完整存下来。后续写脚本做diff、做告警、做可视化的时候，结构化数据永远比截图好用。我自己就是这么把Web-Check纳入了常规的资产巡检流程，现在每次做评估，第一件事就是把目标域名扔进去，等它跑完，剩下需要人工深挖的范围已经缩小了很多。