Web安全三大高危漏洞：SQL注入、路径遍历与越权访问的防御实践

聊Web应用安全现状，我最大的感受是：高危漏洞的榜单年年换，但真正让安全团队头疼的还是那几类老面孔——Injection、File System Traversal、Broken Access Control。每次做代码审计和渗透测试，只要把这三个方向认真过一遍，都能至少捞出一两个中高危问题。这篇文章不打算重复翻译OWASP Top 10，而是把这三类攻击的底层逻辑、典型场景、修复要点放在一起拆解，结合我在项目里的实际操作，整理成一份能直接用于自查和防御的笔记。适合还没系统接触Web安全的开发者、刚转行的安全工程师，也适合正在做代码评审的团队负责人——看完你至少能知道，哪些代码写法必须禁止，哪些接口设计必须补校验。

1. 现状拆解：为什么“老漏洞”还是主流

1.1 攻击面膨胀带来的“漏洞密度”问题

先聊现状。现在一个普通的Web应用，已经很少是简单的单体页面了：前端一套，后端微服务拆成十几个，中间还有API网关、消息队列、对象存储、第三方回调。光是一个订单功能，可能就涉及商品服务、支付服务、用户服务、日志服务四个模块。接口数量从几十个涨到几百上千个，但安全和研发资源并没有等比例增加。

这带来的直接后果是“漏洞密度”被稀释了。安全团队没法每个接口都人工测，自动扫描器又只能覆盖语法层面的问题，于是边缘接口成了重灾区。我做过一次某公司的渗透测试，核心交易链路防护做得很完整，SQL注入基本堵死，但管理后台一个文件导出接口，path参数直接拼接路径，轻轻松松就读到配置文件。这类问题在单体时代反而不常见，因为功能少、评审容易覆盖；服务拆细之后，每个团队都觉得自己那部分“只是内部调用”，结果就是谁都没管。

所以理解Web应用安全现状，不能只看漏洞类型本身，还要看应用架构变化带来的暴露面增长。攻击者不需要找到所有漏洞，只需要找到一个没人管的边缘接口，一条链路就能打穿。安全团队的核心工作之一，就是把“没人管的接口”压缩到最少。

1.2 框架兜底与业务逻辑失控的错位

第二个现状是：开发框架解决了大量“技术型漏洞”，但业务逻辑漏洞反而越来越突出。

以前写SQL注入，是因为大家都在拼字符串；现在用ORM框架，直接拼接SQL的情况少了很多，参数化查询成了默认行为。模板引擎也默认转义，反射型XSS在主流框架里没那么容易触发。很多开发者因此产生了“框架安全了，应用就安全了”的错觉。

但框架不会替你判断业务权限。举个例子：一个订单详情接口，只要用户登录就能访问，参数里带着订单号orderId。后端代码只做了“是否登录”的判断，没有校验这个订单到底是不是当前用户的。结果就是任何登录用户改一下订单号，就能看别人的收货地址和手机号。这个问题属于典型的Broken Access Control，OWASP把它排在漏洞榜单第一不是没有道理——它没法靠框架默认配置解决，必须靠开发者在每个资源访问点显式实现授权逻辑。

框架解决了“注入语法”问题，却把“业务语义”的判断留给了开发者。业务语义又恰恰是最容易被忽略的部分，因为接口在开发环境里测出来是正常的，只有拿到真实用户身份去交叉访问时才会暴露风险。这个错位，是越权漏洞泛滥的根本原因。

1.3 从榜单看：三类攻击为什么始终靠前

如果你关注OWASP Top 10的版本变化，会发现一个有意思的现象：Injection从曾经的榜首滑落到第三，Broken Access Control反而升到第一。这不代表注入消失了，而是“被框架兜住了一部分”；但只要出现新的解释器、新的拼装方式，注入马上就会换个马甲回来。比如NoSQL注入、GraphQL注入、模板注入，都属于注入家族的新形态。

File System Traversal在公开统计里的数量不如前两者多，但危害一点不小。它的核心是CWE-22（路径遍历），常见于文件下载、上传、导出报表、多语言文件加载等场景。很多系统的文件参数都是明文路径，甚至直接把相对路径拼进文件系统调用里。这类漏洞一旦和上传功能组合，攻击者可以往可执行目录写入脚本，直接升级为远程命令执行。

