实战：如何在业务系统中挖到越权漏洞

🔒免责声明：本文所有技术、测试思路，仅用于授权靶场练习、企业授权渗透测试。严禁对没有书面授权的线上业务进行探测攻击，未授权测试属于违法行为。文中全部案例均为模拟业务场景，仅作学习研究。

摘要
越权漏洞（访问控制失效 Broken Access Control，OWASP Top1 2025 排名第一），是 SRC 漏洞平台上报数量最高的高危漏洞类别之一。不同于 SQL 注入、XSS，越权属于业务逻辑缺陷，扫描器很难自动化发现，绝大多数越权漏洞依靠手工测试挖掘。很多新手学习 Web 渗透，学完各类工具，面对真实业务系统却挖不到越权，核心原因是没有掌握完整的业务测试方法论。

本文从实战角度完整讲解越权漏洞挖掘全流程：越权基础概念、业务系统中高发场景、完整标准化测试流程、水平越权、垂直越权、未授权访问实战案例；加密参数、JWT‑Token、UUID 非自增 ID 等现实环境的绕过思路；如何区分真实漏洞与误报；SRC 报告编写模板；代码层面根因分析；完整生产环境修复方案；实战踩坑总结。适合渗透实习生、SRC 白帽子、安全测试工程师阅读，读完之后可以直接把这套流程应用到业务系统安全测试。

前言
在真实业务渗透测试工作中，RCE 远程代码执行、SQL 注入高危漏洞在成熟业务系统越来越少见。但是越权访问漏洞却依旧大量存在。很多开发会做好登录认证，但是混淆了登录校验和权限校验两个完全不同的概念：登录只判断 “你是谁，你是否登录”；权限校验判断 “你是否允许操作这条资源”。

大量业务接口只做登录校验，只要携带合法 Cookie、JWT Token，就允许查询、修改资源，不去校验这条资源到底属不属于当前登录用户，直接造成越权漏洞。

扫描器为什么很难挖到越权？越权漏洞需要两个不同身份账号交互对比结果，需要理解业务资源归属关系，自动化工具无法理解业务逻辑，只能依靠人工操作。很多新手拿到业务站点，只会跑扫描器，扫描器无告警，就认为系统安全，直接错过大量高危越权。

越权漏洞分为三大类：水平越权、垂直越权、未授权访问。在电商系统、OA 工单、SaaS 多租户系统、后台管理、APP 接口都属于重灾区。本文不讲空泛理论，全部以业务实战为导向，输出一套可以直接落地的测试流程。

1. 越权漏洞基础概念：水平越权、垂直越权、未授权访问

1.1 水平越权（IDOR 不安全直接对象引用）

同一权限角色，A 用户访问 / 修改 B 用户的私有资源。
举例：A 账号登录，可以读取 B 账号的订单、手机号、收货地址；A 账号修改 B 账号个人资料；A 下载 B 的工单附件。
核心：权限级别相同，访问别人的私有数据。

产生根源：接口接收前端传入资源 ID（order_id、addr_id、user_id），根据 ID 直接查询数据库，没有校验这条数据归属的用户 ID 是否等于当前登录用户 ID。

危险伪代码 Java：

//高危写法，只根据id查询，没有归属校验 Order order = orderMapper.selectById(orderId); return order;

攻击者修改 order_id 参数为其他用户订单编号，直接拿到别人订单全部信息。

1.2 垂直越权（权限提升）

低权限账号，调用高权限角色接口，执行高权限操作。
举例：普通会员用户，直接调用管理员接口删除用户、修改全站配置；普通操作员访问管理员后台页面。
核心：身份角色权限等级不同，低权限执行高权限功能FreeBuf。

很多系统仅仅做页面隐藏，前端菜单不给普通用户展示管理员功能，但是后端接口没有权限拦截。前端隐藏不等于安全，攻击者抓包直接调用管理员 API 就触发垂直越权。

1.3 未授权访问

不需要登录 Cookie/Tocken，直接访问需要身份认证的接口、后台页面。
分为两种：

1. 完全没有登录鉴权，直接访问后台管理页面；
2. 登录鉴权逻辑失效，删除 Cookie、去掉 Authorization 请求头，依旧可以正常访问接口。

重要区分：

