1. 项目概述为什么我们需要自己的Fuzz工具每次看到安全测试的朋友打开Burp Suite熟练地切换到Intruder模块加载一个庞大的字典开始“突突突”我就在想这确实是高效。但有时候面对一些特殊的场景比如目标有奇怪的WAF规则、需要对参数进行极其定制化的编码、或者只是想快速验证一个简单的猜想打开一个重型工具反而显得有点“杀鸡用牛刀”。更关键的是如果你不理解工具背后“突突突”的原理你其实只是在执行一个黑盒操作一旦遇到工具处理不了的情况很容易就卡壳了。这就是为什么我觉得每一个对Web安全感兴趣的朋友都应该尝试亲手用Python写一个简单的参数Fuzz脚本。这绝不是为了替代Burp Suite这样的神器而是为了理解自动化测试的底层逻辑培养一种“自己动手丰衣足食”的脚本能力。当你自己写过一个Fuzz脚本后你会对HTTP请求、响应处理、并发控制、异常处理有更深刻的理解。下次再遇到Burp跑起来不顺手的情况你脑子里能立刻蹦出三五种用脚本解决的思路。这个项目就是带你从零开始用Python构建一个轻量级但功能完整的Web参数Fuzz脚本。我们会从最基础的单个请求发送讲起逐步加入字典读取、多线程并发、结果过滤等核心功能。最后我还会分享一个我维护的、针对不同场景分类的GitHub字典库让你可以直接“抄作业”并快速上手。整个过程你会发现用几十行代码就能实现一个可用的工具这种掌控感是单纯使用图形化工具无法比拟的。2. 核心思路与工具选型为什么是Python Requests在开始敲代码之前我们先聊聊技术选型。为什么选择Python和Requests库作为我们的基石这背后有非常实际的考量。2.1 语言选择Python的绝对优势在安全领域Python几乎是“胶水语言”的代名词。其语法简洁库生态丰富特别适合快速实现原型和自动化任务。对于Fuzz测试这种需要大量I/O操作网络请求、文件读取和文本处理解析响应的场景Python的开发效率极高。你不需要像用C/C那样操心内存管理也不像Java那样需要复杂的项目结构几行代码就能看到效果这对于学习和快速迭代至关重要。2.2 HTTP客户端库为何是Requests而非urllibPython标准库里有urllib但几乎所有从业者都会首选第三方库Requests。原因很简单“人类友好”。Requests的API设计极其直观让发送HTTP请求变得像说话一样简单。对比一下用urllib可能需要多行代码来设置请求头和处理异常而Requests通常一行requests.get(url)就搞定了。在Fuzz脚本中我们需要频繁地构建和发送请求代码的清晰度和可维护性直接决定了脚本的调试效率。2.3 辅助库规划除了Requests我们还会用到几个核心库concurrent.futures 这是Python标准库中的模块用于实现线程池或进程池是我们实现并发Fuzz的关键。它比手动管理线程更安全、更高效。argparse 用于解析命令行参数让我们的脚本能像专业工具一样接受外部输入比如指定目标URL、字典文件、线程数等。colorama可选 用于在终端输出彩色文字高亮显示成功或错误信息提升结果的可读性。这不是必须的但能极大改善使用体验。2.4 与Burp Suite的定位差异必须再次强调我们造这个“轮子”不是为了挑战Burp Suite。Burp是一个集成化的测试平台包含代理、爬虫、扫描器、插件生态等其强大和全面性无可替代。我们的脚本定位是“轻量、定制、学习”。轻量 无需安装JAVA环境一个Python脚本加一个字典文件就能运行随时随地可以修改。定制 你可以轻松修改代码实现Burp Intruder可能需要配置半天的功能比如对每个Payload进行特定的哈希、加密或嵌套编码。学习 理解每一个环节从网络请求到结果判断全部透明可控。3. 脚本核心功能拆解与实现接下来我们一步步把脚本搭建起来。我会先给出代码片段然后详细解释每一部分的作用和设计理由。3.1 基础请求框架发送单个探测请求任何Fuzz脚本的起点都是能够正确发送一个HTTP请求并获取响应。我们先构建这个最核心的函数。import requests import sys def send_request(url, paramsNone, headersNone, methodGET, timeout5): 发送HTTP请求的核心函数。 :param url: 目标URL :param params: GET请求的查询参数字典 :param headers: 请求头字典 :param method: 请求方法GET 或 POST :param timeout: 请求超时时间秒 :return: 响应对象 (requests.Response) 或 None (如果失败) try: if method.upper() GET: response requests.get(url, paramsparams, headersheaders, timeouttimeout) elif method.upper() POST: # 注意POST请求通常使用data或json参数传递主体数据。 # 这里为简化假设params以表单形式提交。实际可根据需要调整。 response requests.post(url, dataparams, headersheaders, timeouttimeout) else: print(f[!] 不支持的请求方法: {method}) return None return response except requests.exceptions.Timeout: print(f[!] 请求超时: {url}) return None except requests.exceptions.ConnectionError: print(f[!] 连接错误: {url}) return None except requests.exceptions.RequestException as e: print(f[!] 请求发生异常: {e}) return None # 示例用法 if __name__ __main__: test_url http://example.com/search test_params {q: test} test_headers {User-Agent: MyFuzzer/1.0} resp send_request(test_url, paramstest_params, headerstest_headers, methodGET) if resp is not None: print(f状态码: {resp.status_code}) print(f响应长度: {len(resp.content)}) print(f响应前100字符: {resp.text[:100]})注意这里对异常进行了捕获。在网络Fuzz中超时、拒绝连接是家常便饭必须妥善处理不能让单个请求的失败导致整个脚本崩溃。timeout参数也至关重要防止脚本因某个请求卡住而无限等待。3.2 字典管理与Payload生成Fuzz的本质就是用大量测试用例Payload去碰撞目标。一个结构良好的字典文件和处理逻辑是效率的保证。我们假设字典文件dict.txt是每行一个Payload的文本文件。def load_payloads(file_path): 从文件加载Payload字典。 :param file_path: 字典文件路径 :return: Payload列表 try: with open(file_path, r, encodingutf-8, errorsignore) as f: # 去除每行两端的空白字符并过滤掉空行 payloads [line.strip() for line in f if line.strip()] print(f[*] 已加载 {len(payloads)} 个Payload从 {file_path}) return payloads except FileNotFoundError: print(f[!] 字典文件未找到: {file_path}) sys.exit(1) except IOError as e: print(f[!] 读取字典文件错误: {e}) sys.exit(1) def generate_requests(target_url, param_name, payloads, methodGET): 根据目标URL、参数名和Payload列表生成待发送的请求数据。 :param target_url: 基础目标URL (例如: http://test.com/search.php) :param param_name: 要Fuzz的参数名 (例如: id) :param payloads: Payload列表 :param method: 请求方法 :return: 生成器每次yield一个(请求参数, payload)元组 for payload in payloads: # 构建参数字典。例如{id: payload} request_params {param_name: payload} # 如果是POST请求且需要其他固定参数可以在这里合并 # fixed_params {action: view} # request_params.update(fixed_params) yield request_params, payload实操心得使用生成器yield而不是一次性返回所有组合的列表在Payload数量极大时可以节省大量内存。脚本是边生成边发送而不是等所有组合都生成完再开始。3.3 并发引擎使用线程池提速单线程Fuzz几千个Payload会慢得无法忍受。我们必须引入并发。这里使用ThreadPoolExecutor它帮我们管理了线程池的复杂细节。from concurrent.futures import ThreadPoolExecutor, as_completed def fuzz_target(target_info, payloads, max_workers10): 并发Fuzz的主函数。 :param target_info: 字典包含目标url, param_name, method, headers等 :param payloads: Payload列表 :param max_workers: 线程池最大线程数 url target_info[url] param_name target_info[param_name] method target_info.get(method, GET) headers target_info.get(headers, {}) print(f[*] 开始对 {url} 的参数 {param_name} 进行Fuzz测试) print(f[*] 线程数: {max_workers}, 总Payload数: {len(payloads)}) # 用于收集结果的列表 results [] with ThreadPoolExecutor(max_workersmax_workers) as executor: # 提交任务到线程池 future_to_payload {} for req_params, payload in generate_requests(url, param_name, payloads, method): # 每个任务执行send_request函数 future executor.submit(send_request, url, req_params, headers, method) future_to_payload[future] payload # 处理已完成的任务 for future in as_completed(future_to_payload): payload future_to_payload[future] try: response future.result(timeout2) # 获取任务结果 if response is not None: # 这里可以调用结果分析函数 result analyze_response(response, payload) if result: # 如果分析结果认为有意义则记录 results.append(result) print(f[] 潜在发现: Payload{payload} - 状态码{response.status_code}, 长度{len(response.content)}) else: print(f[-] 请求失败: Payload{payload}) except Exception as exc: print(f[!] Payload {payload} 生成异常: {exc}) print(f[*] Fuzz完成。共发现 {len(results)} 个潜在有效结果。) return results关键参数解析max_workers最大线程数这个值不是越大越好。设置过高会导致目标服务器压力过大可能触发其防护机制导致IP被禁。本地网络和CPU资源竞争加剧整体速度可能不升反降。大量线程切换带来额外开销。经验值通常设置在10-50之间。对于内网测试或容忍度高的目标可以设高一些如30。对于公网未知目标建议从5-10开始谨慎试探。我们的脚本将其作为可配置参数。3.4 结果智能过滤从海量响应中找“金子”发送请求容易难的是如何从成千上万个响应中快速识别出有价值的那个。Burp Intruder有差异比对功能我们的脚本也要实现类似逻辑。def analyze_response(response, payload, baseline_responseNone): 分析单个响应判断是否与基线响应有“显著”差异。 :param response: 当前请求的响应对象 :param payload: 当前使用的Payload :param baseline_response: 基线响应对象例如使用一个正常参数请求的响应 :return: 如果发现差异返回一个包含信息的字典否则返回None。 # 如果没有提供基线则只根据简单规则判断例如状态码非200/404或长度异常 if baseline_response is None: if response.status_code not in [200, 404, 403]: # 常见的“正常”状态码 return {payload: payload, reason: f异常状态码: {response.status_code}, response: response} # 可以添加更多启发式规则例如检查响应内容中是否包含特定错误关键词 error_keywords [error, exception, sql, syntax] if any(keyword in response.text.lower() for keyword in error_keywords): return {payload: payload, reason: 响应包含错误关键词, response: response} return None else: # 与基线响应进行比对 reasons [] # 1. 状态码差异 if response.status_code ! baseline_response.status_code: reasons.append(f状态码变化: {baseline_response.status_code} - {response.status_code}) # 2. 响应体长度差异超过10% baseline_len len(baseline_response.content) current_len len(response.content) if baseline_len 0: change_ratio abs(current_len - baseline_len) / baseline_len if change_ratio 0.1: # 长度变化超过10% reasons.append(f长度变化: {baseline_len} - {current_len} (变化率: {change_ratio:.1%})) # 3. 响应时间差异可选需要记录时间 # 4. 特定关键词出现/消失可根据需要定制 if reasons: return {payload: payload, reason: ; .join(reasons), response: response} return None注意事项基线响应baseline_response的获取非常关键。通常你需要先向目标发送一个使用“正常”或“空”参数的请求将得到的响应作为基线。所有后续Fuzz请求的响应都将与此基线对比。这种对比能有效过滤掉大量返回相同“正常页面”或“统一错误页”的请求精准定位那些因Payload不同而产生差异的响应这些往往就是漏洞的蛛丝马迹。4. 脚本集成与实战演示现在我们把上面的模块组装起来并加上命令行参数解析形成一个完整的、可执行的脚本。#!/usr/bin/env python3 Simple Web Parameter Fuzzer Author: Your Name import argparse import requests from concurrent.futures import ThreadPoolExecutor, as_completed import sys # 这里插入上面定义的所有函数send_request, load_payloads, generate_requests, fuzz_target, analyze_response def main(): parser argparse.ArgumentParser(description简易Web参数Fuzz脚本) parser.add_argument(-u, --url, requiredTrue, help目标URL (例如: http://example.com/search.php)) parser.add_argument(-p, --param, requiredTrue, help要Fuzz的参数名 (例如: id)) parser.add_argument(-w, --wordlist, requiredTrue, helpPayload字典文件路径) parser.add_argument(-t, --threads, typeint, default10, help并发线程数 (默认: 10)) parser.add_argument(-m, --method, defaultGET, choices[GET, POST], helpHTTP请求方法 (默认: GET)) parser.add_argument(--proxy, help设置代理 (例如: http://127.0.0.1:8080)) args parser.parse_args() # 设置代理方便与Burp等工具联动调试 if args.proxy: proxies {http: args.proxy, https: args.proxy} requests.proxies.update(proxies) print(f[*] 已设置代理: {args.proxy}) # 加载字典 payloads load_payloads(args.wordlist) if not payloads: print([!] 字典为空退出。) sys.exit(1) # 准备目标信息 target_info { url: args.url, param_name: args.param, method: args.method, headers: { User-Agent: MyPythonFuzzer/1.0, # 可以根据需要添加其他头部如Cookie } } # 可选获取基线响应 baseline_resp None try: print(f[*] 正在获取基线响应...) # 使用一个明显“正常”或“空”的值请求一次 baseline_params {args.param: 1} # 或者用 test, 100 等 baseline_resp send_request(args.url, paramsbaseline_params, headerstarget_info[headers], methodargs.method) if baseline_resp: print(f[*] 基线响应状态码: {baseline_resp.status_code}, 长度: {len(baseline_resp.content)}) else: print([!] 无法获取基线响应将使用简单规则过滤。) except Exception as e: print(f[!] 获取基线响应时出错: {e}) # 这里需要稍微修改一下fuzz_target函数使其能接收baseline_resp并传递给analyze_response # 为了清晰我们重写一个入口函数或者修改fuzz_target的逻辑。以下是一个调整思路 # 在fuzz_target内部调用analyze_response时传入baseline_resp。 # 由于篇幅我们假设已对fuzz_target函数做了相应修改使其接受一个baseline参数。 # 开始Fuzz results fuzz_target(target_info, payloads, args.threads) # 假设fuzz_target已集成analyze_response # 输出总结报告 if results: print(\n *50) print([*] Fuzz测试完成潜在发现总结) for idx, r in enumerate(results, 1): print(f{idx}. Payload: {r[payload]}) print(f 理由: {r[reason]}) print(f 状态码: {r[response].status_code}, 长度: {len(r[response].content)}) print(-*30) else: print(\n[*] Fuzz测试完成未发现明显异常。) if __name__ __main__: main()4.1 实战运行示例假设我们有一个疑似存在SQL注入的URLhttp://testphp.vulnweb.com/artists.php?artist1我们想Fuzzartist参数。准备字典创建一个sql_fuzz.txt文件里面包含常见的SQL注入测试Payload例如1 1 1 AND 11 1 AND 12 1 AND 11 1 AND 12 ...运行脚本python fuzzer.py -u http://testphp.vulnweb.com/artists.php -p artist -w sql_fuzz.txt -t 20 -m GET观察输出脚本会开始并发请求并将那些状态码异常非200/404、响应长度突变或包含错误关键词的请求标记为[] 潜在发现并在最后给出总结。5. GitHub字典库分享与使用建议工欲善其事必先利其器。一个好的字典是Fuzz成功的一半。我整理和维护了一个GitHub仓库里面分类存放了各种场景下的Fuzz字典你可以直接克隆使用。仓库地址示例请替换为实际可用仓库https://github.com/yourusername/awesome-fuzz-dictionaries字典分类结构awesome-fuzz-dictionaries/ ├── README.md ├── sql_injection/ │ ├── generic.txt # 通用SQL注入探测 │ ├── error_based.txt # 报错型注入Payload │ └── time_blind.txt # 时间盲注Payload ├── xss/ │ ├── basic.txt # 基础XSS向量 │ ├── svg_xss.txt # SVG格式XSS │ └── polyglot.txt # 多上下文通杀XSS ├── path_traversal/ │ ├── unix_paths.txt # Linux/Unix路径遍历 │ └── windows_paths.txt # Windows路径遍历 ├── command_injection/ │ └── commands.txt # 系统命令注入分隔符与命令 ├── fuzz_dB/ │ └── big.txt # 大型综合字典用于目录/参数名爆破 └── templates/ └── custom_template.py # 字典生成模板脚本5.1 字典使用心法从大到小从通用到精准初次测试一个目标可以先使用fuzz_dB/big.txt这种大而全的字典进行“广撒网”快速发现哪些参数或路径存在异常。发现可疑点后再换用sql_injection/generic.txt这类精准字典进行“重点捕捞”。理解Payload的上下文不要盲目乱用。向artist参数提交一个scriptalert(1)/script是没意义的。XSS字典用在可能是输出点的参数如name,commentSQL字典用在可能与数据库交互的参数如id,cat。动态生成与编码有些WAF或过滤机制会检查特定字符串。我们的脚本优势在于可以轻松在generate_requests函数里对Payload进行动态编码如URL编码、HTML实体编码、Base64等。你可以根据目标情况实时修改几行代码来绕过简单的过滤。维护自己的专属字典在测试过程中把那些针对特定系统、框架、CMS有效的Payload收集起来形成你自己的“武器库”。比如针对某OA系统的特殊SQL语法针对某CMS模板的注入点。5.2 脚本的扩展方向这个基础脚本是一个完美的起点你可以根据实际需求轻松扩展它支持更多请求类型增加PUT、DELETE、PATCH等方法以及JSON格式的POST数据。智能结果比对实现更复杂的差分算法不仅比长度和状态码还可以比响应内容的相似度使用difflib库。报告生成将结果自动输出为HTML或Markdown报告附带请求和响应的详细信息。与Burp联动通过--proxy参数将流量导向Burp Suite用我们的脚本生成流量用Burp的Logger、Repeater进行深度分析强强联合。速率限制与随机延迟添加--delay参数在请求间插入随机延迟避免触发速率限制。6. 常见问题与排查技巧实录在实际编写和运行这类脚本时你肯定会遇到各种问题。下面是我踩过的一些坑和解决方案。6.1 请求全部失败或超时检查网络与目标首先用浏览器或curl命令手动访问目标URL确认其可达。检查SSL证书如果目标是HTTPS且使用自签名证书Requests会报SSL错误。可以添加verifyFalse参数到requests.get/post中但会收到警告。更安全的方法是设置verify‘/path/to/cert.pem’。response requests.get(url, verifyFalse) # 忽略证书验证不安全 # 或 response requests.get(url, verify/path/to/cert.pem) # 指定证书调整超时时间对于响应慢的目标适当增加send_request函数中的timeout值比如从5秒调到10秒。6.2 脚本被目标网站封禁IP降低并发度这是首要措施。将-t参数从20降到5甚至3。添加随机延迟在send_request函数中每次请求前用time.sleep(random.uniform(0.5, 2))增加随机等待时间模拟人类操作。使用代理池这是高级技巧。可以准备一个代理IP列表在发送请求时随机选取一个。这需要修改脚本从列表读取代理并配置到requests的proxies参数中。6.3 结果太多“误报”或漏报优化基线响应确保你获取的基线响应是真正的“正常”页面。有时需要尝试多个不同的“正常值”才能找到一个稳定的基线。调整分析逻辑修改analyze_response函数中的阈值。例如将长度变化率从10%调整到20%或50%或者添加对特定响应头如Content-Type变化的检查。添加白名单如果发现某些Payload总是触发相同的、无害的错误比如一个统一的“参数无效”页面可以将这些Payload或对应的响应特征加入白名单在分析时直接跳过。6.4 字典太大导致内存占用高使用生成器正如我们在generate_requests函数中所做使用yield逐行处理字典而不是用load_payloads一次性读入所有内容。对于超大型字典几GB甚至可以边读文件边发送请求。分块处理如果必须全部加载可以考虑将字典分割成多个小文件分批运行脚本。6.5 如何调试脚本本身使用代理运行脚本时加上--proxy http://127.0.0.1:8080让流量经过Burp Suite。这样你可以清晰地看到脚本发出的每一个请求和收到的响应便于排查请求构造是否正确。打印详细信息在开发阶段可以在关键函数里添加详细的print语句比如打印出准备发送的完整URL、参数等。确认无误后再关闭这些调试信息。先测试单个请求在实现并发之前务必确保send_request函数能正确发送和接收单个请求。用一个小字典比如只有3-5个Payload进行测试确保整个逻辑链路通畅。写一个自己的Fuzz脚本最大的收获不是脚本本身而是在这个过程中建立起来的对HTTP协议、Web交互和安全测试流程的底层认知。下次当你再使用Burp Suite的Intruder时你会清楚地知道它在你点击“Start attack”后背后大概做了哪些事情这种理解能让你成为一个更主动、更强大的测试者。