三类攻击的共同特点：根源都是“没有充分信任边界”。应用在把用户输入交给解释器、文件系统、业务对象之前，没有做合法性验证。Injections是不验证语法边界，File System Traversal是不验证路径边界，Broken Access Control是不验证权限边界。后面我会逐个拆开讲。

2. Injection：从一个小字符到一次大事故

2.1 注入的本质：语法边界被打破

Injection类漏洞，我习惯把它理解成“语法边界被打破”。应用程序本来想把用户输入当作数据处理，但由于拼接姿势不对，用户输入被解释器当成了指令的一部分。

拿SQL注入举例，服务端代码写的是：

String name = request.getParameter("name"); String sql = "SELECT * FROM user WHERE name = '" + name + "'"; Statement st = conn.createStatement(); ResultSet rs = st.executeQuery(sql);

如果name的值为test，SQL就是正常的条件查询。可一旦输入变成' OR 1=1 --，拼接出来的语句就变成了：

SELECT * FROM user WHERE name = '' OR 1=1 --'

OR 1=1让where条件永远成立，--把后面的单引号注释掉。这样原本只查一个用户的接口，变成了返回全表数据。登录接口遇到这种输入，往往直接绕过认证。

我常用一个生活类比来解释：你在一张提货单上写“备注：帮我带两箱水”，仓库管理员只看备注就把水搬给你；但如果备注写的是“顺便把仓库门锁密码发到群里”，而系统没有任何机制区分“备注”和“指令”，那就会被执行。注入就是这个原理，区别在于Web应用里的“指令”是数据库查询、shell命令、表达式等等。

2.2 SQL注入的常见分类与实战还原

从攻防视角看，SQL注入可以分几种形态：

报错注入最简单也最直观。比如参数后面加一个单引号，页面直接抛出“MySQL语法错误”这类异常，说明输入被代入SQL执行了。联合查询注入需要先猜列数，用ORDER BY n逐步试探，直到不报错的临界值。盲注则更依赖响应时间的差异，比如if(condition,sleep(3),0)，页面延迟说明条件为真。

这里必须强调一点：这些操作只能在授权测试环境中进行。实际风险场景里，攻击者不需要理解每个原理，工具会自动完成这些试探；而防御者恰恰需要理解原理，才能在代码里发现“疑似注入点”。我给开发做培训时，会现场演示一次完整的报错注入和盲注判断，目的不是教攻击，而是让开发者记住一个直觉：参数后面出现单引号报错，绝不是什么“用户输入不规范”，而是危险信号。

2.3 参数化查询不是万能药

很多人一听到SQL注入，第一反应是“用参数化查询”。方向没错，但参数化查询不是万能药，这也是我在实际修复中反复遇到的问题。

参数化查询解决的是“SQL语句结构固定，只有参数值变化”的场景。一旦SQL的语法结构本身需要动态拼接，参数化就无能为力了。常见坑位包括：

• 动态表名或字段名：SELECT * FROM ${tableName}，表名不能写成占位符
• ORDER BY 排序字段：ORDER BY ${sortField}，排序字段不能参数化
• IN 子句的数量动态变化：需要动态生成 ? 占位符
• MyBatis 里误用${}：${name}直接拼接，#{name}才是预编译
• 存储过程内部的动态SQL：参数化外层并不能治好内部拼接

举一个我见过很多次的MyBatis错误写法：

<select id="getUser" resultType="User"> SELECT * FROM user WHERE name = '${name}' </select>

${name}会被MyBatis直接做字符串替换，相当于自己拼SQL。改成#{name}就安全多了：

<select id="getUser" resultType="User"> SELECT * FROM user WHERE name = #{name} </select>

修复之后的SQL语句结构在预编译阶段就确定了，输入值只作为参数传递，不管用户输入什么内容，都不会再改变SQL语义。对于ORDER BY这类确实无法参数化的部分，我的建议是建立白名单映射，前端传索引或枚举，后端映射到固定的列名，而不是把用户字符串直接拼进排序子句。

