很多制造商朋友送产品来做CRA、EN 18031、IEC 62443认证，拿到检测报告后一脸懵：报告里写着"SQL注入漏洞""未授权访问""敏感信息泄露"——这些问题你们是怎么找出来的？难道真有黑客拿着键盘敲两下就进来了？
还真不是。我们的检测工程师手里确实有一套"工具箱"，但跟你想象的"黑客装备"不太一样。同样这些工具，黑客人手里叫"攻击武器"，在合规实验室里叫"检测手段"——工具是同一个工具，目的和约束完全不同。
今天GTG网络安全实验室就把我们日常检测用的Web渗透工具箱摊开给你看。不教你攻击，只让你知道：你的产品在送测之后，到底经历了什么。全文无代码压力，放心阅读。
01 先搞懂：合规检测里的渗透测试是个什么流程？
打个比方，你要验收一栋大楼的安防做得好不好，你会怎么做？
-
先踩点——看看大楼有几个门、几扇窗、摄像头朝哪、保安怎么巡逻
-
找漏洞——哪扇窗户锁坏了、哪个门禁密码没改、哪个后门没锁
-
试渗透——找到薄弱点，实际走一遍，看能不能真的进去
-
查纵深——进去之后，能不能走到不该去的楼层、打开不该开的门
-
出报告——哪里有问题、风险多高、怎么调整
合规检测里的Web渗透测试一模一样——"大楼"变成了你的产品APP、云端后台和Web管理界面，"门窗"变成了端口和API接口，"保险柜"变成了用户数据库。每个阶段都有对应的工具。下面按检测顺序说。
⚠️ 先声明：以下所有工具的使用，都建立在制造商书面授权的前提下。未经授权的渗透测试是违法行为，这个底线不能碰。我们做合规检测，每一次扫描、每一次利用，都在授权范围和明确的测试窗口内进行。
这一步在合规检测里叫信息收集。我们的目标是：在不触发任何告警的前提下，搞清楚你的产品对外暴露了哪些面——哪些端口开着、哪些API接口能访问、哪些页面不需要登录就能看到。
这一步对应CRA和EN 18031里的"暴露面管理"要求——你自己都不知道产品暴露了什么，监管机构来查的时候你怎么说清楚？
1. 目录扫描：找到产品隐藏的"小门小窗"
一个Web管理界面不可能所有页面都挂在导航栏上。后台调试页、测试接口、备份文件、老版本API……这些东西藏在角落里，普通用户看不到，但攻击者/检测工程师知道怎么找。
方法就是拿字典扫——准备一个超大的单词表（admin、login、backup、test、debug……），一个一个去试，看哪个路径能打开。
说白了就是：拿一本厚厚的"可能存在的路径名单"，一个一个去敲门，看谁答应。检测工程师用的字典比你想象的大得多——几万条起步，而且会根据你的产品类型（智能摄像头、智能门锁、路由器）换不同的字典。
2. 参数发现：找到藏起来的"传话筒"
很多漏洞藏在参数里。比如 ?id=1 这个id参数可能有SQL注入，但前提是你得知道有个参数叫id。
可问题是，API接口不会把所有参数都写在脸上。这时候就需要 Arjun——专门用来发现HTTP参数的工具。给它一个URL，它能帮你找出这个接口都接受哪些参数，有点像"盲猜参数名"。
在合规检测里，这一步经常能发现开发团队自己都忘了的调试参数——这些参数往往就是漏洞入口。
3. 敏感信息泄露检测：别让"底裤"露在外面
有些产品的.git目录忘了删，检测工程师直接就能把整个源码拖下来；有些产品的.env配置文件能直接访问，数据库密码明明白白写在里面；还有些产品的JS文件里，藏着API密钥、内网地址、注释掉的调试信息……
这是最容易"捡漏"的一步，也是产品被扣分最多的一步。
常用工具包括：
-
git-dumper——发现.git泄露后，直接把整个仓库dump下来
-
各种JS敏感信息扫描脚本——从前端JS里扒密钥、扒接口、扒注释
在EN 18031和CRA的安全要求里，敏感信息泄露是明确的扣分项——你的产品如果对外暴露了源码、密钥、内网地址，不管有没有被实际利用，都是不合规的。
02 第二阶段：漏洞扫描——自动化"找毛病"
踩完点了，接下来就是系统性地找漏洞。这一步相当于给你的产品做个全身体检。在合规检测里，这一步对应漏洞评估环节——我们需要知道你的产品在常见攻击面前扛不扛得住。
1. 综合扫描器：Web安全的"体检中心"
重点说说 Burp Suite。这玩意儿在渗透圈的地位，就像Photoshop在设计圈的地位——你可以不用，但你不能不会。
它最核心的功能是代理抓包：你手机或浏览器所有的请求，都会经过Burp，检测工程师可以停下来修改、重放、测试。比如你用APP提交一个设备控制指令，在Burp里把"设备ID"改成别的设备ID，看看后端接不接受——这就是最基本的越权测试思路。
在合规检测里，Burp是我们每天开得最久的工具。它的爬虫功能可以自动遍历你的Web界面，主动扫描功能可以检测常见漏洞，手动测试功能可以验证扫描器报出来的每一个疑似问题。
2. Nuclei：模板化扫描的"王者"
这几年Nuclei 异军突起，几乎成了人手必备的工具。
它的思路很简单：社区里有人写好漏洞检测模板（YAML格式），你拿着模板去扫目标就行了。今天Log4j爆了？有人写模板，你拿来就能扫。明天Spring Boot出漏洞了？有人写模板，你拿来就能扫。不用自己写检测脚本。
截止到2026年，Nuclei的官方模板库已经有上万条模板了，涵盖了从CMS漏洞到服务器漏洞到框架漏洞的方方面面。说它是"漏洞扫描界的Steam"，一点不为过。
在CRA合规检测里，Nuclei是我们用来快速筛查已知公开漏洞的主力工具——你的产品用了某个开源组件，如果这个组件最近爆了CVE，Nuclei可以几分钟之内确认你的产品是否受影响。
3. 专项扫描器：针对特定目标的"手术刀"
特别说一下Hydra——在合规检测里，弱密码检测是必测项。你的产品有没有通用默认密码？能不能被暴力破解？这两项直接对应PSTI和EN 18031的强制要求。Hydra就是用来验证"你的密码策略到底扛不扛得住字典攻击"的。
03 第三阶段：漏洞验证——找到洞了，是不是真能打穿？
扫描器报出漏洞只是第一步。在合规检测里，我们必须人工验证每一个疑似漏洞——扫描器可能误报，只有实际验证过的问题才会写进报告。这一步就是"漏洞验证"，相当于扫描器做了初筛，工程师来做终审。
1. SQL注入：sqlmap 一出手，就知有没有
SQL注入可以说是Web漏洞里的"老牌王者"。原理不复杂：用户输入的数据没过滤好，拼到SQL语句里了，导致攻击者能操控数据库。
手工验证费时费力，尤其是盲注（看不到报错，只能靠真假判断），能把人眼睛都瞅瞎。于是就有了 sqlmap——SQL注入自动化验证的天花板。
给它一个带参数的URL，它能自动：
-
检测有没有注入
-
是什么类型的注入（数字型/字符型/盲注/时间盲注）
-
是什么数据库（MySQL/Oracle/MSSQL……）
-
证明可以读到数据（但不会真的脱库——合规检测只证明漏洞存在，不造成实际破坏）
在合规报告里，sqlmap的输出会被作为漏洞证据附在报告中。这也是为什么检测报告里经常能看到"通过sqlmap验证了注入点，确认可读取数据库版本信息"这样的描述。
2. XSS跨站脚本：让浏览器"听话"
XSS是什么？简单说就是：攻击者能在别人的页面里注入自己的JavaScript代码。用户一打开页面，代码就执行了，cookie能偷、页面能改、甚至能跳转钓鱼网站。
在合规检测里，XSS是必测项。特别是你的产品如果有Web管理界面或APP内嵌网页，XSS漏洞直接对应EN 18031里的"输入验证和输出编码"要求。
3. SSRF：让服务器"帮我跑腿"
SSRF（服务端请求伪造）是这些年越来越受重视的漏洞。简单说就是：服务器上有个功能是"帮你访问某个URL"，但没做限制，你让它访问啥它就访问啥。
危害有多大？
-
让它访问 127.0.0.1 → 探测内网服务
-
让它访问云厂商的元数据地址 → 拿到云服务器的临时凭证
-
让它访问内网的Redis、MySQL → 进一步横向移动
SSRFmap 就是专门用来验证SSRF漏洞的工具。在检测带云端功能的产品（如智能摄像头的云端预览、智能音箱的云控制）时，SSRF是高频检测项。
4. 文件上传漏洞：把"后门"传上去
很多产品有上传功能——传头像、传配置、传固件升级包。如果上传功能没做好校验，攻击者直接传一个恶意文件上去，可能就能控制整个设备或服务器。
常见的测试绕过手段（我们在检测里会逐项验证）：
-
改文件后缀（.php → .php5、.phtml）
-
双扩展名（shell.php.jpg）
-
改Content-Type（说自己是图片，其实是脚本）
-
图片马（在图片文件末尾追加代码）
⚠️ 友情提醒：这些技术知道就行了，别乱用。合法授权的渗透测试才是正道。
5. 其他常见漏洞验证工具
05 一张图总结：合规检测中的Web渗透工具全景
把上面说的工具串起来，就是我们在实验室里做一次Web安全渗透测试的完整流程：
→ 信息搜集
（ffuf/Gobuster/Arjun/git-dumper）
→ 漏洞扫描
（Burp Suite/Nuclei/Nikto/Acunetix）
→ 漏洞验证
（sqlmap/Dalfox/XSStrike/SSRFmap/commix）
→ 风险评级
→ 出具检测报告
每一步的输出，最终都会变成你拿到的那份检测报告里的一条条"发现项"——有漏洞描述、有复现步骤、有风险等级（CVSS评分）、有整改建议。
06 最后说几句实在的
看到这你可能会问：既然你们用这些工具一扫就能发现问题，那我自己用这些工具扫一下不就行了，为什么还要花钱送测？
这个问题问得好。
工具是死的，人是活的。同样一把手术刀，在实习生手里可能连缝合都做不利索，在外科主任手里就能做精密手术。渗透检测也是一个道理——
-
知道什么时候用什么工具，比知道工具有多少功能重要
-
能读懂工具的输出结果、判断是真漏洞还是误报，比会敲命令重要
-
能把各种零散的漏洞串起来形成完整攻击链，才是检测的核心价值
更重要的是，合规检测不是"扫完就完了"。CRA、EN 18031、IEC 62443这些标准里，不是每一条都靠工具能测出来的——很多要求涉及安全开发生命周期（SDL）、固件签名、安全启动、密钥管理、日志审计、漏洞披露流程，这些需要人工审计开发文档、检查代码仓库、验证设计文档。
工具只能测"有没有洞"，标准合规测的是"你的整个开发流程和产品设计是不是安全的"。
而且，监管机构和认证机构认可的检测报告，必须由有资质的实验室在书面授权下出具。你自己扫出来的结果，连你自己都未必敢信，更别说拿去当合规证据了。
如果你的联网产品需要做CRA、EN 18031、IEC 62443或PSTI合规检测，欢迎联系GTG网络安全实验室。
我们的工程师每天就是用上面这些工具，帮制造商在产品出厂前把问题找出来、改到位，让你的产品顺利过认证、不被下架、不被罚款。
🏆 为什么GTG能为您降本避险？
-
拒绝模板：不只给报告，我们提供定制化漏洞修复方案，确保产品真安全。
-
极致省心：代写核心文档，免除繁琐填表，让合规效率提升。
-
全域覆盖：从消费电子到汽车、工控、医疗，一站式解决全球隐私与数据安全难题。
您的全球合规通行证，从这里开始。
[👉 立即咨询 CRA / AI法案 / 隐私合规]