Michele

场景：通过不同的响应来枚举用户名睡觉之前无聊开一点简单题玩玩。都是很熟悉的。 浏览器提交登录表单时， 服务器一般有三种结果： 用户名不存在 用户名存在，但密码错误 用户名和密码都正确 安全的系统对前两种情况应尽量返回相同的提示，例如统一显示“用户名或密码错误”。否则，攻击者就可以根据响应差异判断某个用户名是否存在。 狙击手爆破用户名， 然后爆破密码 补充：几种攻击模式的不同：

业务逻辑漏洞业务逻辑漏洞是应用本身的业务流程设计存在缺陷。 场景：对客户端控件的过信任 在加入购物车之前把这里的积分数量修改 放行之后过来，价格直接变了。 成功创建订单 我后面又抓了一下创建订单这一步， 读取你购物车里已经有的商品和总价 → 对比你的账户积分 → 积分够就扣积分、生成订单；积分不够就拒绝。它不会再查一遍商品原价，默认 “购物车里的价格就是对的” 复盘： 这道题的业务逻辑是这样的，在POST /cart加购这里，把商品 ID、数量、price价格等参数传给后端，POST /cart/checkout提交订单这里，并未对参数进行验证。 正常逻辑应该是什么样的？ 加购时，客户端只传「商品 ID + 购买数量」，绝对不传价格； 服务端根据商品 ID 去数据库查真实定价，计算总价，存入购物车； 结账时，服务端再次根据商品 ID 重新计算一遍总价，和购物车数据做比对，确保一致后再扣款。 ==所有敏感数据（价格、金额、权限）都必须以服务端为准，绝对不能信任客户端提交的结果。== 场景：数量边界校验...

访问控制场景：未受保护的管理员功能 这道比较简单，是**robots.txt的知识点。这个只是给爬虫看的协议，不能阻止人类访问。**这个漏洞没有在服务端校验访问页面的权限，只要拿到了这个路径，任何人都能对用户进行删除。 场景：无保护的管理员功能，且相关 URL 难以预测 源码搜索发现admin路径。 场景：用户角色由请求参数控制 仍然是很熟悉很简单的一道题。最弱的前端鉴权，cookie参数可以被前端修改，服务端完全信任客户端 Cookie。如果是防护更完善的网站，每次响应都会重新下发 Set-Cookie 来覆盖修改，就不能在浏览器 Application 里改了，要用 Burp 抓包，直接修改请求包里的 Cookie再放行，每次请求都手动改成 true，这样就不会被服务器响应覆盖。 场景：用户角色可以在用户个人资料中修改 原理：垂直越权。在修改个人资料的接口这里，会接受roleid的角色参数，但服务端不校验是否有权限修改自己的角色。普通用户只要在更新资料的请求里加上roleid=2，就能给自己提权成管理员。 后端更新用户资料时，没有对传入字段做白名单过滤，也没有校...

访问控制场景：未受保护的管理员功能 这道比较简单，是**robots.txt的知识点。这个只是给爬虫看的协议，不能阻止人类访问。**这个漏洞没有在服务端校验访问页面的权限，只要拿到了这个路径，任何人都能对用户进行删除。 场景：无保护的管理员功能，且相关 URL 难以预测 源码搜索发现admin路径。 场景：用户角色由请求参数控制 仍然是很熟悉很简单的一道题。最弱的前端鉴权，cookie参数可以被前端修改，服务端完全信任客户端 Cookie。如果是防护更完善的网站，每次响应都会重新下发 Set-Cookie 来覆盖修改，就不能在浏览器 Application 里改了，要用 Burp 抓包，直接修改请求包里的 Cookie再放行，每次请求都手动改成 true，这样就不会被服务器响应覆盖。 场景：用户角色可以在用户个人资料中修改 原理：垂直越权。在修改个人资料的接口这里，会接受roleid的角色参数，但服务端不校验是否有权限修改自己的角色。普通用户只要在更新资料的请求里加上roleid=2，就能给自己提权成管理员。 后端更新用户资料时，没有对传入字段做白名单过滤，也没有校...