2.4 命令注入与NoSQL注入的变体

SQL注入只是Injection家族里最出名的一个，现实里还有命令注入、NoSQL注入、模板注入，原理都是一样的：把不可信数据拼进了另一个解释器。

命令注入的典型写法是Java里用Runtime.getRuntime().exec拼接系统命令，或者Python里用os.system拼接参数。攻击者传入; id、| whoami、$(whoami)这类特殊字符，就能让应用程序执行额外的系统命令。防御方式很明确：尽量不调用系统命令；必须调用时，使用参数数组而不是拼接一条字符串，并且对入参做严格白名单校验。

NoSQL注入则是把脏数据拼进了JSON查询表达式。比如一个MongoDB登录接口，如果后端直接解析前端传来的整个查询对象，攻击者可以构造{"username": {"$ne": null}, "password": {"$ne": null}}，让数据库认为用户名不为空、密码也不为空，直接绕过登录。这提醒我们：任何查询语法如果允许用户直接传递操作符，都要警惕表达式注入。

对于Injection家族，我的总体建议是：把“拼接”当成最危险的编码操作。任何用户输入，一旦被拼进SQL、shell命令、表达式、模板字符串，都要先问“这一步真的无法避免吗”。多问几次，你会发现很多拼接本来就不该存在。

2.5 注入攻击的检测与拦截思路

检测注入，不能只靠扫描器。我习惯从三个层面看：

• 代码审计层面：全局搜索+拼接SQL、${}、Runtime.exec、os.system、child_process.exec等危险调用点，逐个评估输入是否可控。
• 动态测试层面：在授权环境下用扫描工具辅助，但不能盲目信任工具。工具报“疑似注入”，要用手工请求验证；工具不报，不代表代码没问题，尤其要对业务逻辑型“半注入”保持敏感。
• 流量监控层面：在WAF和网关层面对明显的SQL关键字进行拦截，但切记WAF只是第一道闸，不是最终修复。

很多团队喜欢给所有接口套一个“全局转义”过滤器，比如把单引号替换成两个单引号。这种方案在特定SQL模式下有效，但很容易被编码绕过、宽字节绕过。真正的修复必须回到“永远用参数化/白名单校验”这条根上。

提示：给修复方案加“迷之过滤”——比如把../替换成空字符串、把单引号转义一遍——是最容易埋雷的做法。过滤规则永远落后于绕过技巧，核心思路应该是“不允许就不拼”。

3. File System Traversal：一条路径引发的连锁风险

3.1 路径拼接的“想当然”

File System Traversal，国内常叫“目录遍历”“路径穿越”。它不是新东西，但几乎每年都能见到。

问题出在开发者默认“用户传入的路径是可控的、安全的”。比如下载文件功能，常见写法是：

String path = request.getParameter("path"); File file = new File("/var/data/files/" + path);

如果path是avatar.jpg，程序去读一个公开目录下的文件，看上去没问题。但攻击者把path改成../../etc/passwd，拼接后的路径就变成了/var/data/files/../../etc/passwd，操作系统在解析时“..”代表上一级目录，最终指向了/etc/passwd。

“..”其实不是唯一手段，攻击者还会尝试用绝对路径、URL编码后的%2e%2e%2f、双重编码等绕过方式。这也是为什么简单替换“..”的修复方式不可靠——今天你替换了../，明天攻击者可能用....//或编码变体绕过。我在审计里判断路径遍历风险，只看一个点：你构建文件路径时，是否直接使用了未经验证的用户输入。如果是，那就是高危，别管它前面加了多少层目录。

3.2 任意文件读取导致的敏感信息泄露

路径遍历最常见的危害是任意文件读取。听起来只是“读文件”，但实际能挖出来的东西很致命：

• 应用源代码：读WEB-INF/classes下的class文件，反编译后理解业务逻辑，为下一步攻击铺路
• 配置文件：数据库账号、Redis密码、云厂商密钥、JWT签名密钥，往往都写在配置文件里
• 环境变量：读取/proc/self/environ可能直接拿到运行时环境变量
• 运维信息：读取/etc/passwd、系统版本文件，帮助提权

