网页爬虫网络【免费下载链接】httrackHTTrack Website Copier, copy websites to your computer (Official repository)项目地址https://gitcode.com/gh_mirrors/ht/httrack点击查看免费下载HTTrack Website Copier 每天要面对来自互联网的“敌意输入”网页 HTML、HTTP 响应头、URL、字符集标签、通配符过滤规则、sitemap 乃至 proxytrack 的缓存文件全部可能被任意构造。为了让这些纯解析逻辑在内存安全层面经受住考验项目在fuzz/目录下维护了一套基于libFuzzer的模糊测试工程——默认关闭、仅在 clang 环境下通过--enable-fuzzers开启。本文以 fuzz/README.md 为骨架结合 fuzz/Makefile.am、fuzz/run-fuzzers.sh 与 14 个 harness 源码完整讲解如何构建、运行、理解并扩展这套模糊测试体系以及每个 harness 背后的实现取舍与源码证据。一、定位为什么需要一套独立的模糊测试工程HTTrack 的爬虫引擎由两条截然不同的代码路径组成一条是吞吐整个网站的“业务路径”抓取、链接重写、索引生成另一条则是直接消费网络原始字节的解析路径——字符集/UTF-8/IDNA 编解码、HTML 实体与百分号解码器、通配符过滤器、URL 拆分器等。后者是缓冲区溢出、越界读写的高发区也是 fuzz/README.md 开篇所称的 “pure hostile-input parsers”。这些解析器大多是纯函数式的给定一段输入字节返回解码结果或改写结果没有外部 I/O 依赖因此非常适合用 libFuzzer 的LLVMFuzzerTestOneInput接口逐个包裹。仓库将二者明确隔离业务路径交给tests/下的数百个 shell 回归测试如 tests/500_configure-werror.test 这类构建校验而解析路径交给 fuzz harness。从工程组织上看这套体系有四个鲜明的设计原则默认不构建configure.ac中--enable-fuzzers默认值为no且强依赖 clang 的 libFuzzer 运行时避免干扰普通发行版构建一个输入字节、一个纯解析函数每个 harness 都极简把输入切成“选择器字节 载荷字节”交给目标函数源码级证据链每个 harness 文件头注释都注明所驱动函数及对应源文件方便审计覆盖范围语料库随发行包发布通过 configure 生成的FUZZ_CORPUS_LIST让种子文件进入 tarball配合 fuzz/check-corpus-list.sh 防止漏发。二、构建clang --enable-fuzzers的完整流程README 给出的标准构建流程如下在当前仓库根目录执行./bootstrap mkdir /var/tmp/bld-fuzz cd /var/tmp/bld-fuzz CCclang CFLAGS-fsanitizeaddress,undefined -fno-sanitize-recoverall -g -O1 \ LDFLAGS-fsanitizeaddress,undefined \ bash /path/to/httrack/configure --enable-fuzzers --disable-shared make bash /path/to/httrack/fuzz/run-fuzzers.sh fuzz 60 # 60s per target关键点逐条拆解--enable-fuzzers的硬性约束。查看 configure.ac 可知开启该选项后 configure 会先检查编译器和链接器是否支持-fsanitizefuzzer-no-linkclang 专有并在enable_shared ! no时直接报错--enable-fuzzers requires --disable-shared。原因在注释里写得很清楚clang 的静态 sanitizer 运行时会与.so链接时使用的-Wl,--no-undefined冲突。因此 fuzz 构建必须是静态链接。sanitizer 组合README 默认使用 AddressSanitizerASan加 UndefinedBehaviorSanitizerUBSan并用-fno-sanitize-recoverall让任何一次越界或未定义行为立即中止便于 libFuzzer 捕获为 crash-O1保证覆盖率插桩可读、崩溃栈可回溯。fuzz/的 automake 集成见 fuzz/Makefile.am当FUZZERS条件成立时生成 14 个noinst_PROGRAMS链接标志为-fsanitizefuzzer -static-libtool-libs并静态链接libhttrack.la因为.so里隐藏了内部符号harness 必须直接解析它们。顶层AM_CPPFLAGS加入了-DHTS_INTERNAL_BUILD、-I$(top_srcdir)/src和-I$(top_srcdir)/src/coucal让 harness 能以内部 API 身份引用htsbase.h等私有头。fuzz.h是全部 harness 的公共头只提供两样东西fuzz.h 中的fuzz_strdup()把 fuzz 输入拷贝成堆上的 NUL 结尾字符串使 ASan 能对每一次越界读报错和LLVMFuzzerTestOneInput声明。三、一键驱动run-fuzzers.sh 的两种运行模式fuzz/run-fuzzers.sh 是整个模糊测试的调度入口用法为run-fuzzers.sh build-fuzz-dir check # 确定性回放CI 冒烟 run-fuzzers.sh build-fuzz-dir [seconds] # 定时变异发现默认 20 秒/目标两种模式都使用统一的单测超时与内存上限-timeout25、-rss_limit_mb2048。check模式是-runs0的纯回放不产生任何变异只验证每个目标能在自身语料库上无 crash 无泄漏地跑通——这是 CI 冒烟的标准做法定时模式则调用-max_total_timeseconds -print_final_stats1并在崩溃时把 artifact 保留在临时工作目录里。脚本里有一段容易被忽略却非常关键的逻辑——fuzz_len_flags()按目标选择性加长输入上限fuzz_len_flags() { case $1 in fuzz-htsparse | fuzz-cachendx) echo -max_len16384 -len_control0 ;; esac }其原理脚本注释有详细解释libFuzzer 的默认长度上限从当前最大种子起步只有经过长时间无新覆盖率的阶段后才会缓慢抬高对于fuzz-htsparse这类需要超过 2048 字节输入才能触达链接改写分支的慢目标默认机制永远涨不到所需长度实测会卡在 488 字节。-len_control0直接取消长度控制、一步到位代价是放弃了 libFuzzer 对短输入预算的保护因此只对实测确实需要的两个目标启用其余目标保持默认。四、14 个 Harness 全景从代码解码器到缓存格式读取器所有 harness 源文件与fuzz.h一起列在 fuzz/Makefile.am 中。按其驱动的解析器家族可分成五组4.1 字符集、编码与 IDNA 解码器charset / codepage / idna / metafuzz-charset.c第一个输入字节在 15 个字符集名字符串中选一个utf-8、iso-8859-1/2/15、windows-1252、shift_jis、euc-jp、iso-2022-jp、gb2312、big5、euc-kr、koi8-r、utf-16、us-ascii、unknown-charset剩余字节作为载荷。它完整驱动 src/htscharset.c 的四个转换面hts_convertStringToUTF8/hts_convertStringFromUTF8双向转换、hts_convertUTF8StringToUCS4/hts_convertUCS4StringToUTF8的 UCS4 往返以及hts_readUTF8/hts_writeUTF8的逐码点读写循环。它测的是当前构建实际选择的转换后端——iconv 构建下即 iconv 的胶水层。fuzz-codepage.c与 charset 互补专门钉死内置 codepage 表详见第五节。它的标签选择机制更复杂输入首字节为0xff时从输入自身读取“第一个 NUL 前的标签 NUL 后的载荷”否则在 15 个固定标签含windows-1252、IBM850、koi8-r别名以及no-such-charset反面用例中取模选择。其注释点出hts_equalsCodepageName()的宽松匹配语义——见 src/htscharset.c 的实现windows-1252、windows1252、IBM850都会归一化命中cp1252/cp850表。fuzz-idna.c驱动hts_convertStringUTF8ToIDNA、hts_convertStringIDNAToUTF8与hts_isStringIDNA文件头注释直接标注这是 “CVE-prone lineage”punycode/IDNA 是历史 CVE 高发族系实现代码见 src/punycode.c。fuzz-meta.c驱动 src/htscharset.c 的hts_getCharsetFromMeta()——直接从攻击者提供的原始 HTML 里扫描meta字符集声明覆盖带引号、不带引号、http-equiv、content 优先等语料见 fuzz/corpus/meta/ 下的 5 个种子。4.2 URL、路径与实体解码器url / unescape / entities / filtersfuzz-url.c驱动 URL 拆分器ident_url_absolute()与路径归一化器fil_simplifie()均位于 src/htslib.c。ident_url_absolute是第一个接触原始 URL 的解析器fil_simplifie原地折叠./和../。harness 里特意把path缓冲开到size 3以容纳fil_simplifie把空路径改写为./的增长。fuzz-unescape.c驱动 src/htslib.c 的百分号解码器族——unescape_http、unescape_http_unharm两个 unharm 变体分别对应不同的净化开关、unescape_amp。输入首字节从 {1, 2, 16, 256, 8192} 中选择输出缓冲大小专门考验有界拷贝契约decode 结果不得越过bsize。fuzz-entities.c驱动 src/htsencoding.c 的hts_unescapeEntities()与hts_unescapeEntitiesWithCharset()。首字节从 {1, 2, 8, 64, 4096} 选目标缓冲大小从而同时压测截断边界目标太小时解码器必须优雅停止与正常路径。fuzz-filters.c驱动 src/htsfilters.c 的通配符过滤器。输入以第一个 NUL 切分为 pattern 和 subject 两段。它依次调用strjoker基础匹配、带大小参数的strjoker、strjokerfind以及把 pattern 前置-后经fa_strjoker走完整过滤器管线。这正是 README 提到的#148 bracket-range OOB漏洞发现地。当前实现的抗攻击核心是 src/htsfilters.c 处strjoker()委托的strjoker_bounded()——它带nsteps/depth预算通过STRJOKER_MAXSTEPS/STRJOKER_MAXDEPTH上限防 ReDoSfilters/redos-star-classes.bin、regress-classdepth-timeout.bin等种子正是为此而设。4.3 网络响应解析header / htsparse / sitemapfuzz-header.c模拟接收循环逐行喂给 HTTP 响应头解析器——首行走treatfirstline()状态行后续行走treathead()每个头字段含 cookie 解析见 src/htslib.c 及 src/htsbauth.h。它复刻了线上代码的\r剥离逻辑并额外用 16 字节小缓冲反复调用hts_header_param()让长属性值必然命中 too-long 分支一旦解析器违反“未找到或溢出”契约就abort()。fuzz-htsparse.c最重量级的 harness——它不测单个函数而是用 mock 引擎搭建最小爬取状态后把整页 HTML 走一遍真实的htsparse()主解析器含链接改写。首字节从 {NULL, , iso-8859-1, utf-8, shift_jis, windows-1252, iso-2022-jp, big5, koi8-r} 选页面声明字符集其中NULL对应关闭转换-%T0、对应未声明解析器按 iso-8859-1 猜测。源码注释强调str/stre的字段接线镜像了 src/htscore.c 中htsparse()的真实调用点若这些结构体新增了解析器要读的字段必须同步更新此 harness。输入缓冲按size 1分配专门利用“解析器越过末尾读到 NUL 上”的 ASan 防护语义。fuzz-sitemap.c驱动 src/htssitemap.c 的hts_sitemap_scan()直接喂原始 XML、gzip 帧体与截断流首字节从 {0, 1, 16, HTS_SITEMAP_MAX_URLS_DOC} 选 URL 数量上限覆盖容量边界。4.4 单文件模式重写器singlefilefuzz-singlefile.c驱动--single-file模式的singlefile_rewrite_html()src/htssinglefile.c。它是最“工程化”的 harness初始化时在 TMPDIR 下搭一棵私有资源树a.png、超限的big.png、j.js、带标记的s.css/sub/b.css使 HTML 的标签、CSSurl()/import、srcset解析与内联一半MIME 猜测、base64、嵌套样式表递归全部触达而不会碰磁盘上其他任何东西。输入中的\x01ref\x02转义会被展开成真实标记mark secret 按 httrackp 每次运行绘制语料文件无法预写这是语料能触达标记解析器的唯一途径。4.5 proxytrack 缓存格式读取器cachendx / arc这两个 harness 不属于 libhttrack 主库而是驱动proxytracksrc/proxy/store.c的缓存读写器详见第六节。五、三个“非常规” Harness 的工程巧思README 特别点名了三个不按套路出牌的 harness它们的取舍最能体现这套工程的质量5.1 fuzz-codepage强制编译构建从未选中的代码这是最精彩的一个设计。当系统有 iconv 时src/htscharset.c 的DISABLE_ICONV宏不会定义hts_codepageToUTF8()与htscodepages.h中几百张 codepage 映射表根本不会被编译——但 Windows 和无 iconv 的发行版恰恰就靠这份内置表工作。换句话说主流的 iconv 构建天然“看不见”自己真正会发布的解码器。解决方式见 fuzz/Makefile.amfuzz_codepage_SOURCES fuzz-codepage.c fuzz.h $(top_srcdir)/src/htscharset.c fuzz_codepage_CPPFLAGS $(AM_CPPFLAGS) -DDISABLE_ICONVfuzz-codepage 在 harness 里再编译一份htscharset.c强制-DDISABLE_ICONV钉死到内置表路径。它定义了与库中副本相同的符号链接器因此解析到本地副本、永远不会拉取静态库中那份 archive 成员。README 的结论是在无 iconv 的构建上fuzz-codepage 与 fuzz-charset 覆盖的是同一份代码在 iconv 构建上则互补覆盖全部分支。5.2 fuzz-cachendx双文件输入的 legacy 格式驱动README 指出.ndx/.dat读取器已是该格式仅存的驱动者issue #1551 把-#C缓存从.ndx迁移到了 ZIP 索引上而 src/htscache.c 的cache_brstr自此没有调用者。fuzz-cachendx 因此只能直接驱动 proxytrack 的PT_AddIndex()/PT_SaveCache()src/proxy/store.c。由于加载器按长度前缀读取索引条目、再按条目中的偏移去 seek.dat两个文件都必须来自输入。其输入格式为字节 0..1 .ndx 部分的大端长度 其后 .ndx 内容 剩余 .dat 内容见 fuzz-cachendx.c 的实现且单输入上限 1 MiB。它还在mkdtemp后注册atexit清理并把 coucal 的断言日志静默掉proxytrack 的main()会安装日志处理器harness 没有 main 就必须自己装一个。5.3 fuzz-arc通过临时文件而非缓冲驱动读取器README 称 fuzz-arc 是“异类”它不像其他 harness 那样把输入直接当内存缓冲传给解析器而是把输入写进临时in.arc文件、再由PT_AddIndex()按--convert的方式驱动读取。原因在于.arc记录循环依赖对文件长度/偏移的 seek而PT_GetType()又按扩展名决定格式所以文件名必须以.arc结尾fuzz-arc.c。与 fuzz-cachendx 一样它把 src/proxy/store.c 编译进 harnessproxytrack 不链接 libhttrack而 coucal、minizip、md5 仍来自静态 libhttrack。两个 harness 的LLVMFuzzerTestOneInput都遵循同一闭环PT_New()→PT_AddIndex()→PT_SaveCache()让“读取器索引出的每个条目”再被“写入器读回去”读-写路径互相验证。六、种子语料库发布、校验与每个目标的起点语料库位于 fuzz/corpus/ 下按目标名分子目录corpus/target/总计约 60 个种子文件覆盖各家族的正常样例与回归用例。例如url/http-url.txt、relative-path.txt、regress-file-empty-path.txt、regress-long-path-abort.txtfilters/redos-star-classes.binReDoS 回归、regress-unterminated-class.bin未闭合字符类回归、filter-size.bincachendx/new-format.bin、old-format.bin、regress-overadvance.bin、regress-truncated-entry.binmeta/meta-charset.html、meta-unquoted.html、meta-truncated.html等。发布机制是这套体系的隐藏亮点automake 不展开EXTRA_DIST里的 glob所以 configure.ac 直接 globfuzz/corpus/*/*生成FUZZ_CORPUS_LIST并AC_SUBST再由 fuzz/Makefile.am 写进EXTRA_DIST——种子文件因此能随 tarball 一起发布。与之配套的校验脚本 fuzz/check-corpus-list.sh 专门对付“configure 的 glob 没有 oracle”的问题它会逐一检查语料文件必须是普通文件防止嵌套目录导致 glob 漏掉、文件名不含空白防止 make 按空格切词、不得直接放在corpus/顶层匹配不到*/*而永远无法发布、总数大于 0并在 git 可用时交叉核对“已跟踪但缺失”与“存在但未跟踪”两组集合——注释里明确记载曾有 3 个文件因此漏发。七、运行细节崩溃回放与标准输出噪音单个目标的手动运行方式README 原文fuzz/fuzz-url -max_total_time300 corpusdir fuzz/corpus/url fuzz/fuzz-url crash-file # 回放崩溃复现样本几个必须知道的运行时细节-close_fd_mask2README 特别警告——.ndx/.dat与.arc两个读取器以及写入器在遇到畸形输入时会向 stderr 打印诊断信息在 src/proxy/store.c 中。语料回放规模小无所谓但任何超过回放规模的变异运行都必须加-close_fd_mask2否则 stderr 会被刷爆、fuzz 吞吐归零。uBSan 忽略清单fuzz/ubsan-ignorelist.txt 排除了src/md5.c与src/coucal/*——MD5 与 MurmurHash3 的混合算法依赖无符号回绕这是第三方/子模块代码的既有语义豁免不能放在定义处就像 htsencoding.c 的 FNV 那样所以用 ignorelist 按源码路径排除并同时给出树内/树外两种拼写src:md5.c与src:*/md5.c。-runs0回放与check模式run-fuzzers.sh check是 CI 冒烟的标准姿势-timeout25同时守卫两种模式防止因病理输入如#501修复前的 strjoker 指数级退化拖垮整个测试套件。八、在 CI 与自测中的角色这套 fuzz 工程并不是孤立存在的它和tests/下的 shell 回归测试体系形成“变异探索 确定性回归”的双层防线。fuzz/中的回归种子regress-*命名的 bin/txt本身就是历史 crash 的最小复现样本无论何时回放都必须通过而 tests/378_line-endings.test、tests/435_local-proxytrack-cache-truncated.test 等测试则从构建与缓存语义层面与 fuzz 目标形成交叉验证。从源码结构可以推断项目对“fuzz 发现的问题”采取了纵深防御harness 驱动层发现越界 → 在 src/htsfilters.c 这类实现中加预算上限STRJOKER_MAXSTEPS/STRJOKER_MAXDEPTH→ 把复现样本固化为corpus/回归种子 → 由check-corpus-list.sh保证其进入发布 tarball。这条“发现-修复-固化-发布”的完整闭环正是这套 libFuzzer 工程最具参考价值的地方。赞分享网页爬虫网络【免费下载链接】httrackHTTrack Website Copier, copy websites to your computer (Official repository)项目地址https://gitcode.com/gh_mirrors/ht/httrack点击查看免费下载相关推荐OSS-Fuzz 中的 Go 模糊测试专家指南从 Harness 编写到 libFuzzer 驱动构建OSS Fuzz 中的 Go 模糊测试专家指南从 Harness 编写到 libFuzzer 驱动构建 本指南以 OSS Fuzz 仓库中的 fuzzing测试应用安全质量保障Nmap 仓库 libFuzzer 模糊测试实践fuzz/ 目录剖析与六个 fuzz target 深度解析Nmap 仓库 libFuzzer 模糊测试实践fuzz/ 目录剖析与六个 fuzz target 深度解析 NmapNetwork Mapper官方仓库网络安全网络漏洞扫描FlatBuffers 模糊测试指南基于 libFuzzer 的 Fuzzer 测试套件深入解析FlatBuffers 模糊测试指南基于 libFuzzer 的 Fuzzer 测试套件深入解析 本指南完整介绍 FlatBuffers 仓库中位于 test序列化跨平台编译器上一篇Tekton Pipeline Task 权威指南Step 编排、参数、Workspaces 与 Results 实战下一篇如何快速掌握GNU coreutils构建系统从configure到make的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
网页爬虫网络【免费下载链接】httrackHTTrack Website Copier, copy websites to your computer (Official repository)项目地址https://gitcode.com/gh_mirrors/ht/httrack点击查看免费下载HTTrack Website Copier 每天要面对来自互联网的“敌意输入”网页 HTML、HTTP 响应头、URL、字符集标签、通配符过滤规则、sitemap 乃至 proxytrack 的缓存文件全部可能被任意构造。为了让这些纯解析逻辑在内存安全层面经受住考验项目在fuzz/目录下维护了一套基于libFuzzer的模糊测试工程——默认关闭、仅在 clang 环境下通过--enable-fuzzers开启。本文以 fuzz/README.md 为骨架结合 fuzz/Makefile.am、fuzz/run-fuzzers.sh 与 14 个 harness 源码完整讲解如何构建、运行、理解并扩展这套模糊测试体系以及每个 harness 背后的实现取舍与源码证据。一、定位为什么需要一套独立的模糊测试工程HTTrack 的爬虫引擎由两条截然不同的代码路径组成一条是吞吐整个网站的“业务路径”抓取、链接重写、索引生成另一条则是直接消费网络原始字节的解析路径——字符集/UTF-8/IDNA 编解码、HTML 实体与百分号解码器、通配符过滤器、URL 拆分器等。后者是缓冲区溢出、越界读写的高发区也是 fuzz/README.md 开篇所称的 “pure hostile-input parsers”。这些解析器大多是纯函数式的给定一段输入字节返回解码结果或改写结果没有外部 I/O 依赖因此非常适合用 libFuzzer 的LLVMFuzzerTestOneInput接口逐个包裹。仓库将二者明确隔离业务路径交给tests/下的数百个 shell 回归测试如 tests/500_configure-werror.test 这类构建校验而解析路径交给 fuzz harness。从工程组织上看这套体系有四个鲜明的设计原则默认不构建configure.ac中--enable-fuzzers默认值为no且强依赖 clang 的 libFuzzer 运行时避免干扰普通发行版构建一个输入字节、一个纯解析函数每个 harness 都极简把输入切成“选择器字节 载荷字节”交给目标函数源码级证据链每个 harness 文件头注释都注明所驱动函数及对应源文件方便审计覆盖范围语料库随发行包发布通过 configure 生成的FUZZ_CORPUS_LIST让种子文件进入 tarball配合 fuzz/check-corpus-list.sh 防止漏发。二、构建clang --enable-fuzzers的完整流程README 给出的标准构建流程如下在当前仓库根目录执行./bootstrap mkdir /var/tmp/bld-fuzz cd /var/tmp/bld-fuzz CCclang CFLAGS-fsanitizeaddress,undefined -fno-sanitize-recoverall -g -O1 \ LDFLAGS-fsanitizeaddress,undefined \ bash /path/to/httrack/configure --enable-fuzzers --disable-shared make bash /path/to/httrack/fuzz/run-fuzzers.sh fuzz 60 # 60s per target关键点逐条拆解--enable-fuzzers的硬性约束。查看 configure.ac 可知开启该选项后 configure 会先检查编译器和链接器是否支持-fsanitizefuzzer-no-linkclang 专有并在enable_shared ! no时直接报错--enable-fuzzers requires --disable-shared。原因在注释里写得很清楚clang 的静态 sanitizer 运行时会与.so链接时使用的-Wl,--no-undefined冲突。因此 fuzz 构建必须是静态链接。sanitizer 组合README 默认使用 AddressSanitizerASan加 UndefinedBehaviorSanitizerUBSan并用-fno-sanitize-recoverall让任何一次越界或未定义行为立即中止便于 libFuzzer 捕获为 crash-O1保证覆盖率插桩可读、崩溃栈可回溯。fuzz/的 automake 集成见 fuzz/Makefile.am当FUZZERS条件成立时生成 14 个noinst_PROGRAMS链接标志为-fsanitizefuzzer -static-libtool-libs并静态链接libhttrack.la因为.so里隐藏了内部符号harness 必须直接解析它们。顶层AM_CPPFLAGS加入了-DHTS_INTERNAL_BUILD、-I$(top_srcdir)/src和-I$(top_srcdir)/src/coucal让 harness 能以内部 API 身份引用htsbase.h等私有头。fuzz.h是全部 harness 的公共头只提供两样东西fuzz.h 中的fuzz_strdup()把 fuzz 输入拷贝成堆上的 NUL 结尾字符串使 ASan 能对每一次越界读报错和LLVMFuzzerTestOneInput声明。三、一键驱动run-fuzzers.sh 的两种运行模式fuzz/run-fuzzers.sh 是整个模糊测试的调度入口用法为run-fuzzers.sh build-fuzz-dir check # 确定性回放CI 冒烟 run-fuzzers.sh build-fuzz-dir [seconds] # 定时变异发现默认 20 秒/目标两种模式都使用统一的单测超时与内存上限-timeout25、-rss_limit_mb2048。check模式是-runs0的纯回放不产生任何变异只验证每个目标能在自身语料库上无 crash 无泄漏地跑通——这是 CI 冒烟的标准做法定时模式则调用-max_total_timeseconds -print_final_stats1并在崩溃时把 artifact 保留在临时工作目录里。脚本里有一段容易被忽略却非常关键的逻辑——fuzz_len_flags()按目标选择性加长输入上限fuzz_len_flags() { case $1 in fuzz-htsparse | fuzz-cachendx) echo -max_len16384 -len_control0 ;; esac }其原理脚本注释有详细解释libFuzzer 的默认长度上限从当前最大种子起步只有经过长时间无新覆盖率的阶段后才会缓慢抬高对于fuzz-htsparse这类需要超过 2048 字节输入才能触达链接改写分支的慢目标默认机制永远涨不到所需长度实测会卡在 488 字节。-len_control0直接取消长度控制、一步到位代价是放弃了 libFuzzer 对短输入预算的保护因此只对实测确实需要的两个目标启用其余目标保持默认。四、14 个 Harness 全景从代码解码器到缓存格式读取器所有 harness 源文件与fuzz.h一起列在 fuzz/Makefile.am 中。按其驱动的解析器家族可分成五组4.1 字符集、编码与 IDNA 解码器charset / codepage / idna / metafuzz-charset.c第一个输入字节在 15 个字符集名字符串中选一个utf-8、iso-8859-1/2/15、windows-1252、shift_jis、euc-jp、iso-2022-jp、gb2312、big5、euc-kr、koi8-r、utf-16、us-ascii、unknown-charset剩余字节作为载荷。它完整驱动 src/htscharset.c 的四个转换面hts_convertStringToUTF8/hts_convertStringFromUTF8双向转换、hts_convertUTF8StringToUCS4/hts_convertUCS4StringToUTF8的 UCS4 往返以及hts_readUTF8/hts_writeUTF8的逐码点读写循环。它测的是当前构建实际选择的转换后端——iconv 构建下即 iconv 的胶水层。fuzz-codepage.c与 charset 互补专门钉死内置 codepage 表详见第五节。它的标签选择机制更复杂输入首字节为0xff时从输入自身读取“第一个 NUL 前的标签 NUL 后的载荷”否则在 15 个固定标签含windows-1252、IBM850、koi8-r别名以及no-such-charset反面用例中取模选择。其注释点出hts_equalsCodepageName()的宽松匹配语义——见 src/htscharset.c 的实现windows-1252、windows1252、IBM850都会归一化命中cp1252/cp850表。fuzz-idna.c驱动hts_convertStringUTF8ToIDNA、hts_convertStringIDNAToUTF8与hts_isStringIDNA文件头注释直接标注这是 “CVE-prone lineage”punycode/IDNA 是历史 CVE 高发族系实现代码见 src/punycode.c。fuzz-meta.c驱动 src/htscharset.c 的hts_getCharsetFromMeta()——直接从攻击者提供的原始 HTML 里扫描meta字符集声明覆盖带引号、不带引号、http-equiv、content 优先等语料见 fuzz/corpus/meta/ 下的 5 个种子。4.2 URL、路径与实体解码器url / unescape / entities / filtersfuzz-url.c驱动 URL 拆分器ident_url_absolute()与路径归一化器fil_simplifie()均位于 src/htslib.c。ident_url_absolute是第一个接触原始 URL 的解析器fil_simplifie原地折叠./和../。harness 里特意把path缓冲开到size 3以容纳fil_simplifie把空路径改写为./的增长。fuzz-unescape.c驱动 src/htslib.c 的百分号解码器族——unescape_http、unescape_http_unharm两个 unharm 变体分别对应不同的净化开关、unescape_amp。输入首字节从 {1, 2, 16, 256, 8192} 中选择输出缓冲大小专门考验有界拷贝契约decode 结果不得越过bsize。fuzz-entities.c驱动 src/htsencoding.c 的hts_unescapeEntities()与hts_unescapeEntitiesWithCharset()。首字节从 {1, 2, 8, 64, 4096} 选目标缓冲大小从而同时压测截断边界目标太小时解码器必须优雅停止与正常路径。fuzz-filters.c驱动 src/htsfilters.c 的通配符过滤器。输入以第一个 NUL 切分为 pattern 和 subject 两段。它依次调用strjoker基础匹配、带大小参数的strjoker、strjokerfind以及把 pattern 前置-后经fa_strjoker走完整过滤器管线。这正是 README 提到的#148 bracket-range OOB漏洞发现地。当前实现的抗攻击核心是 src/htsfilters.c 处strjoker()委托的strjoker_bounded()——它带nsteps/depth预算通过STRJOKER_MAXSTEPS/STRJOKER_MAXDEPTH上限防 ReDoSfilters/redos-star-classes.bin、regress-classdepth-timeout.bin等种子正是为此而设。4.3 网络响应解析header / htsparse / sitemapfuzz-header.c模拟接收循环逐行喂给 HTTP 响应头解析器——首行走treatfirstline()状态行后续行走treathead()每个头字段含 cookie 解析见 src/htslib.c 及 src/htsbauth.h。它复刻了线上代码的\r剥离逻辑并额外用 16 字节小缓冲反复调用hts_header_param()让长属性值必然命中 too-long 分支一旦解析器违反“未找到或溢出”契约就abort()。fuzz-htsparse.c最重量级的 harness——它不测单个函数而是用 mock 引擎搭建最小爬取状态后把整页 HTML 走一遍真实的htsparse()主解析器含链接改写。首字节从 {NULL, , iso-8859-1, utf-8, shift_jis, windows-1252, iso-2022-jp, big5, koi8-r} 选页面声明字符集其中NULL对应关闭转换-%T0、对应未声明解析器按 iso-8859-1 猜测。源码注释强调str/stre的字段接线镜像了 src/htscore.c 中htsparse()的真实调用点若这些结构体新增了解析器要读的字段必须同步更新此 harness。输入缓冲按size 1分配专门利用“解析器越过末尾读到 NUL 上”的 ASan 防护语义。fuzz-sitemap.c驱动 src/htssitemap.c 的hts_sitemap_scan()直接喂原始 XML、gzip 帧体与截断流首字节从 {0, 1, 16, HTS_SITEMAP_MAX_URLS_DOC} 选 URL 数量上限覆盖容量边界。4.4 单文件模式重写器singlefilefuzz-singlefile.c驱动--single-file模式的singlefile_rewrite_html()src/htssinglefile.c。它是最“工程化”的 harness初始化时在 TMPDIR 下搭一棵私有资源树a.png、超限的big.png、j.js、带标记的s.css/sub/b.css使 HTML 的标签、CSSurl()/import、srcset解析与内联一半MIME 猜测、base64、嵌套样式表递归全部触达而不会碰磁盘上其他任何东西。输入中的\x01ref\x02转义会被展开成真实标记mark secret 按 httrackp 每次运行绘制语料文件无法预写这是语料能触达标记解析器的唯一途径。4.5 proxytrack 缓存格式读取器cachendx / arc这两个 harness 不属于 libhttrack 主库而是驱动proxytracksrc/proxy/store.c的缓存读写器详见第六节。五、三个“非常规” Harness 的工程巧思README 特别点名了三个不按套路出牌的 harness它们的取舍最能体现这套工程的质量5.1 fuzz-codepage强制编译构建从未选中的代码这是最精彩的一个设计。当系统有 iconv 时src/htscharset.c 的DISABLE_ICONV宏不会定义hts_codepageToUTF8()与htscodepages.h中几百张 codepage 映射表根本不会被编译——但 Windows 和无 iconv 的发行版恰恰就靠这份内置表工作。换句话说主流的 iconv 构建天然“看不见”自己真正会发布的解码器。解决方式见 fuzz/Makefile.amfuzz_codepage_SOURCES fuzz-codepage.c fuzz.h $(top_srcdir)/src/htscharset.c fuzz_codepage_CPPFLAGS $(AM_CPPFLAGS) -DDISABLE_ICONVfuzz-codepage 在 harness 里再编译一份htscharset.c强制-DDISABLE_ICONV钉死到内置表路径。它定义了与库中副本相同的符号链接器因此解析到本地副本、永远不会拉取静态库中那份 archive 成员。README 的结论是在无 iconv 的构建上fuzz-codepage 与 fuzz-charset 覆盖的是同一份代码在 iconv 构建上则互补覆盖全部分支。5.2 fuzz-cachendx双文件输入的 legacy 格式驱动README 指出.ndx/.dat读取器已是该格式仅存的驱动者issue #1551 把-#C缓存从.ndx迁移到了 ZIP 索引上而 src/htscache.c 的cache_brstr自此没有调用者。fuzz-cachendx 因此只能直接驱动 proxytrack 的PT_AddIndex()/PT_SaveCache()src/proxy/store.c。由于加载器按长度前缀读取索引条目、再按条目中的偏移去 seek.dat两个文件都必须来自输入。其输入格式为字节 0..1 .ndx 部分的大端长度 其后 .ndx 内容 剩余 .dat 内容见 fuzz-cachendx.c 的实现且单输入上限 1 MiB。它还在mkdtemp后注册atexit清理并把 coucal 的断言日志静默掉proxytrack 的main()会安装日志处理器harness 没有 main 就必须自己装一个。5.3 fuzz-arc通过临时文件而非缓冲驱动读取器README 称 fuzz-arc 是“异类”它不像其他 harness 那样把输入直接当内存缓冲传给解析器而是把输入写进临时in.arc文件、再由PT_AddIndex()按--convert的方式驱动读取。原因在于.arc记录循环依赖对文件长度/偏移的 seek而PT_GetType()又按扩展名决定格式所以文件名必须以.arc结尾fuzz-arc.c。与 fuzz-cachendx 一样它把 src/proxy/store.c 编译进 harnessproxytrack 不链接 libhttrack而 coucal、minizip、md5 仍来自静态 libhttrack。两个 harness 的LLVMFuzzerTestOneInput都遵循同一闭环PT_New()→PT_AddIndex()→PT_SaveCache()让“读取器索引出的每个条目”再被“写入器读回去”读-写路径互相验证。六、种子语料库发布、校验与每个目标的起点语料库位于 fuzz/corpus/ 下按目标名分子目录corpus/target/总计约 60 个种子文件覆盖各家族的正常样例与回归用例。例如url/http-url.txt、relative-path.txt、regress-file-empty-path.txt、regress-long-path-abort.txtfilters/redos-star-classes.binReDoS 回归、regress-unterminated-class.bin未闭合字符类回归、filter-size.bincachendx/new-format.bin、old-format.bin、regress-overadvance.bin、regress-truncated-entry.binmeta/meta-charset.html、meta-unquoted.html、meta-truncated.html等。发布机制是这套体系的隐藏亮点automake 不展开EXTRA_DIST里的 glob所以 configure.ac 直接 globfuzz/corpus/*/*生成FUZZ_CORPUS_LIST并AC_SUBST再由 fuzz/Makefile.am 写进EXTRA_DIST——种子文件因此能随 tarball 一起发布。与之配套的校验脚本 fuzz/check-corpus-list.sh 专门对付“configure 的 glob 没有 oracle”的问题它会逐一检查语料文件必须是普通文件防止嵌套目录导致 glob 漏掉、文件名不含空白防止 make 按空格切词、不得直接放在corpus/顶层匹配不到*/*而永远无法发布、总数大于 0并在 git 可用时交叉核对“已跟踪但缺失”与“存在但未跟踪”两组集合——注释里明确记载曾有 3 个文件因此漏发。七、运行细节崩溃回放与标准输出噪音单个目标的手动运行方式README 原文fuzz/fuzz-url -max_total_time300 corpusdir fuzz/corpus/url fuzz/fuzz-url crash-file # 回放崩溃复现样本几个必须知道的运行时细节-close_fd_mask2README 特别警告——.ndx/.dat与.arc两个读取器以及写入器在遇到畸形输入时会向 stderr 打印诊断信息在 src/proxy/store.c 中。语料回放规模小无所谓但任何超过回放规模的变异运行都必须加-close_fd_mask2否则 stderr 会被刷爆、fuzz 吞吐归零。uBSan 忽略清单fuzz/ubsan-ignorelist.txt 排除了src/md5.c与src/coucal/*——MD5 与 MurmurHash3 的混合算法依赖无符号回绕这是第三方/子模块代码的既有语义豁免不能放在定义处就像 htsencoding.c 的 FNV 那样所以用 ignorelist 按源码路径排除并同时给出树内/树外两种拼写src:md5.c与src:*/md5.c。-runs0回放与check模式run-fuzzers.sh check是 CI 冒烟的标准姿势-timeout25同时守卫两种模式防止因病理输入如#501修复前的 strjoker 指数级退化拖垮整个测试套件。八、在 CI 与自测中的角色这套 fuzz 工程并不是孤立存在的它和tests/下的 shell 回归测试体系形成“变异探索 确定性回归”的双层防线。fuzz/中的回归种子regress-*命名的 bin/txt本身就是历史 crash 的最小复现样本无论何时回放都必须通过而 tests/378_line-endings.test、tests/435_local-proxytrack-cache-truncated.test 等测试则从构建与缓存语义层面与 fuzz 目标形成交叉验证。从源码结构可以推断项目对“fuzz 发现的问题”采取了纵深防御harness 驱动层发现越界 → 在 src/htsfilters.c 这类实现中加预算上限STRJOKER_MAXSTEPS/STRJOKER_MAXDEPTH→ 把复现样本固化为corpus/回归种子 → 由check-corpus-list.sh保证其进入发布 tarball。这条“发现-修复-固化-发布”的完整闭环正是这套 libFuzzer 工程最具参考价值的地方。赞分享网页爬虫网络【免费下载链接】httrackHTTrack Website Copier, copy websites to your computer (Official repository)项目地址https://gitcode.com/gh_mirrors/ht/httrack点击查看免费下载相关推荐OSS-Fuzz 中的 Go 模糊测试专家指南从 Harness 编写到 libFuzzer 驱动构建OSS Fuzz 中的 Go 模糊测试专家指南从 Harness 编写到 libFuzzer 驱动构建 本指南以 OSS Fuzz 仓库中的 fuzzing测试应用安全质量保障Nmap 仓库 libFuzzer 模糊测试实践fuzz/ 目录剖析与六个 fuzz target 深度解析Nmap 仓库 libFuzzer 模糊测试实践fuzz/ 目录剖析与六个 fuzz target 深度解析 NmapNetwork Mapper官方仓库网络安全网络漏洞扫描FlatBuffers 模糊测试指南基于 libFuzzer 的 Fuzzer 测试套件深入解析FlatBuffers 模糊测试指南基于 libFuzzer 的 Fuzzer 测试套件深入解析 本指南完整介绍 FlatBuffers 仓库中位于 test序列化跨平台编译器上一篇Tekton Pipeline Task 权威指南Step 编排、参数、Workspaces 与 Results 实战下一篇如何快速掌握GNU coreutils构建系统从configure到make的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
