[i=s] 本帖最后由 zeke 于 2025-9-24 15:05 编辑 [/i]
WEB渗透测试工程师系统班250303期
42节课作业
1、什么是逻辑漏洞
逻辑漏洞是应用程序在业务逻辑或流程设计上存在的缺陷，使得攻击者能够利用这些缺陷执行非预期的操作，从而绕过安全限制或获取不正当利益。
2、越权访问攻击有几种，分别是什么
核心分类：三种越权访问攻击
越权访问攻击主要分为以下三种：
①水平越权
②垂直越权
③上下文相关的越权（有时也被视为水平越权的一种特殊情况）
①. 水平越权
核心定义：相同级别的用户之间，用户A能够未经授权地访问或操作用户B的数据。
攻击者与受害者关系：攻击者和受害者拥有相同的用户权限级别（例如，都是普通用户）。
关键点：攻击的目标是数据，而不是提升权限。
经典实例：
修改ID参数：用户登录后，在查看自己的订单、个人信息、收货地址时，浏览器地址栏或请求参数中会包含一个标识符（如 ?id=123）。如果用户A将自己的ID 123 改为 124，就能看到用户B的订单信息，这就是典型的水平越权。后端没有校验“当前登录的用户”是否是“所请求数据的主人”。
修改用户名/手机号：在个人信息修改功能处，通过抓包修改请求中的username或phone参数为其他用户的，如果后端未校验，就可能覆盖其他用户的信息。
②. 垂直越权
核心定义：低权限的用户能够执行本应只有高权限用户（如管理员）才能进行的操作。
攻击者与受害者关系：攻击者从一个低权限角色（如普通用户、未登录游客）提升到了高权限角色（如管理员、运营人员）。
关键点：攻击的目标是功能权限，直接提升了在系统中的地位。
经典实例：
直接访问管理员URL：网站的管理员功能链接（如 https://example.com/admin/deleteUser）在前端页面上对普通用户是隐藏的，但攻击者可以通过猜测或信息泄露得知该地址。如果后端仅仅依靠前端隐藏菜单，而没有在每次请求时校验用户角色，那么普通用户直接访问该URL就能执行删除用户的操作。
修改Cookie或请求参数中的角色标识：在请求参数、Cookie或JWT令牌中，可能存在一个如 role=user 的字段。攻击者将其修改为 role=admin，如果后端完全信任这个值而没有从数据库重新验证，就会导致垂直越权。
通过低权限功能组合实现高权限操作：某个低权限功能存在缺陷，可以被利用来间接执行高权限操作。
③. 上下文相关的越权
核心定义：这种越权发生在一个多步骤的业务流程中，用户违反业务逻辑的顺序，访问了在当前上下文中不应被访问的步骤或数据。
攻击者与受害者关系：通常是用户自己，但通过绕过业务规则，获得了不正当的利益或完成了非预期的操作。
关键点：它利用了业务流程状态控制的缺失。
经典实例：
密码重置流程绕过：正常的密码重置流程是：1. 输入用户名/邮箱 -> 2. 验证身份（如输入短信验证码）-> 3. 设置新密码。如果攻击者在第一步后，直接通过抓包修改请求跳转到第三步，而服务端没有检查“当前会话是否已经完成了第二步的身份验证”，那么就发生了上下文越权。这意味着攻击者只要知道你的用户名（第一步），无需验证码就能重置你的密码。
跳过支付流程：在电商平台，订单流程是：1. 添加商品 -> 2. 确认订单 -> 3. 支付 -> 4. 支付成功。如果攻击者从第二步直接构造请求访问第四步的“支付成功”页面，而服务端没有验证该订单的实际支付状态，就可能将未支付的订单标记为成功。
3、越权访问修复方案
核心修复原则
①服务端校验是唯一准则：所有权限判断必须在服务端进行。前端隐藏菜单、禁用按钮只是UI优化，毫无安全作用。
②默认拒绝：系统默认应拒绝所有请求，只有显式配置了允许的规则才能通过。
③最小权限：用户只应拥有完成其任务所必需的最小权限。
④贯穿始终的权限上下文：在整个业务逻辑中，都需要携带并验证当前用户的权限上下文。
一、 代码层修复方案（具体技术实现）
这是最直接、最有效的修复手段。
1.修复水平越权
漏洞根源：服务端在处理数据请求时，仅根据客户端传入的ID（如order_id=123）查询数据，而未校验该数据是否属于当前登录的用户。
修复方案：在查询/操作中绑定当前用户ID
在执行任何数据库查询或操作时，必须将“当前登录用户的ID”作为必要条件。
2.修复垂直越权
漏洞根源：服务端仅通过前端隐藏功能或简单的角色参数来判断权限，未在接口入口进行强制角色/权限校验。
修复方案：基于角色的访问控制（RBAC）
定义权限点：为每个需要权限控制的后端接口（API Endpoint）定义一个唯一的权限点（如order:delete）。
校验角色或权限：在接口被调用前，校验当前用户是否拥有所需角色或权限。
3.修复上下文相关的越权
漏洞根源：服务端未校验多步骤业务流程的完整性和顺序性。
修复方案：维护服务端会话状态
在服务端使用Session、缓存（如Redis）或数据库字段来记录流程的当前状态。
示例：密码重置流程
用户请求重置密码，输入邮箱。服务端生成一个随机的、一次性的Token（如reset_token_abc123），并将其与用户的邮箱、状态step1_completed一起存入缓存，并设置较短的有效期（如15分钟）。
用户提交验证码。服务端校验缓存中该用户的Token是否存在且状态正确，然后验证验证码。验证通过后，将状态更新为step2_verified。
用户设置新密码。服务端必须校验请求中的Token是否存在，且状态为step2_verified。校验通过后，才允许修改密码，并立即使该Token失效。
二、 架构与设计层方案
①统一的访问控制层（中间件/过滤器）：在Web框架的请求入口处（如Spring的Interceptor、Filter）设置统一的权限校验逻辑，避免在每个业务方法中重复编写校验代码。
②使用安全的、不可预测的标识符：避免使用自增ID（1, 2, 3）作为资源标识符暴露给前端。改用UUID、雪花算法ID等，增加攻击者猜测的难度。
③API网关治理：在微服务架构中，可在API网关层对路由进行初步的认证和粗粒度权限校验。
三、 流程与管理层方案
①威胁建模：在系统设计阶段，就识别出哪些数据和服务是敏感的，分析可能存在的越权风险点。
②代码审查：将权限校验代码作为代码审查的重点。重点关注所有涉及ID参数传递、接口访问的代码。
③专项安全测试：
手动渗透测试：测试人员手动修改请求中的ID、角色参数，尝试跳过步骤，检验系统是否有效拦截。
自动化工具辅助：虽然自动化工具难以发现所有逻辑漏洞，但可以编写自定义脚本，批量测试ID遍历等问题。
4、业务逻辑分类中的登录体系安全有哪些逻辑漏洞
一、 身份认证绕过漏洞
这类漏洞的核心是无需获得用户密码或其他认证要素，就能直接以该用户身份登录系统。
①密码重置漏洞
漏洞点：密码重置功能的设计缺陷。
具体表现：
Ⅰ.验证码可爆破：重置密码时发送的短信/邮箱验证码位数过短（如4位）、无时间限制、无尝试次数限制，导致可被暴力破解。
Ⅱ.Token安全问题：重置密码的链接中包含可预测的Token（如基于时间戳或用户ID生成），或Token有效期过长，甚至不失效。
Ⅲ.凭证泄漏：重置密码成功后，系统直接在返回包或页面上显示新密码（明文），而非强制跳转到登录页。
Ⅳ.邮箱/手机号篡改：在重置流程中，第一步输入邮箱/手机号，第二步验证身份，但攻击者通过抓包在第二步请求中将邮箱/手机号修改为受害者的，从而为受害者账户重置密码。
②万能密码/万能验证码
漏洞点：后端代码存在硬编码或调试后门。
具体表现：系统存在一个特殊的密码（如debug、000000）或验证码（如000000），使用这个密码可以登录任何账户。这常出现在开发阶段的测试代码，上线后被遗忘删除。
③条件竞争漏洞
漏洞点：登录逻辑在多线程或并发处理时存在时序问题。
具体表现：系统在验证短信验证码登录时，先校验验证码是否正确，正确后再查询手机号对应的账户。攻击者同时发送两个请求：第一个使用自己的手机号和正确的验证码；第二个使用受害者的手机号和任意错误的验证码。在极端情况下，服务器可能先处理第二个请求（校验错误失败），但紧接着第一个请求的验证状态覆盖了会话，导致最终登录了受害者账户。
二、 认证凭证窃取与伪造漏洞
这类漏洞的核心是攻击者能够合法地获取或非法地构造代表用户身份的凭证（如Session、Token）。
①Session fixation（会话固定）攻击
漏洞点：登录前后Session ID未发生变化。
具体表现：攻击者先访问网站获取一个合法的Session ID，然后诱导受害者使用这个特定的Session ID登录（例如，通过构造一个带SID的链接：http://example.com/login?sid=attacker_sid）。受害者登录后，该SID就拥有了受害者的权限，攻击者即可利用已知的SID劫持会话。
②Token设计缺陷
漏洞点：自定义的Token（如用于“记住我”功能、APP认证）设计不当。
具体表现：
Ⅰ.Token可预测：Token由用户ID、时间戳等简单信息加密生成，规律可循。
Ⅱ.Token信息泄露：Token使用Base64编码而非加密，解码后可直接看到用户ID等敏感信息，可被篡改。
Ⅲ.JWT令牌误用：未对JWT签名进行严格验证；或使用弱密钥；JWT中包含敏感信息。
三、 用户枚举漏洞
这类漏洞本身不能直接登录，但能探测出系统中哪些用户名/手机号/邮箱是已注册的，为后续的撞库攻击或精准钓鱼提供目标清单。
①登录错误提示差异
漏洞点：系统对“用户名不存在”和“密码错误”返回了不同的错误信息。
具体表现：
Ⅰ.前端提示：提示“用户名不存在” vs “密码错误”。
Ⅱ.HTTP状态码：返回不同的状态码（如404 vs 401）。
Ⅲ.响应时间差异：“用户名不存在”时系统直接返回，响应快；“密码错误”时系统需要校验密码哈希，响应稍慢。
②注册功能枚举
漏洞点：用户注册时，提示“该手机号已注册”。
具体表现：攻击者遍历手机号段，根据系统返回的“已注册”提示，即可筛选出所有已注册用户。
③密码重置功能枚举
漏洞点：输入邮箱/手机号请求重置时，提示“该账户不存在”或“验证码已发送至已注册邮箱”。（后者实际上也暗示了账户存在）。
四、 多因素认证（MFA/2FA）绕过漏洞
在已具备密码的基础上，攻击者绕过第二重认证。
①MFA状态绕过
漏洞点：MFA验证状态校验不严。
具体表现：用户完成密码验证后，进入MFA验证步骤。攻击者通过直接跳转到登录后的主页面URL（如/home）来绕过MFA验证。服务端没有在访问/home时校验当前会话是否已完成MFA验证。
②MFA代码爆破
漏洞点：MFA验证码（如TOTP的6位数字）无尝试次数限制，可被暴力破解。
③MFA恢复流程缺陷
漏洞点：绕过MFA的“备用码”或“恢复邮箱”流程存在漏洞。
具体表现：恢复流程过于简单（如仅通过邮箱验证即可禁用MFA），如果攻击者控制了用户的邮箱，即可轻易移除MFA保护
5、业务逻辑分类中的业务数据篡改有哪些逻辑漏洞
业务数据篡改的核心是攻击者通过修改客户端与服务器之间传输的业务数据，导致服务器处理了非预期的、被恶意篡改后的数据，从而获取不正当利益或破坏业务完整性。
这类漏洞的根源在于：服务器过分信任客户端传来的数据，且没有对这些数据在业务逻辑层面的合理性和合法性进行二次校验。
一、 关键业务参数篡改
这是最直接的数据篡改形式，攻击者修改直接影响交易结果的参数。
①商品价格篡改
漏洞描述：在提交订单或支付请求时，参数中包含商品价格（如 "price": 100.00）。攻击者将其修改为任意值，如 0.01 或 -50。
实例：
Ⅰ.负数价格：将价格改为负数，可能导致用户余额反而增加，实现“薅羊毛”甚至套现。
Ⅱ.低价购买：将高价商品改为极低价格，以近乎免费的方式购
买。
根源：服务端最终计算订单总额时，直接使用了客户端传来的价格，而未从服务端数据库重新查询并确认价格。
②数量/金额篡改
漏洞描述：修改购买数量、转账金额等数值参数。
实例：
Ⅰ.无限兑换：在积分兑换礼品时，将兑换数量 "quantity": 1 改为 1000，用少量积分兑换大量商品。
Ⅱ.支付金额篡改：在充值或转账时，将 "amount": 10 改为 0.01，但服务端却根据此金额生成支付订单。
根源：服务端未对数量的合理性进行校验（如库存是否充足、用户积分是否足够），也未使用服务端计算出的金额。
③唯一标识符篡改
漏洞描述：修改指向特定资源的ID，如商品ID、优惠券ID、订单ID。
实例：
Ⅰ.优惠券替换：用户有一张9折券（ID: coupon_id=101），但攻击者通过抓包发现存在一张满减券（ID: coupon_id=102）。他将自己的券ID修改为满减券ID，试图享受更大力度的优惠。
Ⅱ.商品替换：将廉价商品的ID（如 product_id=1 袜子）替换为高价商品的ID（如 product_id=999 手机），但结算时仍按廉价商品流程处理。
根源：服务端在应用优惠券或确认商品信息时，仅根据客户端传来的ID进行查询，未校验该ID是否真正属于当前用户或适用于当前订单。
二、 状态标识篡改
攻击者修改业务流程中的状态标志，从而跳过必要步骤或直接进入完成状态。
①支付状态篡改
漏洞描述：在客户端回调或查询支付结果时，伪造“支付成功”的状态信号。
实例：某些支付流程依赖客户端返回的支付结果。攻击者拦截请求，将 "status": "pending" 改为 "status": "success"，欺骗服务器认为支付已成功，从而发货或开通服务。
根源：支付状态必须依赖服务端与支付网关（如支付宝、微信支付）的后端异步通知（Server-side Notification）进行确认，绝不能信任客户端。
②业务环节状态篡改
漏洞描述：修改多步骤流程中的当前步骤标识。
实例：一个审核流程有“提交->初审->复审->通过”几个状态。攻击者通过修改参数，将状态从“提交”直接改为“通过”，绕过审核。
根源：业务流程的状态机应由服务端严格控制和维护，客户端只能触发状态变更的请求，而不能直接指定目标状态。
三、 批量操作篡改
本应为单条记录的操作，通过参数篡改实现对多条记录的批量操作，常与越权结合。
①批量赋值漏洞
漏洞描述：在修改用户信息（如收货地址）时，API接口设计为接收一个对象模型。攻击者不仅修改地址，还额外添加了如 "is_admin": true 的字段。
实例：用户更新个人资料的接口接受JSON数据 {"name": "新名字", "phone": "新手机号"}。攻击者提交 {"name": "黑客", "phone": "138...", "balance": 9999}，如果服务端未过滤字段，直接将整个对象更新到数据库，就会导致用户余额被篡改。
根源：服务端使用了不安全的“自动绑定”机制，应明确指定允许更新的字段白名单。
②批量删除/查询漏洞
漏洞描述：通过修改ID参数为数组形式，实现批量操作越权数据。
实例：删除留言的接口为 DELETE /message?id=123。攻击者将其修改为 DELETE /message?id=123,124,125，如果服务端处理了这种请求，就会一次性删除多条留言。
根源：服务端应设计为每次只操作一个ID，并对该ID进行所有权校验。
四、 序列化数据篡改
主要出现在使用自定义序列化数据（如Java反序列化、Python Pickle）或未正确签名的数据（如Cookie、Token）时。
反序列化漏洞
漏洞描述：攻击者篡改序列化后的数据，在服务端反序列化时执行恶意代码或修改对象属性。
实例：一个Java应用将用户权限信息序列化后存储在Cookie中。攻击者破解序列化格式，生成一个包含 "role: admin" 的恶意序列化对象，替换自己的Cookie，从而提升权限。
根源：使用了不安全的反序列化机制，应对序列化数据进行数字签名或避免反序列化用户可控的数据。
6、业务逻辑分类中的验证码突破有哪些逻辑漏洞
一、 验证码本身的设计缺陷
这类漏洞源于验证码生成机制过于简单或存在规律，使其可以被机器自动识别或推断。
①验证码可预测
漏洞描述：验证码不是由强随机数生成器生成的，存在某种规律或模式。
实例：
Ⅰ.时间戳生成：验证码基于当前时间戳（如秒数）简单加密或哈希生成，攻击者可以根据时间推测出可能的验证码范围。
Ⅱ.序列生成：验证码是递增或递减的（如第一次是1001，第二次是1002），攻击者可以轻易预测下一个验证码。
②验证码复杂度不足
漏洞描述：验证码过于简单，容易被现代的OCR（光学字符识别）技术或机器学习模型识别。
实例：
Ⅰ.纯数字/短字符集：仅使用4位纯数字，暴力破解的空间很小（10000种可能）。
Ⅱ.无扭曲、无干扰：验证码字符清晰、无旋转、无点线干扰，容易被OCR库直接识别。
Ⅲ.固定字体和位置：字符使用标准字体且位置固定，便于机器分割和识别。
③验证码答案泄漏
漏洞描述：验证码的正确答案在HTTP响应包、Cookie或前端HTML代码中泄漏。
实例：服务端生成验证码后，为了前端校验方便，将其以明文形式隐藏在HTML的隐藏域（``）或返回给客户端的JSON数据中。攻击者只需提取该值即可自动填写。
二、 验证码校验逻辑漏洞
这是最经典、最高发的逻辑漏洞，核心在于服务端校验流程存在缺陷。
①验证码可被暴力破解
漏洞描述：系统未对单次验证码的尝试次数进行限制，或者限制可以被绕过。
实例：一个4位数字短信验证码，理论上有1万种可能。如果系统允许无限次尝试，攻击者可以编写脚本在几分钟内穷举所有可能，从而突破验证码。即使有“图形验证码”，如果其本身可被识别，则暴力破解短信验证码的请求可以被自动化。
②验证码一次校验后未失效
漏洞描述：同一个验证码在使用一次后，没有在服务端立即作废（置为已使用状态），导致可以被重复使用。
实例：用户获取短信验证码123456并成功登录。攻击者截获了这个验证码，并立即在另一个登录会话中使用123456，如果服务端没有使该验证码失效，攻击者也能登录成功。
③验证码与会话绑定不严
漏洞描述：验证码没有与特定的客户端会话（Session）或设备标识符强绑定。
实例：
Ⅰ.Session覆盖/共享：系统为手机号138XXXXX生成验证码后，将其存储在服务器上，但只以手机号为键（Key）。攻击者可以先用自己的手机号获取一个验证码，然后在请求中将自己的手机号改为受害者的手机号，并填入自己刚收到的验证码。如果服务端只验证“手机号”和“验证码”是否匹配，而不管这个验证码是发给哪个会话的，攻击就会成功。
Ⅱ.缺少设备指纹绑定：在APP中，验证码未与设备ID、IP地址等因子绑定。攻击者可以为一个手机号在不同的设备上同时请求验证和验证。
③验证码校验环节可被绕过
漏洞描述：整个验证码校验步骤可以被跳过。
实例：这是一个经典的业务流程绕过漏洞。正常流程是：1. 输入手机号 -> 2. 输入验证码 -> 3. 登录成功。攻击者在第一步之后，通过抓包修改请求，直接访问第三步的API接口。如果服务端没有在第三步校验“当前会话是否已完成第二步验证”，则验证码形同虚设。
三、 验证码触发逻辑漏洞
这类漏洞出现在获取验证码的环节，常被用于恶意骚扰或资源耗尽攻击。
①短信/邮箱轰炸
漏洞描述：系统未对同一手机号/邮箱在单位时间内的获取次数进行限制，或者限制可以被绕过（如通过篡改手机号参数）。
实例：攻击者编写脚本，不断向同一个手机号发送验证码请求，导致用户的手机被垃圾短信淹没。更高级的攻击是，在“忘记密码”功能处遍历常见手机号段，触发大量短信发送，消耗企业短信资费。
②接口滥用导致资源耗尽
漏洞描述：图形验证码的生成需要服务器资源。如果生成接口无防护，攻击者可频繁请求，耗尽服务器CPU或内存资源。
实例：攻击者以极高并发请求/api/captcha/image接口，导致服务器因生成大量图片而负载过高。
四、 业务流程设计漏洞
验证码在整个业务流程中的位置和作用设计不当。
验证码前置导致用户枚举
漏洞描述：在用户登录时，先输入验证码，再校验用户名和密码。
实例：这种设计允许攻击者在不暴露账户是否存在的情况下，无限次尝试验证码。虽然防止了密码爆破，但破坏了“统一化错误信息”防御用户枚举的原则。攻击者可以先爆破验证码，再爆破密码。
一、笔记标题：WEB渗透系统班-逻辑漏洞（上）+逻辑漏洞（下）
二、文章内容：
1.课程内容概要
主要知识点1：越权访问
主要知识点2：登录安全
主要知识点3：数据篡改
主要知识点4：验证码突破
2.重点知识与细节
概念解析
概念1：逻辑漏洞
概念2：
关键步骤
步骤1：
步骤2：
步骤3：
相关代码
3.实操练习和解析
多看案例
4.个人总结
本节课最大的收获是：学习了一些逻辑漏洞的案例
仍然存在疑问的地方：暂无
需要课后深入学习的内容：逻辑漏洞的各种案例场景