• 登录校验：判断用户是否登录；
• 资源归属校验：登录之后，判断该用户能不能操作这条数据；
• 角色权限校验：登录之后，判断该角色能不能执行这个功能；

绝大多数越权，都是缺少后两者其中一项校验。

2. 业务系统哪些功能点最容易产生越权（重点测试清单）

拿到业务系统，不需要漫无目的乱改参数，优先测试下面高频模块，线上 80% 越权出自这些业务。

2.1 水平越权高发业务模块

1. 订单模块：查看订单详情、订单列表、订单导出、取消订单；参数：order_id、orderNo
2. 个人地址模块：查看地址、修改地址、删除地址；参数：addr_id
3. 用户资料：查看个人信息、修改昵称、修改手机号；参数：uid、user_id
4. 工单系统：工单详情、工单附件下载；参数：work_id、file_id
5. SaaS 多租户系统：查询其他租户数据；参数：tenant_id
6. 文档、文件下载：下载私有文件；参数：fileId、doc_id
7. 消息通知：查看他人站内消息
8. 收藏、优惠券：读取别人优惠券数据

参数关键词看到这些，优先测试：id、uid、user_id、order_id、addr_id、file_id、work_id、tenant_id、article_id。

注意：参数不一定放在 URL GET，大量在 POST JSON Body 里面，JSON 里面的 id 同样会越权。

2.2 垂直越权高发业务模块

1. 用户管理：新增用户、删除用户、修改角色权限
2. 系统配置：修改站点参数
3. 后台日志查看、数据导出
4. 会员等级修改，重置任意用户密码

2.3 未授权访问高发

后台管理路径、内部接口、监控接口、swagger 接口文档。

测试小技巧：完整走一遍业务流程，Burp 抓全部请求包，把所有携带 ID 类参数的请求全部标记出来，这些就是越权测试重点对象。

3. 实战前置准备：账号环境、抓包工具、测试前准备工作

想要成功复现越权，账号环境是重中之重，很多新手挖不出越权，就是账号准备不到位。

3.1 需要准备的测试账号

1. 账号 A（普通账号 A），用来生成属于 A 自己的资源：创建订单、新增收货地址、生成工单，拿到 A 对应的资源 ID。
2. 账号 B（同权限普通账号 B），和 A 权限完全一样，用来测试水平越权。使用 B 的 Cookie/Tocken，去尝试访问 A 的资源 ID。
3. 如果测试垂直越权，条件允许尽量准备管理员账号，拿到管理员接口路径；没有管理员账号，就用普通账号直接尝试调用猜测的管理员接口。

重点：两个账号必须完全独立，注册两个手机号，不要共用会话。浏览器可以用两个浏览器或者无痕模式分别登录，避免 Cookie 互相污染。

3.2 抓包工具准备

Burp Suite 为首选，核心使用 Repeater 模块，用来替换 Cookie、修改 ID 参数，对比返回包。

越权测试核心不是 Intruder 爆破，而是 Repeater 反复切换不同账号 Token，对比响应结果。

3.3 测试前收集信息

1. 抓包记录账号 A 的 Cookie 或者 JWT Token；
2. 在账号 A 操作业务，拿到属于 A 的资源 ID：订单 id、地址 id；复制保存；
3. 抓包记录账号 B 的 Cookie/JWT Token；
4. 记录全部接口请求方式：GET / POST / JSON 请求；
5. 记录接口返回包正常返回和报错返回样例，用来后续对比。

很多新手踩坑：测试 A 的资源，忘记替换成 B 的 Cookie，依旧携带 A 自己的 Cookie，结果当然可以访问，误以为存在越权，造成误报。这是最高频错误！

4. 标准化完整测试流程：水平越权完整实操步骤

下面这套流程，可以直接套用到几乎所有业务接口。

步骤 1：登录账号 A，生成私有业务资源
登录账号 A，新增订单、新增收货地址，访问详情接口，抓包拿到请求包。
示例请求包：

GET /api/order/detail?order_id=10086 HTTP/1.1 Host: test-business.com Cookie: A账号的Cookie

响应返回账号 A 完整订单信息：姓名、手机号、收货地址。复制资源 IDorder_id=10086。