我见过一个真实案例：系统有个“导出报表”功能，参数是文件名，拼到服务器本地目录。攻击者先读配置拿到数据库连接串，然后连上去发现数据库账户是高权限，直接把整个用户表拖走了。整个过程没有任何注入，就是一条路径遍历。

所以评估这类漏洞，不要只盯着“能不能读passwd”，要看“读完这个文件之后，攻击者还能做什么”。高危路径遍历的核心价值不在于“读文件”这个动作本身，而在于它为后续攻击提供了跳板。

3.3 从路径穿越到远程命令执行

路径遍历不只是“读文件”，和上传功能组合时，危害会急剧放大。

如果应用允许上传文件，且文件名由用户控制，攻击者可以传一个../shell.php或../../webroot/shell.php。如果服务器解析到了Web根目录，这个文件就会被当作可执行脚本访问，攻击者就拿到了一个WebShell，等于远程命令执行。这种场景我称为“文件写入型路径穿越”，杀伤力比读取更大。

除了上传，还有一些隐蔽场景：日志文件名、缓存文件名、多语言文件路径、模板加载路径，都可能踩中。修复思路是：用户提交的文件名一律不信任。真实落地时，我一般建议：

• 服务端用UUID重新生成文件名，原始文件名只存数据库，不参与路径构建
• 文件保存到固定的落地目录，目录本身不允许被用户参数改变
• 如果是对象存储，直接用对象的唯一键，不要让业务层感知本地路径
• 不要用黑名单过滤文件名，而是用白名单限制扩展名，并且服务端校验MIME类型

在文件名这个环节，“随机化+白名单”是性价比最高的方案。因为你无法穷举攻击者会用哪些字符串，但你可以让业务根本不依赖用户提供的字符串来定位文件。

3.4 文件遍历的防御实践

具体到代码，一个比较稳的修复是“规范化+前缀校验”。以Java为例：

String path = request.getParameter("path"); Path base = Paths.get("/var/data/files").toRealPath(); Path target = Paths.get(base.toString(), path).normalize(); if (!target.startsWith(base)) { throw new SecurityException("文件路径非法"); } File result = target.toFile();

原理很简单：先把基础目录解析成真实路径，再把用户输入的path拼进去、做normalize（把里面的..、.规约掉），最后检查结果路径是否仍然以基础目录开头。如果拼完之后跑到了基础目录之外，直接拒绝。

Python版本也是同样思路，用os.path.realpath再判断前缀。不过要注意：realpath可能会解析软链接，如果基础目录自身包含软链接，要先把base也realpath一遍再比较。

除了代码层，部署层也要做纵深防御。比如Web容器不直接对公网暴露文件系统目录、配置文件不出现在Web根目录、敏感文件做权限管控。这样即使代码漏了一处，攻击者也难以直接读取高价值文件。

4. Broken Access Control：越权是业务漏洞之王

4.1 横向越权与纵向越权

Broken Access Control，直译是“访问控制失效”，国内更习惯叫“越权”。它和注入、路径遍历不太一样，问题几乎全部出在业务逻辑层。

先区分两类典型越权。横向越权是指普通用户访问了另一个普通用户的资源，比如A登录后能看B的订单；纵向越权是指低权限用户使用了高权限功能，比如普通员工能调管理员的删除接口。横向越权常见于业务数据接口，纵向越权常见于后台管理功能。

为什么越权这么普遍？因为开发者经常默认“接口只被前端调用，前端只显示当前用户的菜单”。现实是攻击者根本不走你家的前端页面，他们直接拿工具改个HTTP请求就完事。前端隐藏按钮、页面不展示菜单，这些都属于“客户端控制”，对服务端没有任何约束力。我见过不少系统，管理后台的入口按钮被隐藏了，但后端接口没有任何角色校验，攻击者直接请求一个管理API就能绕过前端限制。

4.2 IDOR：最常见也最隐蔽的越权

IDOR（Insecure Direct Object Reference）是越权里最经典的形态。核心问题在于：接口直接使用数据库自增ID作为资源标识，后端却只校验“登录状态”，不校验“资源归属”。

