这几天没咋学，接着搞搞。

学了点业务逻辑，然后尝试着挖了一下结果大败而归（悲），js绕过不会，然后自己也比较犟，想先看懂一下这个包，然后放弃再看看报告，老老实实的从边缘开始，对了，还有js接口提取的那个项目没搞。。。。自己也比较欠缺安全情报那些什么CMS通杀识别，然后组件通杀漏洞CVe的东西，之后好好的补一补，js太重要了。

以及一些旁门左道的信息收集（谷歌语法永远的神），我还得和别人学一学。。。。

怎么绕过前端校验呢？阿巴阿巴。。。

在这一步的时候不能从定向吧，就算得到了学校的ID指纹，但是它也有后续的查询和验证，要是没有后续的查询验证是不是可以直接用我的邮箱从定向改值直接变成学校的一员。

一、当前步骤无法通过前端重定向无法通过前端重定向/改值实现越权**

即便篡改前端参数，也不可能直接将你的QQ邮箱变成学校成员账号，核心原因是腾讯后端的企业归属校验是不可绕过的核心逻辑，和前端重定向、ID指纹无关：

1. 重定向的控制权不在前端

页面是否跳转、跳转到哪，取决于腾讯后端返回的响应结果（如 code:0 表示邮箱合法，才会跳转到手机号验证页； code:-1 则提示"邮箱不属于该企业"）。学校前端仅能根据后端返回的状态码执行跳转逻辑，无法自主触发重定向到学校成员的功能页面。

2. 企业ID指纹的后端强校验

学校的企业邮在腾讯系统中绑定了专属企业ID和域名白名单（仅 axhu.edu.cn 后缀邮箱属于该校），你输入的 3540372118@qq.com 是腾讯公共邮箱，后端会先校验邮箱后缀是否在学校的白名单内，直接判定为"非校内用户"，后续的ID指纹篡改、参数改值都无意义。

二、"无后续查询验证"的极端情况分析

即便腾讯后端真的缺失了"企业归属查询验证"这一步，仅靠前端改值也无法实现"变成学校一员"的实际越权：

1. 功能层面：就算前端跳转到了学校成员的重置页面，后续的手机号验证、密码重置仍需要绑定该企业的手机号，你没有对应的校内手机号，无法完成最终的重置操作；

2. 权限层面：腾讯企业邮的用户权限（如校内邮箱的收发、企业通讯录访问）是基于企业用户池分配的，你的QQ邮箱不在学校的用户池中，就算篡改参数进入页面，也无法调用任何学校成员的核心功能；

3. 数据层面：学校成员的信息存储在腾讯为该校分配的独立企业数据库中，你的QQ邮箱无法被写入该数据库，自然无法成为合法成员。

三、实操测试验证（新手可落地）

你可以通过抓包改参验证这个逻辑，步骤如下：

1. 用Burp拦截"下一步"的请求，将邮箱 3540372118@qq.com 改为 xxx@axhu.edu.cn （随便编一个校内后缀邮箱）；

2. 同时篡改请求中可能的 corp_id （企业ID）、 domain （域名）等参数为学校的标识；

3. 发送请求后，后端仍会返回"邮箱不存在"或"非企业用户"的错误，证明后端的企业归属校验是强制的。

需要我帮你整理企业邮类场景的参数篡改测试清单，包含具体要修改的参数名、测试值和验证标准吗？

那是不是新手几乎挖不了了，除非前端直接给你写信息了。

并不是新手完全挖不了，只是要避开腾讯核心后端的硬茬（如SQL注入、命令执行），聚焦学校定制层的前端和业务逻辑漏洞------这类漏洞对技术门槛要求低，新手通过基础的工具操作和逻辑分析就能发现，且是SRC中认可度较高的漏洞类型。以下是新手可落地的挖掘方向，难度从低到高排序：

一、零门槛：前端静态信息泄露（新手最易上手）

这是你提到的"前端直接写信息"的场景，也是新手最容易挖到的漏洞，仅需浏览器开发者工具就能操作：

1. 硬编码信息查找

• 操作：打开F12→ Sources 标签，搜索页面的JS/CSS文件，关键词用 phone / token / key / password / admin / bak ，甚至直接搜学校名称、邮箱后缀 axhu.edu.cn ；

• 可挖点：JS里的测试手机号、腾讯接口的测试密钥、学校管理员的测试账号等明文信息。

2. 注释泄露

• 操作：F12→ Elements 标签，查看HTML注释（ <!-- 内容 --> ）；

• 可挖点：开发人员留下的"测试账号：test@axhu.edu.cn，密码：123456""接口地址：xxx.qq.com/api，未做权限校验"等注释。