步骤 2：切换账号 B 的身份凭证
复制上面这个请求包，发送到 Burp Repeater。把 Cookie 替换为账号 B 的 Cookie，order_id 保持为 A 的 10086，不要修改 ID。

关键点：现在身份是账号 B，访问属于账号 A 的 order_id=10086。

步骤 3：发送请求，分析响应结果，三种情况
情况①：返回 200，完整返回 A 账号订单全部手机号地址信息。✅确认水平越权漏洞真实存在。

情况②：返回 403、401、业务错误码无权访问、订单不属于该用户。✅权限校验正常，不存在越权。

情况③：返回空数据、返回 B 自己的订单、返回订单不存在。无漏洞。

步骤 4：确认漏洞可复现，多次验证排除缓存干扰
调换顺序，A 的 Cookie 访问 B 的资源 ID，再次测试一遍，双向验证。避免页面缓存造成假象。

步骤 5：测试写入型越权（修改、删除操作，危害更高）
上面是读取越权（查看别人数据），更危险的是修改、删除越权。
比如修改地址接口：

POST /api/address/update HTTP/1.1 Host: test-business.com Cookie: B账号Cookie Content‑Type: application/json {"addr_id":A的地址id,"receiver":"攻击者修改名字"}

使用 B 账号 Cookie，修改 A 的 addr_id。如果提交成功，A 账号的收货地址被篡改，属于高危写入越权。

越权分为读越权和写越权，写越权危害等级更高，提交 SRC 报告时要区分说明。

步骤 6：批量风险评估
ID 如果是自增数字，代表攻击者可以枚举全部 ID，批量遍历全站用户资源。如果是随机 UUID，无法简单遍历，危害等级会下降。

水平越权测试核心口诀

拿 A 的资源 ID，带 B 的身份凭证，发送请求；双向验证，排除缓存，区分读 / 写越权。

5. 垂直越权完整挖掘流程实战

垂直越权是低权限账号调用高权限接口，两种测试思路。

方式一：有管理员账号，拿到管理员接口

1. 使用管理员账号登录，Burp 抓包，把全部管理员接口保存下来，例如：POST /api/admin/user/delete删除用户POST /api/admin/user/setRole修改用户角色
2. 将这些管理员请求包放到 Repeater，把 Cookie 替换为普通低权限账号 Cookie，接口路径、POST 参数保持不变。
3. 发送请求：

• 如果返回 200，成功执行管理员操作，确认垂直越权；
• 返回 403、无权限，权限校验正常。

方式二：没有管理员账号，猜测接口路径

真实 SRC 测试经常拿不到管理员账号。依靠业务路径命名习惯猜测管理接口：
常见路径前缀：/admin、/manage、/backend、/api/admin/

操作：普通用户登录状态，直接 GET/POST 访问这些管理接口，观察是否允许执行高权限功能。

注意很多开发只做前端菜单隐藏，后端没有拦截。前端看不到按钮，但是接口依然可以被普通用户调用。

垂直越权典型案例：普通用户调用修改角色接口，把自己账号角色修改为 admin，直接提升为管理员权限。

请求示例：

POST /api/admin/user/updateRole HTTP/1.1 Host: test‑business.com Cookie:普通用户Cookie Content‑Type:application/json {"user_id":"1001","role":"admin"}

如果执行成功，就是垂直越权权限提升。

6. 未授权访问漏洞挖掘思路

未授权访问测试：去掉身份凭证，看是否依旧可以访问需要登录的接口。

操作步骤：

1. 正常登录状态抓包，可以正常访问的业务接口；
2. 将请求包放到 Repeater，直接删掉 Cookie 字段，或者删掉 Authorization JWT 头；
3. 发送请求：

• 返回 200，正常拿到业务数据 → 存在未授权访问；
• 返回 401、403、跳转登录页面 → 鉴权正常。

注意区分：有些接口首页公开不需要登录，这属于业务设计；只有本应登录才能访问的私有资源，无需凭证就能访问，才算漏洞。

测试小技巧：

1. 后台管理页面直接浏览器访问，不登录；
2. API 接口去掉 JWT Authorization 请求头测试；
3. 部分业务只校验 Cookie 是否存在，不校验 Cookie 有效性，填一个随便伪造 Cookie 也能访问，同样属于未授权。