典型场景：

GET /api/order/1001 HTTP/1.1 Authorization: Bearer <用户A的Token>

攻击者把URL里的1001改成1002，如果后端没有校验这个订单的owner是不是当前用户，就会返回用户B的订单信息。信息越敏感，危害越大，通讯录、订单、发票、病历，任何一个资源只要存在IDOR，数据就会批量泄露。

修复方式分为两层。第一层是把可枚举的资源ID换成不可预测的标识，比如UUID；第二层也是更核心的一层，是在服务端显式校验资源归属：

@GetMapping("/api/order/{orderId}") public Order getOrder(@PathVariable String orderId) { Order order = orderService.getById(orderId); if (!order.getOwnerId().equals(当前登录用户ID)) { throw new AccessDeniedException("无权访问该订单"); } return order; }

UUID只能提高“猜”的成本，真正挡住越权的还是owner校验。很多团队只做了第一层，以为ID不可枚举就安全了，但用户如果本身就是资源相关方，比如同一个客户的多个联系人之间，UUID并不能防止越权。权限校验必须和人绑定，而不是和随机性绑定。

4.3 服务端信任带来的权限失控

除了IDOR，还有几类越权写法值得点名批评：

• 用请求参数直接传角色，比如role=admin，后端不加校验直接信任
• 只判断“是否登录”，不判断“角色是否匹配”，普通用户能调管理接口
• 管理后台嵌在同一个Web应用里，只靠前端路由隐藏，没有后端权限拦截
• 缓存/CDN覆盖导致权限数据串用，用户A的会话信息被用户B读取
• 多租户系统里，租户ID从请求头读取，后端没有校验租户隔离

这些问题的共同根因是“服务端过度信任客户端输入”。攻击者可以任意修改HTTP请求，可以删除Cookie、篡改Header、遍历ID，服务端必须把所有输入都当成不可信数据来处理。

我在做代码评审时，遇到“只要加了权限注解就完事”的说法都会格外警惕。权限校验不是加个注解那么简单，注解可能没生效、可能被绕过、可能只覆盖了部分接口。关键要看：每个接口入口，是否都经过统一鉴权中间件；资源级授权，是否在业务代码里显式完成。

4.4 越权防御的落地清单

针对越权问题，我整理了一份可以贴进团队Wiki的落地清单：

• 设计原则：接口默认拒绝，显式放行；别用黑名单，用白名单
• 统一鉴权：登录态、角色、权限点都集中在网关或中间件处理，业务代码不重复实现
• 对象级授权：每个资源访问函数都要校验当前用户与资源归属的关系
• 功能级授权：RBAC（基于角色的访问控制）管住“哪些角色能调哪些接口”
• 细粒度控制：租户隔离、字段级权限用ABAC（基于属性的访问控制）补齐
• 测试要求：每个角色都测一遍调用关系矩阵，重点测“改了ID能不能看到别人的数据”

越权防御没有一劳永逸的方案，因为它和具体业务强相关。但“每个资源访问点都必须有归属校验”这条铁律是通用的。把它写进代码规范，要比依赖一两个安全人员的自觉可靠得多。

5. 三类攻击的组合利用与纵深防御

5.1 攻击链复盘：从文件读取到权限提升

把前面的三类攻击放到一条攻击链里，你会看到Web安全为什么要做纵深防御。

假设一个典型系统：攻击者先通过文件下载接口的路径遍历，读取到应用配置文件，拿到了数据库连接字符串和JWT签名密钥。因为数据库账户配置了最小权限，不能直接提权，攻击者转而用JWT密钥伪造管理员Token。伪造之后调用管理后台的删除接口，结果发现接口只校验“是否是管理员Token”，没有校验操作人的真实身份，于是攻击者顺利删除了全量业务数据。

这条链路上，单个漏洞的危害都没到“直接沦陷”的程度，但组合在一起就失控了。如果文件遍历被修掉，攻击者拿不到配置；如果JWT密钥不放在Web可读取范围内，攻击者伪造不了Token；如果管理接口做了二次校验，即使Token泄露，也无法直接删数据。