3. 静态文件泄露

• 操作：用简单的目录扫描工具（如Dirsearch，新手可直接用在线扫描工具），对 mail.axhu.edu.cn 扫描 /backup / /config / .git / .svn 等路径，或测试 readtemplate.bak / index.txt 等备份文件；

• 可挖点：学校的配置备份文件、前端开发日志，甚至包含校内邮箱列表的txt文件。

二、低门槛：前端逻辑漏洞（仅需抓包和简单分析）

这类漏洞不需要懂复杂的后端原理，只需通过抓包和页面反馈差异就能发现，是新手进阶的重点：

1. 账号枚举漏洞

• 操作：输入不同的校内邮箱（存在/不存在），观察页面提示（如"邮箱不存在"vs"验证码错误"）、返回速度（存在的邮箱可能因数据库查询，返回稍慢）；

• 可挖点：若系统对"不存在的邮箱"和"存在的邮箱"返回不同提示，就属于账号枚举漏洞（SRC中多为中低危，易收录）。

2. 敏感信息泄露（提示语漏洞）

• 操作：输入存在的邮箱，若系统返回"该邮箱绑定的手机号为138****1234"，尝试多次输入不同邮箱，看是否能通过手机号前几位/后几位枚举完整手机号；

• 可挖点：若系统未做脱敏（如直接返回完整手机号），或返回的脱敏信息能推导出完整内容，属于敏感信息泄露。

3. 验证码逻辑漏洞

• 操作：

1. 抓包查看验证码请求，测试是否能重复使用同一个验证码；

2. 输入空验证码、固定值（如0000、1234），看是否能绕过；

3. 拦截验证码校验的请求，删除 code 参数后重放；

• 可挖点：验证码可重复使用、空验证码绕过、验证码有效期过长等逻辑缺陷。

三、中门槛：集成层配置漏洞（需基础的配置知识）

学校在将腾讯企业邮与校内系统集成时，可能出现配置疏漏，新手可通过简单的配置检查发现：

1. CORS跨域配置不当

• 操作：用Burp抓包，在请求头中添加 Origin: https://baidu.com ，查看响应头是否包含 Access-Control-Allow-Origin: * 或 Access-Control-Allow-Origin: https://baidu.com ；

• 可挖点：若配置宽松，恶意网站可跨域获取该页面的用户信息，属于跨域信息泄露漏洞。

2. 域名解析/CDN配置疏漏

• 操作：用站长工具查询 mail.axhu.edu.cn 的解析记录，查看是否存在子域名劫持、CDN配置错误导致的资源泄露；

• 可挖点：若学校的子域名 test.mail.axhu.edu.cn 未绑定腾讯服务，且可被注册，属于子域名接管漏洞（SRC中多为中危）。

关键结论

新手的核心不是去碰腾讯的后端（几乎无漏洞），而是把焦点放在学校定制的前端、集成配置、业务逻辑上------这些地方的漏洞门槛低、易验证，且在SRC中被认可，完全是新手可以挖掘的范围。

需要我帮你整理新手专属的漏洞挖掘实操步骤，从打开开发者工具到提交SRC漏洞的全流程，让你能一步步跟着做吗？

一、发包的控制权：学校前端仅负责"组装/发送"，核心规则由腾讯把控

发包的动作确实由学校定制的前端页面触发，但并非由学校"管理"发包的核心逻辑，具体分工：

1. 学校前端的职责：

• 组装请求参数（如把你输入的邮箱、验证码拼接成请求体）；

• 触发发包动作（点击"下一步"时调用JS的 fetch / axios 发送请求）；

• 做简单的前端校验（如邮箱格式、验证码长度）。

但发包的目标接口、参数命名规则、请求头要求（如腾讯的鉴权 Token 、 Referer 限制）都是腾讯预先定义的，学校前端只能按规则来，无法修改。

2. 腾讯的控制权：

• 所有请求最终都会转发到腾讯的后端接口（如 weixinbridge.com / exmail.qq.com ），学校服务器仅做"反向代理"或"请求转发"，不处理业务逻辑；

• 腾讯会对请求做鉴权（如校验请求头的 Origin 是否为学校备案域名、参数签名是否合法），非法请求会直接拦截。

二、前后端分工：前端是学校定制的"外壳"，后端是腾讯的"核心"

• 学校的前端：仅为视觉交互层，包括页面样式、表单布局、简单的前端校验、域名映射（ mail.axhu.edu.cn ），相当于给腾讯的企业邮服务套了一个"学校风格的外壳"。