7. 现实业务各种难点场景：加密 ID、JWT、UUID、签名参数

上面是最简单明文自增 ID 场景，现实业务系统经常做防护，ID 不再是简单数字，会遇到加密 id、UUID、接口签名、JWT Token 场景，很多新手遇到就直接放弃。

7.1 场景 1：资源 ID 使用 UUID 随机字符串，非自增数字

业务资源 ID 不是数字，是类似f342ac01‑xxxx‑4421‑xxxx‑xxxUUID 字符串。
问题：无法简单遍历 ID，但是依然可能存在越权漏洞。

测试思路：

1. 账号 A 业务页面，页面响应、JS 返回包中找到 A 的完整 UUID；
2. 复制这个 UUID，使用账号 B 的 Token 去访问；
3. 如果成功读取，确认越权。

只是攻击者不能批量枚举，但是拿到 UUID 的情况下可以越权访问单条资源，依旧属于漏洞，只是危害等级降低。
注意：UUID 随机不等于安全，UUID 只是增加枚举难度，不能当做权限校验方案。很多开发误以为用 UUID 就可以避免越权，这是巨大误区。

7.2 场景 2：ID 经过前端加密，数据包里面看不到明文 ID

业务数据包里面的 id 是加密字符串，不是明文数字。
两种情况：

1. 加密运算在浏览器 JS 完成；
   处理：抓 A 账号正常请求，直接复制数据包里面加密之后完整参数值，不要解密。放到 B 账号请求包直接使用加密后的密文，发送请求。不需要逆向解密算法，直接复用密文测试越权。

重点：越权测试不需要解密！直接复用业务自己生成的加密字符串，切换 Cookie 发包即可。

2. 服务端生成密文，密文和用户身份绑定：A 生成密文，B 使用密文返回无权限，代表后端做了绑定防护，无漏洞。

7.3 场景 3：接口带有 Sign 签名校验，请求参数携带签名 sign

业务接口全部带有 sign 签名，参数修改之后 sign 校验失败，请求被拦截。
测试思路：

1. 账号 A 正常操作，完整复制一整条请求包（全部参数 + sign 签名完整复制）；
2. 仅仅把 Cookie/JWT 替换成账号 B，其余参数、sign 完全不动，直接发送。

不去篡改参数，只是替换身份凭证。如果后端校验 sign 只校验参数完整性，没有绑定用户身份，就会触发越权。
很多签名只防参数篡改，签名没有和当前登录用户做绑定，造成防护失效。

7.4 场景 4：使用 JWT Token 鉴权，无 Cookie，Authorization: Bearer xxx

现在前后端分离项目大量使用 JWT。
测试要点：

1. 账号 A 拿到 A 的 Bearer Token；账号 B 拿到 B 的 Bearer Token；
2. Repeater 修改 Authorization 头切换 Token，其他参数不变；

坑：JWT 不要手动去修改里面 payload 的 user_id。绝大多数 JWT 有签名，篡改之后直接校验失败。不要修改 JWT 内容，只做整体替换。

7.5 场景 5：参数 user_id 从前端传入

很多请求 JSON 里面同时携带user_id字段，这个字段是前端传过来的。
危险案例：

{"user_id":1002,"order_id":2001}

后端直接使用 JSON 中的 user_id 作为操作用户，没有从 JWT、Session 解析当前真实登录用户 id。攻击者修改 user_id 为别人 id 实现越权。
测试：保持自己 Token 不变，修改请求包中 user_id 为其他用户 id，观察是否成功操作他人资源。

安全原则：当前登录用户 ID，必须服务端从会话（Session/JWT）内部解析读取，绝对不能信任前端 http 请求传入的 user_id。

8. 真实业务模拟实战案例（5 个业务场景复现）

案例 1：电商订单读取水平越权（高危）

业务描述：电商订单详情接口，GET 传参 order_id。
账号 A 创建订单 order_id=5001；账号 B 登录。
B 的 Cookie，访问/api/order/detail?order_id=5001，返回 A 的姓名、手机号、收货地址。
根因：只根据 order_id 查询，没有校验该订单 user_id 是否等于登录用户 id。
危害：泄露用户手机号地址隐私，如果 id 自增，批量遍历全部用户订单。