所以安全不是“修完一个高危漏洞就结束”，而是要把每一层的风险都压到可接受范围。攻击者需要从入口一路打通到核心数据，防御者只需要在链路任何一个节点把门关上。

5.2 纵深防御的层次

我把纵深防御拆成几个阶段，每个阶段都有自己的责任：

这里特别想说一下编码阶段的重要性。安全测试和WAF更像是“事后补救”，如果在编码阶段就统一消灭“字符串拼接SQL”“用户文件名直接拼路径”“接口不做归属校验”这三类写法，绝大多数高危问题根本不会进入线上。

我见过一些团队把安全预算几乎全砸在WAF和扫描器上，但代码里依然遍地是拼接。设备堆得再多，也填不上开发的坑。先解决编码规范，再谈安全工具，这个顺序不能颠倒。

5.3 安全测试的核心抓手

安全测试不可能穷尽所有漏洞，所以要有抓手。我的习惯是先做资产梳理：把域名、服务、接口、数据流转画出来，标注哪些接口涉及敏感数据。然后按风险高低排序，高风险的先测。

自动化扫描适合做广撒网，比如SQLMap扫参数注入、nuclei跑模板规则、AWVS走一遍常见漏洞。但业务逻辑漏洞必须靠人工：登录后修改订单ID看会不会越权、上传带路径的文件名看会不会穿越、把普通用户Token换成管理员Token看会不会放行。

自动化工具最怕的是“误报和漏报一样多”。一款工具报了几十个“中危”，真正手工验证可能全是误报。我一般要求测试报告里附上完整的复现请求和响应，不能只丢一句“存在注入风险”。修复方拿到复现包，才能快速定位到具体代码。

6. 常见问题排查与实操心得

6.1 我踩过的坑

做安全这么多年，我自己也踩过不少坑，挑几个写出来供参考。

第一个坑是“只测主链路”。以前给某公司做测试，盯着订单支付、用户登录这些核心流程扫了半天，结果一个文件导出接口的参数没测。测试报告发出去后，正式环境被人用路径遍历把数据库配置读走了。从那以后我检查范围一定会覆盖所有“带文件名的接口”和“管理类接口”，哪怕这些接口在业务上看着不重要。

第二个坑是“修复方案过度简单”。同事刚开始遇到路径遍历，直接在代码里加了一句replace("../", "")，想着把点点点去掉就安全。结果攻击者用....//、URL编码一下就绕过了。后来改成规范化+前缀校验，才算真正封住。修复漏洞不能只针对“见过的payload”，要针对“根因”。

第三个坑是“权限校验复制粘贴时漏改”。同一个项目里，订单接口都校验了归属，但新增的发票接口复制代码时漏了那一行。这种问题代码审计很难一眼看出来，必须靠自动化规则和对照测试。现在我看到接口代码里出现“当前用户ID”，都会要求旁边必须有资源归属判断，缺一不可。

6.2 三类攻击的自查速查表

给团队做自查时，我通常发一张速查表，按漏洞类型列出代码特征、建议修复和绕坑点：

表格看起来简单，但每条背后都是真实漏洞换来的教训。代码评审时照着这张表过，至少能挡住一大半常见高危。我建议团队把这张表挂在CI平台首页，每次提交代码之前，开发自己先对照一遍。

6.3 给团队的一条实在建议

最后分享一个我自己的团队在推的做法：把“安全修复”从救火变成流程。

我们不满足于提交漏洞报告让开发改，而是在CI流水线里接了SAST工具，把“禁止字符串拼接SQL”“禁止直接使用用户输入构建文件路径”这类规则固化成规则集，提交代码时自动扫描，拦截高危模式。接口侧的越权问题暂时没法完全靠静态规则解决，所以强制要求每个新接口必须通过“角色矩阵”评审，并且在测试环境跑一遍越权用例。

这三类攻击在未来很长一段时间还会继续存在。它们不是新技术，而是根因没被消灭的旧问题。与其不停追着漏洞跑，不如在编码阶段就统一堵住根因。这是我从大量实战里得到的最实在的一条经验——安全能力的提升，靠的不是某一次专项治理，而是把这些基础动作变成日常习惯。