• 腾讯的后端：掌控所有核心业务逻辑，包括账号校验、数据库查询、手机号检索、重置流程处理、验证码生成/校验，学校无法触碰这部分代码和数据。

三、学校的角色：并非只"买接口"，是采购腾讯企业邮的SaaS服务+定制化部署

学校不只是购买单一接口，而是采购了腾讯企业邮的整体SaaS服务，具体合作内容包括：

1. 获得腾讯企业邮的服务使用权（如校内邮箱开通、账号管理、找回功能）；

2. 享有腾讯提供的品牌定制权限（修改前端样式、绑定学校域名）；

3. 腾讯提供接口对接支持（如与学校的统一身份认证系统做简单集成）；

4. 学校负责校内用户的分配、基础管理（如新增/注销校内邮箱账号），但核心的账号安全、找回逻辑仍由腾讯负责。

需要我帮你梳理该场景下的SRC漏洞挖掘优先级清单，让你能聚焦高价值的测试点（前端逻辑漏洞），避免无效测试吗？

腾讯好像是一个用户，一段时间只能请求15次，这样的话感觉只能用大批量的账号不断的试了，又是脚本。

线程。。。。

宏，也是获取前端的令牌。

那种验证码，就是图片验证码发包之类的，我感觉是它是在后端生成，然后显示在前端，由后端校验的。

空值（空字符串 "" 、参数缺失）和 null 本质不是同一个东西，但在部分编程语言/后端框架的强制类型转换下，二者可能会被等价处理为 0 ，这就是你测试时"空值反而生效"的核心原因，具体拆解如下：

一、核心概念区分

类型 定义 典型场景（Burp改参）

空字符串 "" 有参数，但值为空 把 check=1 改为 check=

null 无值（参数不存在/值为空） 直接删除 check 参数；传 check=null

0 明确的数值类型 传 check=0

三者本身是不同的，但后端的类型转换/校验逻辑会让它们产生关联。

二、为什么空值会被当成 0 ？（语言级的强制转换）

WEB后端常用的 PHP/Java/Python 对空值的处理规则不同，其中PHP的转换规则是导致"空值=0"的最常见场景：

1. PHP 场景（最易触发）

• 空字符串 "" 强制转为 int 类型时，结果是 0 ： (int)"" → 0 ；

• null 强制转为 int 类型时，结果也是 0 ： (int)null → 0 ；

• 若后端逻辑是 if ($check == 0) { 执行正确逻辑 } ，那么传 check= （空字符串）、删参数（ null ）、传 check=0 都会匹配这个条件，表现为"空值生效"。

• 但要注意： == 是弱比较（只比值）， === 是强比较（比类型+值），若后端用 $check === 0 ，则空字符串/ null 不会匹配 0 。

2. Java 场景（较少触发）

• 空字符串 "" 直接转 int 会报 NumberFormatException 异常；

• 但如果后端用框架（如Spring）做了参数默认值处理（如 @RequestParam(defaultValue = "0") int check ），那么参数缺失（ null ）时会自动填充为 0 ，空字符串仍会报错。

3. Python 场景（几乎不触发）

• 空字符串 "" 或 None （对应 null ）转 int 都会直接报错，只有显式传 0 才会匹配数值 0 。

三、关键结论：空值≠0≠null，是后端处理让它们"等价"

1. 空字符串 "" 和 null 是不同的空状态，和数值 0 本身没有关联；

2. 只有当后端使用弱类型语言（如PHP） 且做了强制类型转换，或设置了参数默认值时，空值才会被等价处理为 0 ，从而触发正确逻辑；

3. 若后端用强类型比较（如PHP的 === 、Java的类型校验），空值和 0 不会等价，测试时就不会出现"空值生效"的情况。

需要我帮你整理不同后端语言的空值/0/null 处理对照表，方便你在测试时快速判断目标系统的逻辑吗？

Fuzz得有错误回显，或者正确的回显才可以测。

而且是你不能封，就封IP。

溯源感觉不是很难，找关键信息他访问到哪儿他干的什么事几点差不多就可以排一大半。

这个就是下个软件，然后调试一直监控AP p或者小程序。

做钓鱼网站，然后它可以重定向。

这是网站重定向漏洞，加上不合法访问。

上一期讲的就是暴力破解js的技巧。

这个让我忽然想起了我之前挖的一个，不对，应该是找到了一个东西，好像就是可以控制很大的值什么的。

让一个功能不停的做处理，然后再用他的资源。

可控。

接口乱用。

验证码一般是找网上的发送接口配置的，我*玛一直朝这个接口发，