Michele-Codex 模型路由器（持续更新）前言： 前几天看到新出的jev，当时第一反应就是，这个东西可以拿来做模型路由器。正好我平时主力用的codex这边没有这个功能，我就想自己搓了。但是这几天上课就没动工。然后开始之前查了一下，github上已经有一些基于jev的模型路由了，大佬的速度真的很快hhh。但是但是，我发现这些里面，没有跟我的设想形态类似的，所以还是自己动手搓了。这应该是我第三次搓工具自己用了，也算有一丢丢经验。第一个是appleranker，效果不错，但一直觉得功能设计上还有改进的余地，然后有点没想好以什么具体的形态发出来所以还留在私有仓库，具体做什么这个就先留个神秘感hhh，如果公开了会写在博客里面的。还有一个是之前那个搁浅的sqlmap-auto，这个确实是我目前太菜了，想设计好具体的形态和流程有一定困难，所以目前还是个小玩具的样子，不太能用到实战里面。然后就是这个，模型路由器了。纯粹为爱发电了。这个版本目前是第二版，还在持续改进。这个过程中还是吸取了一些经验，比如，有了初步的构思之后，在定技术路线之前，要尽量把影响巨大的功能考虑进去，不然等后面都跑出来...

@ 开头的标签，不影响程序逻辑，但决定框架怎么对待这段代码。 第 1 层：类上的注解 —— 判断这是什么类12345@Api("水平越权") // IDOR1.java:21 Swagger 文档用，和安全无关，跳过@Slf4j // IDOR1.java:22 Lombok 生成 log 对象（所以能写 log.info）@RestController // IDOR1.java:23 ← 关键@RequestMapping("/vulnapi/IDOR") // IDOR1.java:24 ← 关键public class IDOR1 { // IDOR1.java:25 @RestController = 方法返回什么，浏览器就收到什么 审计动作：看到 @RestController / @Controller，把整个文件标记为入口文件...

java 文件有固定结构，按固定顺序读，就不会漏东西。 符号 意思 {} 花括号 圈定范围。类的内容、方法的内容都装在花括号里 ; 分号 一句话说完。每个”动作”结尾基本都是它 () 圆括号 装参数。方法名后面跟的括号里写输入 <> 尖括号 泛型，说明”这里面装的是什么类型的东西” @ 注解 贴给框架看的标签，不影响程序逻辑，但决定框架怎么对待这段代码 此处代码： 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172package com.best.hello.controller.IDOR;import com.alibaba.fastjson.JSON;import com.best.hello.entity.User;import com.best.hello.entity.UserIDOR;import com.b...

场景：布尔盲注具体原理前面的笔记写过此处略。 1、真假条件试探是否存在布尔盲注 payload： 12TrackingId=enM2J0zPN7COMcsA' AND '1'='1' -- -TrackingId=enM2J0zPN7COMcsA' AND '1'='2' -- - 2、猜测密码长度 1TrackingId=enM2J0zPN7COMcsA' AND (SELECT LENGTH(password) FROM users WHERE username='administrator')=1 -- - 不断根据and后面半句的逻辑猜测密码长度，修改1的值 (子查询)=20 注意：子查询单独当作一个值使用的时候必须用圆括号包裹。但是有一个区分的点：SQL 里，AND 的优先级低于比较运算符=，但子查询语法强制要求括号，这不是优先级，是语法硬性规定。多个 and/or 混合条件，用来改变运算先后顺序，才是优先级括号。 3、猜测密码...

1. 模式卡片（最重要）每学一个漏洞类型，记一张”模式卡”： 123456789【SQL 注入 - JDBC 拼接】特征：看到字符串拼接 SQL String sql = "select ... where id = '" + id + "'"; stmt.executeQuery(sql);数据流：参数 → 字符串拼接 → executeQuery结论：有漏洞修复：用 PreparedStatement + ? 占位 2. 危险函数清单记一张表，不断往里加： 123456| 漏洞类型 | 危险函数（Sink） | 项目中哪个文件出现过 ||---------|------------------------|------------------|| SQL 注入 | executeQuery() | SQLI/JDBC.java || SQL 注入 | queryForMap() | SQLI/JDBC.java || 命令执行 | Runtim...

场景一、orderby和联合查询注入的组合portswigger靶场sql注入第三题。这里是orderby和联合查询注入的组合。 整个流程大概是这样的： 1、'单引号测试 →确认存在注入【报语法错误】 2、order by猜列数 →得知原始查询返回 2 列 这道题是通过 ‘ order by 3 – 判断原始查询有多少列 【order by n 按查询结果的第n列排序】 UNION 联合查询有硬性规则：前后两个 select 返回的列数量必须一模一样。所以必须先测出原始 SQL 返回多少列。 3、union+常量字符串‘a’‘b’测试哪些列可以回显字符串。 在这里有两个作用：验证数据库（Oracle 需要 FROM dual 才不报错）、看页面输出确认哪些列是网页回显位（没有回显的就不是） 由上一步查出有两列，所以这里要构造的语句是： 查询1 UNION SELECT 字段1,字段2 FROM 表名 4、把想要查询的数据放到回显列，其余位置用常量占位，完成数据窃取。 1category=Gifts' UNION SELECT banner,'x&#...