1. 为什么圈内人总爱说“五大漏洞”
1.1 五大漏洞的历史与定位
做安全这些年，最常被新人问的一句话就是：“我到底该从哪里开始学？”市面上分类五花八门，一会儿 OWASP Top 10，一会儿 CWE Top 25，一会儿又是各家厂商的年度报告。对零基础的同学来说，这些列表看着就头疼。
但如果你去问任何一个在一线做过渗透测试的老手，大概率会得到一个非常朴素的答案：先把五大漏洞吃透。所谓“五大”，指的就是 SQL 注入、XSS 跨站脚本、CSRF 跨站请求伪造、文件上传漏洞，以及我今天要重点讲的口令与认证绕过类漏洞，也就是很多人听过的“pass 漏洞”。
这五类不是哪个人拍脑袋定出来的，而是从大量真实攻防事件里沉淀下来的经验值。它们的共同特点是：出现频率极高、利用门槛相对低、一旦触发影响范围大。换句话说，只要是连过互联网的业务系统，十有八九逃不出这五类的覆盖范围。先把这五类搞明白，后面的进阶之路会顺畅很多。
1.2 一张表看懂五类风险
为了方便你建立整体印象，我把这五类漏洞的核心信息整理成了对照表。建议先存下来，后面每个部分都会反复回到这张表。
| 漏洞类型 | 攻击面 | 典型危害 | 高频场景 | 修复难度 |
|---|---|---|---|---|
| SQL 注入 | 数据库查询参数 | 数据泄露、拖库、口令爆破 | 搜索框、登录框、排序参数 | 低，参数化即可 |
| XSS 跨站脚本 | 浏览器端输入输出 | 会话劫持、钓鱼、挂马 | 评论框、昵称、富文本 | 中，需全链路转义 |
| CSRF 请求伪造 | 用户会话 | 越权操作、财产损失 | 改密、转账、发帖 | 低，加 Token 和校验 |
| 文件上传 | 服务器存储与解析 | 远程命令执行、网站沦陷 | 头像上传、附件上传 | 中，需多层防护 |
| 口令/认证绕过（pass 漏洞） | 身份认证边界 | 账户接管、后台沦陷 | 登录页、找回密码、越权接口 | 中，需体系化治理 |
注意表格最后一行的“pass 漏洞”，它比前四类更抽象，也因为这个词在不同场合有不同解释，导致很多人一直云里雾里。下面我单独把它拆开讲清楚。
2. 揭开 pass 漏洞的“真实身份”
2.1 pass 漏洞到底是什么
先直接回答那个最常被搜索的问题：pass 漏洞是什么？
在中文网络安全圈里，“pass”最常见的意思是“口令”，也就是英文 password 的简写。所以 pass 漏洞，本质上是指口令与认证相关的安全漏洞。它不是一个单一漏洞，而是一类问题的集合，中心思想是：攻击者通过口令的脆弱性或认证逻辑的缺陷，骗过了系统的身份校验，拿到了自己本不该拥有的权限。
但这里有个容易混淆的点。在一些日志、报告或漏洞库描述里，你也会看到“pass”被用作动词，表示“绕过”的意思。比如“该接口可通过修改参数 pass 登录校验”，这时说的就是认证绕过漏洞。这两种理解其实不矛盾，反而相辅相成——口令脆弱往往是被绕过的前提，而认证绕过又是口令问题的终极表现形式。所以本文里我把 pass 漏洞定义为：口令脆弱性与认证逻辑缺陷共同引发的一类身份认证安全问题。
理解了这层含义，你再看网上那些“默认口令导致后台沦陷”“登录接口存在逻辑绕过”“验证码形同虚设”的案例，就能全部归位到 pass 漏洞这个大类下面了。
2.2 四类最常见的高危口令场景
实际渗透和应急响应过程中，我见过太多 pass 漏洞的变种。严格来说，它们都符合“口令与认证问题”这个总纲。我把最高频的四类列出来，每一类都配了真实世界里反复上演的场景。
第一类是弱口令。这是最原始也最常见的问题，用户把密码设成 admin、123456、password 这类简单组合，攻击者用字典跑一遍就能批量进系统。很多新人对弱口令不以为然，觉得“哪有人真会这样设密码”，直到自己去看一次社工库里的密码统计，才知道 123456 的保有量有多离谱。
第二类是默认口令。很多网络设备、中间件、数据库在出厂或安装时自带一组默认账号密码，比如某些路由器是 admin/admin，某些开源后台是 admin/123456，如果运维部署后没有强制修改，攻击者按说明书就能登进去。这不是段子，勒索病毒最爱打的远程桌面和防火墙，很多就是靠默认口令进的。
第三类是硬编码口令。开发者在源码或配置文件里写死了一个数据库口令、API 密钥或者后台账号，比如在某个配置文件里留下“pass = xxxx”。一旦源码泄露或被反编译，等于把钥匙直接交给了攻击者。这类问题在第三方组件、物联网固件里尤其常见。
第四类是口令复用与撞库。攻击者从 A 网站拿到一批账号口令，拿到 B 网站去试，因为很多用户在不同平台用同一套密码，结果一撞一个准。这也是为什么现在主流平台都强制要求做“异常用地登录提醒”和“多因素认证”。
2.3 从“口令脆弱”到“认证绕过”
如果你只是记住了“弱口令”三个字，那远远不够。真正让 pass 漏洞变复杂的是它的“认证绕过”形态。
我举个典型的例子。一个登录接口，前端提交用户名和密码，后端查询数据库验证。有些开发者为了省事，会把“验证是否成功”的结果直接返回给前端，前端根据返回值决定是否跳转进入后台。攻击者抓包后把返回结果里的 failure 改成 success，就能直接以管理员身份进系统。这就是典型的认证逻辑绕过，它根本不需要破解口令，而是利用“服务端信任前端”的缺陷。
再比如找回密码功能，如果验证码校验放在前端，或者验证码不失效、不绑定会话，攻击者就能反复枚举手机号或邮箱，甚至直接跳过校验步骤改掉目标用户的密码。这类业务逻辑漏洞也归入 pass 漏洞大类。
所以完整的修复思路必须是体系化的，不能只改一个点：
- 强制口令复杂度与更换周期，禁止常见弱口令；
- 默认口令首次登录强制修改，设备上线检查；
- 删除代码中的硬编码口令，敏感信息统一放入密钥管理系统；
- 服务端必须做完整的身份认证与权限校验，不看前端传回的“成功标记”；
- 登录、找回密码等关键接口增加多因素认证、验证码、失败锁定与频率限制。
提示：评估一个系统是否存在 pass 漏洞，不要只测密码强度，还要把所有涉及“身份判断”的逻辑点列出来，逐个检查服务端是否真的校验了。
3. 四大“老牌”漏洞的识别与加固
3.1 SQL 注入：从参数拼接说起
SQL 注入排在第一，自有它的道理。它利用了“程序把用户输入直接拼接进 SQL 语句”的缺陷，让数据库执行了攻击者构造的额外命令。
打个简单的比方。你家门锁正常逻辑是“验证钥匙对不对”，但 SQL 注入等于锁在判断钥匙时，还顺手把钥匙上的文字当作指令执行了。比如一个搜索框，代码执行了这样的查询：
SELECT * FROM articles WHERE title = '用户输入'如果用户在输入框里填的是：
' OR '1'='1整条语句就变成了：
SELECT * FROM articles WHERE title = '' OR '1'='1由于'1'='1'永远成立，查询结果把整张表都带出来了。更严重的版本可以联合查询其他表、调用系统函数、写入恶意文件，最终演变成拖库甚至拿下服务器权限。
识别 SQL 注入的实操方法，我建议遵循“由简到繁”的顺序：
- 先试基础探测字符，比如单引号、双引号、括号，观察页面是否报错、返回结果是否异常；
- 再用布尔条件判断，传入
1 AND 1=1与1 AND 1=2，对比两次响应差异； - 进一步用时间盲注或报错注入确认存在性与注入点；
- 最后才是用工具或手注提取数据。
修复层面，核心原则只有一条：参数化查询。把用户输入当作数据，而不是 SQL 代码的一部分。无论是使用预编译语句、存储过程还是 ORM 框架，都要确保参数是参数、语句是语句。另外还要做好最小权限原则，给数据库连接账号只授予业务必需的最小权限，这样即使注入发生，攻击者也拿不到 high-level 权限。
3.2 XSS：让恶意脚本在别人浏览器里执行
XSS 全称是跨站脚本，核心问题是程序没有对用户输入做充分过滤，导致恶意脚本被存储、反射或通过 DOM 方式在受害者的浏览器里执行。
我对新人的直观解释是：XSS 就像你在留言板上贴了一张写着“谁看了这张纸条，就把自己钱包里的钱放桌上”的纸条。其他用户路过时，浏览器这个“人”真的去执行了。危害程度取决于脚本能做什么——窃取 Cookie、模拟用户操作、篡改页面、发起钓鱼请求，几乎是无上限的。
XSS 通常被分成三种类型：
- 反射型：恶意脚本经过参数提交后，直接反射在返回页面里，诱导用户点击恶意链接触发；
- 存储型：脚本被存在服务端数据库里，任何访问该页面的用户都会触发，危害最大；
- DOM 型：脚本通过浏览器的 DOM 操作改变页面结构，不需要经过服务端，隐蔽性更强。
检测 XSS 不能光靠工具扫描，更要靠人工分析输入输出点。常见的高危位置包括搜索框、评论框、昵称、URL 参数、富文本编辑器内容等。你需要在每个输出点测试是否有转义缺失，注意不只是<script>标签，还有img onerror、svg、javascript:伪协议等一堆变体。
修复 XSS 的思路是“输出编码 + 上下文感知”。具体动作包括：
- 对所有输出到 HTML 的内容按上下文做编码，比如 HTML 实体编码、JavaScript 编码、URL 编码；
- 设置
Content-Security-Policy头，限制脚本来源； - 给会话 Cookie 加
HttpOnly与Secure标记，降低 Cookie 被窃取的风险； - 富文本场景采用白名单标签过滤，而不是一味黑名单，因为黑名单永远堵不完全。
3.3 CSRF：借刀杀人的请求伪造
CSRF 跨站请求伪造的攻击思路很有趣，它不直接攻击用户，也不直接攻击服务器，而是让受害者的浏览器代替攻击者，向目标网站发送已经被“合法身份认证”的请求。
原理其实不复杂。假设你在登录状态下访问了一个购物网站，浏览器里躺着有效的会话 Cookie。这时攻击者诱导你点开一个恶意页面，页面里藏着一个指向该购物网站的转账或改密请求。由于浏览器自动携带 Cookie，目标服务器以为这个请求是你本人发起的，于是执行了操作。整个过程你毫不知情，纯粹是“被借刀杀人”了。
CSRF 之所以屡见不鲜，是因为很多开发者默认“请求来自浏览器 = 用户主动操作”，忽略了浏览器本身是个多线程的、可以被第三方页面诱导的环境。
检测 CSRF 的思路也很直接：找页面里所有“非查询”类请求（POST、PUT、DELETE 等），看它们是否校验了请求来源或携带了不可预测的 Token。如果一个敏感操作只需携带 Cookie 就能完成，那基本就中招了。
防护方案有三个层次，按优先顺序排列：
- 使用同步 Token 模式，即服务端生成随机 Token，嵌入表单或请求头，提交时校验；
- 设置
SameSite属性为Lax或Strict，限制第三方页面发送跨站 Cookie； - 对转账、改密等高危操作增加二次验证，比如输入原密码、短信验证码。
注意：CSRF 防护不能只依赖前端加个请求头，必须由服务端验证 Token 或 Source。我在实际项目里见过不少“前端加了 Token 但后端根本没校验”的情况，等于白装。
3.4 文件上传：从文件头到免杀
文件上传漏洞是五类中“上线即高危”的代表。它的核心问题是：服务器接收了用户上传的文件后，没有严格校验文件内容与执行权限，导致攻击者上传脚本文件并在服务器上执行，直接拿到网站控制权。
常用的利用思路包括上传一句话木马、图马（把脚本代码藏在图片里）、以及各种绕过扩展名过滤的技巧。我见过绕过方式花样百出，比如修改文件后缀为.php.jpg、利用大小写绕过.PhP、上传.htaccess改变解析规则、在文件头部伪造图片的 magic bytes，等等。这些都是因为校验只做了“表面功夫”，没有从实际执行链条上去堵。
修复文件上传，我总结了一套组合策略：
- 使用扩展名白名单，而不是黑名单，明确允许哪些类型，其他统统拒绝；
- 同时校验 MIME 类型与文件头，防止伪造；
- 重命名文件为随机字符串，不给攻击者预测文件路径的机会；
- 文件存储目录单独隔离，并关闭脚本执行权限，比如只允许静态文件访问；
- 对上传的图片进行二次渲染或内容安全扫描，清理内嵌的恶意代码。
这五层全做了，才算是一个真正让人放心的上传模块。
4. 零基础到精通的进阶路线
4.1 第一周：先学会“看懂漏洞”
很多零基础的同学一上来就拿着工具到处扫，扫出来一堆“高危漏洞”却不知道怎么验证，也不知道怎么写报告，这其实走偏了。学习安全的第一步从来不是动手，而是建立“漏洞模型”。
我的建议是，第一周只做三件事。第一件，把五类漏洞的原理分别看懂，不要求会利用，只要求能解释清楚“为什么会产生”“攻击者利用的是什么”“危害会体现在哪里”。第二件，搭一个本地实验环境，把 SQL 注入、XSS、CSRF、文件上传的经典靶场题目各做一遍。这类靶场网上很多，记住要选那些专门用于练习的合法环境。第三件，看完每道题后写一篇复盘笔记，回答三个问题：漏洞在哪一行代码产生、触发条件是什么、如何用一句话修复。
这个阶段最重要是“手感”。你要亲眼看到参数改变了、页面异常了、数据库数据被查出来了，才能真正理解漏洞不是纸上概念，而是实实在在的业务风险。
4.2 从扫描到手工：工具与手感的配合
到了进阶阶段，工具是必不可少的，但工具永远不能替代思考。我的习惯是用扫描器做“广度”，用人工做“深度”。
以 Web 漏洞扫描为例，先用扫描器对目标系统做一轮全量巡检，拿到初步的风险列表。这里要提醒一句：扫描器跑出来的结果至少要过滤三个维度的噪音——误报、重复项、低危项。然后对每个高危结果，必须通过浏览器手工验证一次，确认漏洞真实存在，并判断可利用程度和影响范围。
我最推荐的工具组合是：抓包代理加浏览器，配合数据库客户端和系统终端。抓包代理用来观察请求与响应，验证 SQL 注入、越权、认证绕过等逻辑问题；浏览器用来复现 XSS 和 CSRF 的实际触发过程；数据库客户端和终端则用于在授权测试中确认数据泄露范围和权限边界。
这里必须强调一个边界问题：所有渗透测试都必须在授权范围内进行。没有书面授权的“练手”，无论出于什么目的，都会构成违法行为。这点我在带新人时永远放在第一条。
4.3 从“发现问题”到“闭环修复”
能发现漏洞只是半个安全工程师，另一个关键是推动修复落地。
每发现一个问题，我建议按这个模板记录：漏洞名称、URL 和参数、复现步骤、影响说明、修复建议、修复状态。一份合格的漏洞报告，业务方拿过去能看懂危害，开发方拿过去能照着改代码。写报告最忌讳只说“这里存在 SQL 注入”，却不说怎么复现、怎么修。
修复后的回归同样重要。很多漏洞改了一版又改出一版新的，比如为了修 SQL 注入，用了字符串替换单引号，结果被宽字节注入绕过。所以复测不是跑一遍扫描器说“没了”就完了，而是要针对原有的利用路径重新走一遍，确认利用链被真正掐断。
更进阶一步，是要把修复经验沉淀成团队的编码规范和安全基线。比如开发规范里明确所有 SQL 必须参数化，所有上传必须走统一接口，所有登录接口必须服务端校验。这样一来，安全就不再是某个测试人员的事，而是融入了开发流程本身。
5. 常见问题与排查技巧实录
5.1 问题排查速查表
实操中大家问得最多的几个问题，我整理成了速查表，方便你直接对照：
| 现象 | 可能的根因 | 排查思路 | 快速处置 |
|---|---|---|---|
| 扫描器报了 SQL 注入，但手工验证没反应 | 扫描器误报或触发点需要特定参数 | 重新构造简单布尔条件验证 | 找到真实注入点再确认，不要直接关闭工单 |
| 登录页存在弱口令，但改了密码后仍然被登录 | 可能存在硬编码口令或认证绕过 | 抓包分析登录请求，检查返回逻辑 | 排查代码中的硬编码口令，修复服务端校验 |
| 文件上传功能已经做了扩展名黑名单，仍被上传脚本 | 黑名单被大小写或解析规则绕过 | 查看 Web 服务器解析配置，试上传变体后缀 | 改为白名单+禁用执行权限 |
| 添加了 CSRF Token，但接口仍然被跨站调用 | 后端没有校验 Token 或 Token 可预测 | 查看后端代码校验逻辑 | 服务端强制校验 Token 并绑定会话 |
| 用户明明设置了强密码，仍提示账号被盗 | 可能是口令复用撞库或键盘记录器 | 检查登录日志、异地登录记录 | 启用多因素认证，强制临时改密 |
5.2 我踩过的几个坑
第一个坑：过于相信扫描器。早期我拿到扫描结果后直接写进报告，结果被开发反手一问“怎么复现”，当场卡壳。后来学乖了，所有高危发现一律手工验证，验证不过的一律降级处理。
第二个坑：忽略业务逻辑漏洞。SQL 注入、XSS 这类技术漏洞大家盯得紧，但“忘记密码功能可以被遍历手机号”“订单金额可以前端修改”这类逻辑漏洞却经常漏掉。它们恰恰是 pass 漏洞的高发区，也是真实攻击里被利用最多的点之一。
第三个坑：修复建议写得太虚。刚开始写报告，总喜欢写“建议加强输入过滤”这种话。后来发现，开发真正需要的是能直接落地的方案。比如“在 DAO 层统一使用参数化查询，禁止字符串拼接 SQL”，比“加强过滤”有用一万倍。
5.3 上线前的漏洞自检清单
把下面这份清单存在笔记里，以后给任何 Web 系统做上线前检查都能直接用：
- 登录接口是否有服务端认证校验，是否依赖前端返回的成功标记；
- 是否存在默认口令、弱口令或硬编码口令；
- 所有数据库查询是否都使用参数化，无字符串拼接；
- 所有用户输出点是否按上下文编码，敏感 Cookie 是否设置了 HttpOnly；
- 所有敏感操作请求是否校验了 Token 或请求来源；
- 上传模块是否使用扩展名白名单，存储目录是否禁用了脚本执行；
- 是否存在越权访问接口，即仅凭 ID 遍历就能查看他人数据；
- 关键接口是否有频率限制、失败锁定和操作日志。
这份清单是我在多次实战后沉淀下来的，虽然不保证覆盖所有边界情况，但能挡住至少九成的高频攻击路径。
6. 最后分享一个学习思路
最后说点方向感的东西。五大漏洞看起来是五个孤立知识点，其实它们之间有明显的逻辑主线：SQL 注入和文件上传攻击的是“数据处理链路”，XSS 和 CSRF 攻击的是“用户信任链路”，pass 漏洞攻击的是“身份认证链路”。先站在攻击者视角把每条链路走通，再回到防御者视角逐点加固，你在安全这条路上基本就入门了。
对我个人来说，每次复测一个系统，最大的成就感不是“发现了多少漏洞”，而是“那些能真正保护用户数据的防线终于立起来了”。希望这篇关于五大漏洞与 pass 漏洞的拆解，能帮你少走一些我当年走过的弯路。