案例 2：修改收货地址写入型水平越权（高危）

业务：修改收货地址接口 POST JSON。
账号 A 生成 addr_id=121。账号 B 登录。
B 发包：{"addr_id":121,"receiver":"测试修改"}，请求成功。
账号 A 登录查看，收货地址被篡改。

写入越权危害高于读取越权，可以篡改他人业务数据。

案例 3：SaaS 多租户系统越权查看其他租户报表

SaaS 系统每个企业一个 tenant_id。接口传入 tenant_id 查询报表。普通用户修改 tenant_id 为其他企业编号，读取别家企业业务数据。
SaaS 系统越权属于高频高危。

案例 4：垂直越权：普通用户提升自己角色为管理员

普通用户调用接口/api/user/updateRole，传入user_id=自己id,role=admin。后端没有角色校验，执行成功，普通账号获得全部管理员权限。

案例 5：工单附件下载未授权访问

下载附件接口/api/file/download?file_id=8001，删除 Cookie，直接访问链接，就可以下载工单附件。不需要登录。未授权访问。

9. 如何区分越权漏洞与误报，新手常见误报场景汇总

越权测试新手非常容易产出大量误报，提交 SRC 被驳回，下面列出高频误报场景，测试完成之后逐条核对。

误报 1：切换 ID，Cookie 忘记替换，依旧使用资源所属账号 Cookie

A 账号 Cookie，访问 A 的 order_id，当然可以访问，误以为越权。
✅校验标准：访问 A 资源的时候，必须携带 B 账号身份凭证。

误报 2：页面缓存导致结果异常

浏览器缓存，上一次 A 的响应被缓存，B 发包返回缓存的 A 数据。
✅解决：Burp repeater 测试，关闭缓存，双向互换账号再次测试。

误报 3：业务本身就是公开资源

比如公告、公开文章，设计上允许所有人查看，不属于越权。区分私有资源与公开资源。

误报 4：返回数据是当前账号自己的数据，不是目标 ID 对应数据

修改 order_id=9999，返回的依旧是 B 账号自己的订单，属于后端做了过滤，不是漏洞。

误报 5：UUID 场景，自己账号生成的 UUID 当然可以访问

拿 A 账号 Token 访问 A 生成 UUID，不能证明漏洞，必须 B 账号 Token 访问 A 的 UUID。

误报 6：返回资源不存在、404，不是越权。

判定真实越权漏洞四条标准

1. 使用另一个用户身份凭证；
2. 成功读取 / 修改属于其他账号的私有业务资源；
3. 双向测试可稳定复现，排除缓存；
4. 该资源业务逻辑上本不允许当前用户访问。

只有全部满足，才是真实越权漏洞。

10. 越权漏洞 SRC 漏洞报告完整模板

提交漏洞报告，清晰的复现步骤至关重要。很多人报告写的含糊不清，厂商无法复现直接驳回。下面模板可以直接修改使用。

漏洞标题：【水平越权】xxx 业务订单接口可越权读取任意用户订单手机号地址
漏洞等级：高危
资产：test‑business.com
漏洞描述：
业务订单详情接口 /api/order/detail 只校验登录状态，未校验订单资源归属用户。攻击者登录普通账号，修改 order_id 参数，可读取其他用户订单全部隐私信息（姓名、手机号、收货地址），order_id 为自增数字，可批量枚举全站订单数据，造成大量用户隐私泄露。

复现前提
账号 A（测试账号 1）、账号 B（测试账号 2）两个普通业务账号。

复现步骤

1. 使用账号 A 登录业务系统，创建一条测试订单，抓包获取订单编号 order_id=10086；
2. 使用账号 B 登录，获取账号 B 的 Cookie；
3. Burp 构造请求包，携带账号 B 的 Cookie，请求接口 GET /api/order/detail?order_id=10086；
4. 接口返回 HTTP 200，响应包返回账号 A 的订单信息，包含手机号、收货地址，实现越权访问。

危害

1. 越权读取任意用户订单、手机号、收货地址，造成用户隐私泄露；
2. ID 自增，攻击者编写脚本批量遍历，泄露全站用户订单数据；
3. 如果接口支持修改删除，可篡改他人业务数据。

修复建议

