1. 项目概述从手动到自动化的资产安全检测在高校、企业乃至任何拥有数字化资产的机构里安全运维人员都面临着一个永恒的矛盾资产规模庞大且动态变化而已知的安全漏洞NDay却层出不穷。手动去一个个系统上测试、验证效率低下且容易遗漏尤其是在面对像GitLab代码仓库和SpringBoot应用这类广泛部署的组件时。这个项目就是针对这个痛点的一次实战演练——用Python写一个脚本自动化地对指定目标进行GitLab和SpringBoot相关NDay漏洞的批量检测。简单来说它不是一个攻击工具而是一个资产安全巡检脚本。它的核心价值在于帮助安全团队或运维人员快速梳理内网或授权范围内的资产识别出那些因为版本老旧、配置不当而暴露在已知风险下的系统。比如某个学院三年前部署的GitLab服务器是否还存在着未修复的远程命令执行漏洞各个部门自行开发的SpringBoot应用接口是否存在未授权访问风险手动去查费时费力写个脚本跑一遍结果一目了然。这个脚本适合有一定Python基础的安全爱好者、初级安全工程师或运维人员。你不需要是漏洞挖掘专家但需要对HTTP协议、常见的Web漏洞原理有基本了解更重要的是要有将重复性劳动转化为自动化流程的思维。接下来我会带你从零开始拆解这个脚本的编写思路、核心模块和避坑指南让你不仅能复现更能理解其背后的设计逻辑从而适配到你自己的实际场景中。2. 脚本整体设计与核心思路拆解写一个自动化检测脚本绝不是把几个网络请求堆砌起来那么简单。它更像是在设计一个微型的安全雷达系统需要兼顾效率、准确性、鲁棒性和安全性。盲目扫描不仅效果差还可能触发目标系统的防护机制甚至引发误报影响业务。我们的设计必须有理有据。2.1 目标分析与技术选型首先我们要明确“刷NDay”在这里的具体含义。它不是去利用0day漏洞而是针对已经公开披露、有明确PoC概念验证代码或检测方式的漏洞进行批量验证。对于GitLab和SpringBoot社区和漏洞库如NVD、CNVD中有大量相关CVE记录。我们的脚本不需要去实现复杂的漏洞利用链只需要实现漏洞存在性检测。为什么选择Python这是最务实的选择。Python拥有极其丰富的网络库如requests、aiohttp、解析库如lxml、BeautifulSoup、json和并发处理库如concurrent.futures、asyncio能够快速构建原型。其语法简洁便于聚焦在业务逻辑而非语言细节上。像Nmap这类专业工具虽然强大但定制化检测逻辑和结果处理不如Python脚本灵活。核心思路流程如下资产输入脚本需要接收一个目标列表。这可以是一个IP段如192.168.1.0/24、一个域名列表文件或是从其他资产发现系统导出的数据。服务识别对每个目标首先识别其是否开放了Web服务通常是80/443端口并初步判断是否为GitLab或SpringBoot应用。这可以通过访问特定路径如/help、/api/v4/version或分析HTTP响应头如X-GitLab-*、X-Application-Context来实现。指纹采集对于识别出的服务进行更精确的指纹采集以确定其具体版本。例如GitLab的/api/v4/version接口会返回版本信息SpringBoot的/actuator/env或/actuator/info端点如果开启也可能包含版本数据。漏洞检测根据采集到的版本信息与本地维护的漏洞库进行比对。如果版本落在受影响范围内则执行对应的无损检测PoC。例如针对某个GitLab的CVE检测脚本可能是一个特定的API请求通过分析响应内容来判断漏洞是否存在。结果输出将检测结果目标、服务类型、版本、存在的漏洞CVE编号、风险等级清晰、结构化地输出如保存为CSV文件或打印到控制台。2.2 架构设计与模块规划基于以上流程我们可以将脚本划分为几个松耦合的模块便于维护和扩展输入输出模块负责读取目标文件、解析命令行参数以及将最终结果写入文件或数据库。网络请求引擎封装HTTP请求统一处理超时、重试、代理、SSL证书验证以及请求头管理特别是User-Agent的随机化以避免被简单屏蔽。指纹识别模块包含GitLab识别器、SpringBoot识别器。每个识别器实现一套探测逻辑从响应中提取版本等关键信息。漏洞检测模块这是核心。它维护一个漏洞规则库每条规则关联一个或多个版本范围和一个检测函数。检测函数执行具体的检测逻辑。并发调度器用于管理多线程或多协程并发地对多个目标进行检测极大提升效率。日志与错误处理模块记录运行过程优雅地处理网络异常、解析错误等保证脚本不会因单个目标的问题而崩溃。注意在设计之初就必须牢记这是一个检测脚本而非渗透工具。所有检测请求应设计为无害的。例如检测未授权访问漏洞时只读取公开信息不执行任何写操作或敏感信息获取。检测命令执行漏洞时只使用如echo test、whoami且目标需在授权范围内等无害命令或者通过延时、DNS外带等盲注方式判断绝对不执行rm -rf或下载恶意软件等危险操作。3. 核心模块解析与关键技术实现接下来我们深入各个核心模块看看代码具体怎么写以及为什么要这么写。3.1 智能化的指纹识别指纹识别的准确性直接决定了后续漏洞检测的针对性。我们不能仅仅依靠端口更要分析HTTP响应。GitLab指纹识别GitLab通常有多个特征点。最直接的是访问其REST API版本接口。import requests def identify_gitlab(target_url): 识别目标是否为GitLab及其版本 :param target_url: 目标基础URL如 http://target.com :return: (is_gitlab, version) 元组 headers {User-Agent: Mozilla/5.0 (安全检测脚本)} try: # 尝试访问API版本接口 resp requests.get(f{target_url}/api/v4/version, headersheaders, timeout10, verifyFalse) if resp.status_code 200: data resp.json() version data.get(version) if version: return True, version # 备用方案检查登录页面或特定静态资源 resp requests.get(target_url, headersheaders, timeout10, verifyFalse) if GitLab in resp.text or gitlab in resp.headers.get(Server, ).lower(): # 可以尝试从页面元标签或JS变量中提取更精确版本这里返回一个标记 return True, unknown (GitLab detected) except requests.exceptions.RequestException: pass return False, None这里有几个关键点1) 设置了合理的超时和自定义UA2) 优先使用最可靠的API接口3) 准备了备用方案4) 使用verifyFalse仅为了方便演示在实际对HTTPS目标检测时应妥善处理证书验证问题或使用合法证书。SpringBoot指纹识别SpringBoot应用的识别点更多但很多依赖于Actuator端点的开启而生产环境通常会关闭或加固这些端点。def identify_springboot(target_url): 识别目标是否为SpringBoot应用 :param target_url: 目标基础URL :return: (is_springboot, clues) 元组 clues {} common_paths [ /actuator/health, # 健康检查常开放 /error, # 默认错误页面 /favicon.ico, # 特定图标 ] for path in common_paths: try: resp requests.get(f{target_url}{path}, timeout8, verifyFalse) # 分析响应状态码、Content-Type、响应体特征 if resp.status_code 200: content_type resp.headers.get(Content-Type, ) if application/json in content_type and status in resp.text: clues[actuator_health] resp.json() elif resp.status_code 404 and Whitelabel Error Page in resp.text: clues[whitelabel_error] True # 检查特定的响应头 if X-Application-Context in resp.headers: clues[app_context] resp.headers[X-Application-Context] except: continue # 综合判断 if clues: return True, clues return False, None这个函数展示了“试探性”识别的思路。通过访问多个常见路径收集线索clues最后综合判断。clues字典可以包含健康检查信息、错误页面特征等为后续可能的风险判断如Actuator未授权访问提供依据。3.2 漏洞检测规则库的设计这是脚本的“大脑”。我们需要一个结构来管理漏洞规则。一个简单的规则可以用字典或类来表示# 示例一个漏洞规则的数据结构 vuln_rule { id: CVE-2021-22205, # 漏洞编号 name: GitLab 未授权RCE, affected_components: [GitLab], affected_versions: [13.10.3, 13.11.0, 13.11.3, 14.0.0, 14.0.1], # 版本范围 severity: critical, detection_method: poc_gitlab_cve_2021_22205, # 对应的检测函数名 references: [https://about.gitlab.com/releases/2021/...] } # 版本检查函数 def check_version_affected(current_version, affected_ranges): 检查当前版本是否在受影响范围内。 :param current_version: 字符串如 13.9.2 :param affected_ranges: 列表如 [13.10.3, 13.11.0, 13.11.3] :return: Boolean # 这里需要实现一个简单的版本号解析和比较逻辑 # 可以使用 packaging.version 库需安装来精确处理 # 为简化此处展示逻辑 for range_str in affected_ranges: # 假设 range_str 是类似 13.10.3 或 13.11.0, 13.11.3 # 解析并比较... pass return False检测函数PoC的实现 检测函数是规则的具体执行者。它接收目标URL和已识别的指纹信息返回是否存在漏洞。def poc_gitlab_cve_2021_22205(target_url, fingerprint): 检测CVE-2021-22205 (GitLab 未授权RCE)。 这是一个历史漏洞其PoC涉及上传特定构造的图片文件触发。 作为无损检测我们仅验证是否存在易受攻击的端点或特征不执行任何命令。 # 实际PoC可能比较复杂。这里演示一个高度简化的、仅用于说明原理的检查。 # 真实检测可能需要多步交互或分析特定响应。 check_url f{target_url}/api/v4/some_endpoint try: resp requests.get(check_url, timeout10) # 分析响应判断是否存在漏洞特征 if resp.status_code 200 and vulnerable_indicator in resp.text: return True, 存在CVE-2021-22205漏洞特征 else: return False, 未发现明显漏洞特征 except Exception as e: return False, f检测请求失败: {e}实操心得维护一个本地漏洞规则库文件如JSON或YAML是更工程化的做法。脚本启动时加载规则库。当识别出服务版本后遍历规则库找到所有affected_components匹配且版本在affected_versions范围内的规则然后依次执行其detection_method指向的函数。这样新增漏洞只需要在规则库文件中添加一条记录并实现对应的检测函数即可符合开闭原则。3.3 高并发调度与性能优化当目标数量成百上千时串行检测是不可接受的。Python的concurrent.futures.ThreadPoolExecutor是一个简单易用的选择。from concurrent.futures import ThreadPoolExecutor, as_completed def batch_detection(target_list, max_workers20): 并发批量检测 :param target_list: 目标URL列表 :param max_workers: 最大并发线程数 results [] with ThreadPoolExecutor(max_workersmax_workers) as executor: # 提交任务 future_to_target {executor.submit(scan_single_target, target): target for target in target_list} # 处理完成的任务 for future in as_completed(future_to_target): target future_to_target[future] try: result future.result(timeout30) # 每个任务总超时 results.append((target, result)) print(f[] {target} 扫描完成: {result}) except Exception as exc: print(f[-] {target} 扫描生成异常: {exc}) results.append((target, fERROR: {exc})) return results def scan_single_target(target_url): 对单个目标执行完整的扫描流程 # 1. 指纹识别 is_gitlab, gitlab_ver identify_gitlab(target_url) is_springboot, springboot_clues identify_springboot(target_url) vuln_findings [] # 2. 根据识别结果进行漏洞检测 if is_gitlab and gitlab_ver: for rule in load_vuln_rules_for_component(GitLab): if check_version_affected(gitlab_ver, rule[affected_versions]): is_vuln, detail globals()[rule[detection_method]](target_url, {version: gitlab_ver}) if is_vuln: vuln_findings.append(f{rule[id]}: {detail}) # ... 类似处理 SpringBoot return { target: target_url, fingerprint: {gitlab: gitlab_ver, springboot: springboot_clues}, vulnerabilities: vuln_findings }关键参数解析max_workers并发线程数。并非越大越好需要根据网络带宽、目标服务器承受能力和本地系统资源来调整。通常设置在20-50之间。过大会导致大量连接超时或本地端口耗尽。future.result(timeout30)这是每个检测任务的总超时。即使单个请求超时设为10秒但一个目标可能需要多个请求识别多个漏洞检测因此需要一个更大的总超时来控制单个目标的检测时间防止某个“卡住”的目标阻塞整个队列。4. 完整实操流程与脚本组装现在我们把所有模块组合起来形成一个可以运行的脚本骨架。假设我们从一个targets.txt文件中读取目标每行一个IP或域名。#!/usr/bin/env python3 GitLab/SpringBoot 资产漏洞批量检测脚本 Author: [你的名字] 注意本脚本仅用于授权下的安全检测请勿用于非法用途。 import requests import json from concurrent.futures import ThreadPoolExecutor, as_completed from urllib.parse import urljoin import argparse import logging import sys # 禁用SSL警告仅用于测试环境生产环境应妥善处理证书 requests.packages.urllib3.disable_warnings() # 配置日志 logging.basicConfig(levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s) logger logging.getLogger(__name__) # --- 模块1: 配置与输入 --- def load_targets(file_path): with open(file_path, r) as f: return [line.strip() for line in f if line.strip() and not line.startswith(#)] def load_vuln_rules(rule_filevuln_rules.json): try: with open(rule_file, r) as f: return json.load(f) except FileNotFoundError: logger.error(f漏洞规则文件 {rule_file} 未找到请检查。) return [] # --- 模块2: 指纹识别 (函数 identify_gitlab, identify_springboot 同上此处省略) --- # [将3.1节中的 identify_gitlab 和 identify_springboot 函数复制到这里] # --- 模块3: 漏洞检测规则与函数 --- VULN_RULES [] # 将从文件加载 def check_version_affected(current_version, affected_ranges): # 简化版实际应使用 packaging.version 库 # 这里假设版本号是规范的 x.y.z if not current_version or current_version unknown: return False # 实现版本比较逻辑... pass def poc_sample_gitlab_rce(target_url, fingerprint): 示例检测函数 # 实现具体的无损检测逻辑 return False, 示例检测未发现漏洞 # --- 模块4: 单目标扫描流程 --- def scan_single_target(target_url): result { target: target_url, service: None, version: None, vulnerabilities: [] } logger.info(f开始扫描目标: {target_url}) # 1. 指纹识别 is_gitlab, gitlab_ver identify_gitlab(target_url) if is_gitlab: result[service] GitLab result[version] gitlab_ver component GitLab version_for_check gitlab_ver else: is_springboot, springboot_clues identify_springboot(target_url) if is_springboot: result[service] SpringBoot result[version] str(springboot_clues) # 线索作为版本信息 component SpringBoot version_for_check None # SpringBoot版本可能无法直接获取 else: result[service] Unknown logger.info(f{target_url} 未识别出GitLab或SpringBoot服务) return result # 2. 漏洞检测 for rule in VULN_RULES: if component in rule.get(affected_components, []): if version_for_check and check_version_affected(version_for_check, rule.get(affected_versions, [])): # 执行检测 detector_func_name rule.get(detection_method) if detector_func_name and detector_func_name in globals(): detector_func globals()[detector_func_name] is_vuln, detail detector_func(target_url, result) if is_vuln: result[vulnerabilities].append({ id: rule.get(id), name: rule.get(name), detail: detail }) return result # --- 模块5: 主函数与并发控制 --- def main(target_file, output_file, max_workers20): global VULN_RULES VULN_RULES load_vuln_rules() if not VULN_RULES: logger.error(未加载到漏洞规则退出。) return targets load_targets(target_file) if not targets: logger.error(未加载到有效目标退出。) return logger.info(f加载了 {len(targets)} 个目标开始并发扫描线程数: {max_workers}) all_results [] with ThreadPoolExecutor(max_workersmax_workers) as executor: future_to_target {executor.submit(scan_single_target, target): target for target in targets} for future in as_completed(future_to_target): target future_to_target[future] try: target_result future.result(timeout60) # 单目标总超时60秒 all_results.append(target_result) vuln_count len(target_result.get(vulnerabilities, [])) status f发现 {vuln_count} 个漏洞 if vuln_count 0 else 未发现漏洞 logger.info(f目标 {target} 扫描完成。{status}) except Exception as e: logger.error(f目标 {target} 扫描失败: {e}) all_results.append({target: target, error: str(e)}) # 输出结果 with open(output_file, w, encodingutf-8) as f: json.dump(all_results, f, indent2, ensure_asciiFalse) logger.info(f扫描完成结果已保存至 {output_file}) # 简单统计输出 vuln_targets [r for r in all_results if r.get(vulnerabilities)] print(f\n 扫描摘要 ) print(f总计扫描目标: {len(all_results)}) print(f存在漏洞的目标: {len(vuln_targets)}) for res in vuln_targets: print(f - {res[target]} ({res.get(service)}):) for vul in res.get(vulnerabilities, []): print(f * {vul[id]}: {vul[name]}) if __name__ __main__: parser argparse.ArgumentParser(descriptionGitLab/SpringBoot 资产漏洞批量检测脚本) parser.add_argument(-f, --file, requiredTrue, help目标文件路径每行一个URL/IP) parser.add_argument(-o, --output, defaultscan_results.json, help输出结果文件路径 (默认: scan_results.json)) parser.add_argument(-t, --threads, typeint, default20, help并发线程数 (默认: 20)) args parser.parse_args() main(args.file, args.output, args.threads)这是一个完整的、可运行的脚本框架。你需要做的是完善identify_gitlab和identify_springboot函数中的版本提取逻辑。实现一个健壮的check_version_affected函数建议使用packaging库。构建你的vuln_rules.json漏洞规则库文件。为规则库中的每个漏洞实现具体的无损检测函数poc_*。5. 常见问题、排查技巧与避坑指南在实际编写和运行过程中你会遇到各种各样的问题。下面是我踩过的一些坑和总结的经验。5.1 网络请求相关的问题问题1大量连接超时或拒绝连接。原因目标主机不存在、防火墙拦截、或并发数过高导致本地端口耗尽或目标服务器拒绝。排查先用ping或telnet检查目标网络可达性。降低并发线程数-t 10。在请求中增加随机延迟避免对单一IP短时间发起过多请求。检查本地是否启用了代理脚本可能无意中走了代理。在requests中可以通过设置proxies参数为None来确保直连。问题2遇到SSL证书验证错误。现象SSLError或CERTIFICATE_VERIFY_FAILED。处理对于内网或测试环境可以像示例中一样使用verifyFalse但会收到警告。更规范的做法是将目标的自签名证书添加到信任库或使用REQUESTS_CA_BUNDLE环境变量指定证书。切勿在生产脚本中全局禁用验证这会使中间人攻击成为可能。应根据目标情况动态决定。问题3被WAF或防护设备拦截。现象返回403、429请求过多状态码或返回奇怪的验证页面。应对伪装请求头使用常见的浏览器User-Agent并添加Referer、Accept-Language等头。降低请求频率在请求间增加随机延时如time.sleep(random.uniform(0.5, 2))。使用会话requests.Session()可以保持cookies使请求看起来更像一个连贯的浏览器会话。识别验证机制如果遇到验证码通常意味着你的请求已被识别为异常流量此时应停止对该目标的扫描。5.2 指纹识别与漏洞检测的误报/漏报问题4指纹识别不准确将Nginx默认页识别为SpringBoot。原因仅依靠有限的特征匹配容易误判。改进采用多特征综合判断。例如对于SpringBoot可以同时检查/actuator/health返回特定JSON、/errorWhitelabel页面、以及静态资源路径的特征。只有多个特征同时匹配时才判定。也可以尝试访问一个绝对不存在的路径观察404错误页面的特征。问题5漏洞检测函数触发误报将正常响应判断为存在漏洞。原因检测逻辑过于简单匹配规则不精确。改进深入分析漏洞原理。例如检测未授权访问时不能只因为访问/actuator/env返回200就判定漏洞存在还要检查返回的内容是否确实包含敏感信息如password、secret等关键词并且与授权访问后的内容进行对比如果可能。对于命令执行漏洞的“盲注”检测使用DNS外带或HTTP外带时要确保你的接收服务器确实收到了请求并排除网络抖动等因素。5.3 脚本性能与稳定性问题6扫描速度慢尤其是目标很多时。优化使用异步IO将concurrent.futures.ThreadPoolExecutor替换为asyncioaiohttp可以大幅提升I/O密集型任务的效率尤其是在检测逻辑需要多个顺序请求时。设置连接池requests的Session可以复用TCP连接减少握手开销。超时设置为每个请求设置合理的连接超时和读取超时如timeout(3, 10)避免在无响应的目标上浪费过多时间。问题7脚本运行中途崩溃所有结果丢失。解决增加异常捕获确保每个可能出错的地方都有try...except并将错误记录到日志而不是让整个脚本崩溃。实现结果实时保存不要等所有目标扫描完才写文件。可以每扫描完一个目标就将其结果追加到文件如JSON Lines格式或数据库中。这样即使脚本中断已完成的扫描结果也不会丢失。使用信号处理捕获KeyboardInterruptCtrlC等信号在脚本终止前优雅地保存当前状态。5.4 法律与道德边界这是最重要的一条。你必须时刻清楚自己在做什么。明确授权只扫描你拥有明确书面授权的资产。未经授权扫描他人的系统是违法行为。无损检测所有检测操作必须是“只读”的、无害的。绝对不要尝试上传文件、执行系统命令、修改数据等可能影响系统正常运行的操作除非在完全隔离的测试环境中。控制影响即使是无损检测过于频繁的请求也可能对目标服务器造成负载压力形成DoS攻击。务必控制并发数和请求频率。保护结果扫描结果可能包含敏感信息如服务器版本、内部路径。务必妥善保管不得泄露。最后这个脚本只是一个起点。你可以在此基础上扩展更多功能比如集成更强大的指纹识别库如Wappalyzer的原理、从在线漏洞库动态更新规则、生成更美观的HTML报告、或者与漏洞管理平台如OpenVAS, Nessus的API对接。安全自动化之路始于这样一个解决实际需求的小脚本成长于不断迭代和深入理解的过程中。