1. 接口查询订单时，除 order_id 之外，必须同时校验数据库中该订单记录归属 user_id 与当前登录会话解析得到用户 ID 保持一致；
2. 用户身份 ID 必须从 Session/JWT 会话解析获取，禁止信任前端传入 user_id 参数；
3. 对于写入、删除类接口，同样增加资源归属权限校验；
4. 测试环境增加越权安全测试用例，迭代上线回归测试。

附件：请求包响应包截图（关键信息脱敏）

11. 代码层面根因剖析：错误代码 vs 安全修复代码（Java SpringBoot + PHP）

很多开发修复越权，仅仅增加黑名单，或者使用 UUID，没有修复底层逻辑。这里对比错误写法和正确修复代码。

SpringBoot Java 错误示例（高危越权）

//危险代码！仅仅根据前端传入orderId查询，没有归属校验 @GetMapping("/api/order/detail") public Result getOrderDetail(Long orderId){ Order order = orderMapper.selectById(orderId); return Result.success(order); }

SpringBoot Java 安全修复示例

@GetMapping("/api/order/detail") public Result getOrderDetail(Long orderId, HttpServletRequest request){ //【关键】从会话/JWT解析当前登录用户ID，绝对不取前端参数 Long loginUserId = UserSessionUtil.getLoginUserId(request); //查询同时带上归属用户id条件 Order order = orderMapper.selectByIdAndUserId(orderId,loginUserId); if(order == null){ return Result.fail("无权限访问该订单"); } return Result.success(order); }

核心：查询条件同时包含资源 ID + 当前登录用户 ID，数据库层面做归属校验。

PHP 危险示例

<?php $order_id = $_GET['order_id']; //直接根据id查询，没有用户归属校验 $sql = "select * from `order` where id = ".$order_id; $res = mysqli_query($conn,$sql); ?>

PHP 修复之后

<?php session_start(); //从服务端session拿到登录用户id，不要从http参数拿 $login_uid = $_SESSION['user_id']; $order_id = $_GET['order_id']; //查询条件带上归属uid $sql = "select * from `order` where id=? and user_id=?"; $stmt = $conn->prepare($sql); $stmt->bind_param("ii",$order_id,$login_uid); $stmt->execute(); ?>

重点提醒：UUID 加密 ID 只是提升枚举成本，不能替代资源归属校验，就算使用 UUID，代码依旧必须校验 user_id 归属，否则依然越权。

12. 越权绕过思路：开发做了部分防护如何继续测试

实战中开发会做简单防护，但是防护不完整，存在绕过空间。

绕过 1：只对 GET 接口校验，POST JSON 接口忘记校验

很多开发修复了 GET 查询接口，但是忘记 POST 修改、删除接口。读取接口修复，写接口依旧越权。

测试技巧：不要只测试查询详情，重点测试修改、删除接口。

绕过 2：网关层只校验是否登录，业务服务没有校验归属

微服务架构，网关统一校验登录状态，但是网关不会感知业务资源归属，把权限校验交给业务代码，业务代码漏写校验直接越权，这是微服务高频坑点。

绕过 3：参数名称不一样，部分接口漏校验

比如有的接口参数叫order_id做了校验，另一个接口参数叫oid，开发漏处理 oid，造成越权。

绕过 4：Restful 路径参数漏校验

/api/order/{orderId}路径携带 ID，开发只校验表单参数，忘记校验路径里面的路径变量。

绕过 5：不同终端接口防护不一致

Web 端修复越权，APP、小程序后端接口复用同一套逻辑，部分版本接口没有同步修复。

13. 实战踩坑总结：挖越权经常踩的坑

1. ❌测试越权，忘记切换账号 Cookie/Tocken，直接使用资源所有者身份发包，造成大量误报；
2. ❌只测试读取接口，忽略修改、删除写入型越权；写入越权危害更高；
3. ❌误以为 UUID 加密 ID 就不会越权，UUID 只能防批量枚举，不能解决权限校验缺失；
4. ❌只测试 GET 参数，忽略 JSON Body 里面的 id 参数；
5. ❌把前端菜单隐藏当成安全，不去抓包测试后端接口；
6. ❌JWT 越权测试手动修改 JWT 里面 user_id，签名校验失败，直接放弃；正确做法是整体替换完整 Token；
7. ❌扫描器跑完没有告警，就判定没有越权；越权几乎无法自动化扫描；
8. ❌只单向测试 A 访问 B，不反向 B 访问 A，没有排除缓存问题；
9. ❌接口签名 sign 只校验参数完整性，没有绑定用户身份，造成防护失效。

14. 开发生产环境完整加固方案

1. 区分登录认证 和 权限校验：认证判断你是谁；权限校验两件事：①该角色能不能执行这个功能；②这条资源是否归属于当前登录用户。两个校验缺一不可。
2. 资源查询，数据库查询条件必须带上当前登录用户 ID，从会话 / JWT 解析，禁止从前端请求获取用户身份 ID。
3. 角色访问控制：管理员接口增加角色拦截器，低权限角色直接拦截，不依赖前端菜单隐藏。
4. 微服务场景：网关负责登录认证，业务服务必须自行完成资源归属校验，不能把权限全部交给网关。
5. UUID / 加密 ID 仅作为资源标识符，不能当做权限防护手段。
6. 所有私有资源接口，编写越权安全测试用例，迭代上线回归测试。
7. 安全编码培训：避免开发出现 “只要登录就安全” 的错误认知。

WAF、黑名单无法防护越权漏洞，越权是业务逻辑缺陷，WAF 识别不出来，必须代码层面修复。

15. 练习路线：如何训练自己挖掘越权的能力

越权是非常适合新手入门产出漏洞的方向，不需要复杂 Payload，重点是业务思维。

1. 靶场练习：Pikachu 靶场越权关卡，使用两个账号完整复现水平、垂直越权，不要复制 POC，严格按照上面的测试流程操作。
2. DVWA 越权关卡，手工抓包完成复现，理解代码错误点。
3. 本地搭建简单业务 demo，自己写出存在越权的接口，再修改为安全代码，理解代码层面差异。
4. 练习看公开越权漏洞案例，思考漏洞复现的账号环境，思考开发哪里少写了一行校验代码。
5. 练习写漏洞报告：模拟漏洞，完整写出复现步骤。

训练思考问题：每看到一个带 id 的接口，反问自己：这个接口后端，从哪里拿到当前登录用户？查询数据库的时候，有没有对比资源归属 user_id？

最后

关于网络安全技术储备

网络安全是当今信息时代中非常重要的一环。无论是找工作还是感兴趣（黑客），都是未来职业选择中上上之选，为了保护自己的网络安全，学习网络安全知识是必不可少的。

如果你是准备学习网络安全（黑客）或者正在学习，下面这些你应该能用得上：

①网络安全学习路线
②20份渗透测试电子书
③安全攻防357页笔记
④50份安全攻防面试指南
⑤安全红队渗透工具包
⑥网络安全必备书籍
⑦100个漏洞实战案例
⑧安全大厂内部视频资源
⑨历年CTF夺旗赛题解析

一、网络安全（黑客）学习路线

网络安全（黑客）学习路线，形成网络安全领域所有的知识点汇总，它的用处就在于，你可以按照上面的知识点去找对应的学习资源，保证自己学得较为全面。

二、网络安全教程视频

我们在看视频学习的时候，不能光动眼动脑不动手，比较科学的学习方法是在理解之后运用它们，这时候练手项目就很适合了。

三、网络安全CTF实战案例

光学理论是没用的，要学会跟着一起敲，要动手实操，才能将自己的所学运用到实际当中去，这里带来的是CTF&SRC资料&HW资料，毕竟实战是检验真理的唯一标准嘛~

四、网络安全面试题

最后，我们所有的作为都是为就业服务的，所以关键的临门一脚就是咱们的面试题内容，所以面试题板块是咱们不可或缺的部分，这里我给大家准备的就是我在面试期间准备的资料。

网安其实不难，难的是坚持和相信自己，我的经验是既然已经选定网安你就要相信它，相信它能成为你日后进阶的高效渠道，这样自己才会更有信念去学习，才能在碰到困难的时候坚持下去。

机会属于有准备的人，这是一个实力的时代。人和人之间的差距不在于智商，而在于如何利用业余时间，只要你想学习，什么时候开始都不晚，不要担心这担心那，你只需努力，剩下的交给时间！

这份完整版的网络安全学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】