2025 年发布的技术文章
查看所有标签
在上一篇文章中，我们介绍了 mockHTTPRequest 热加载函数在 MITM 代理场景下的应用——通过完全控制响应来实现“无污染”的客户端测试。今天，我们将这一能力进一步延伸到两个关键场景：
WebFuzzer 中的 Mock 响应：用于漏洞场景模拟、复现与演示
模板代码调试中的模拟响应：便于本地调试匹配器和提取器
这两个新特性共同解决了一个核心痛点：在没有真实漏洞环境的情况下，如何高效地编写、调试和演示安全检测规则？
逻辑漏洞往往隐藏在业务代码深处，传统扫描工具难以覆盖。本文以 fuint 和 forest 两个开源项目中被分配了 CVE 编号的真实漏洞为例，分享如何通过 IRify 的 SyntaxFlow 语法编写规则，快速定位 Token 伪造与未授权访问等高危逻辑漏洞。
在代码审计和安全研究中，逻辑漏洞（Logic Vulnerabilities）一直是最难攻坚的堡垒。不同于 SQL 注入或 XSS 这种有明显特征的漏洞，逻辑漏洞通常依赖于具体的业务上下文，例如权限校验缺失、关键数据被篡改等。
最近，我们在对开源项目的审计中，利用静态代码分析工具 IRify 及其查询语言 SyntaxFlow，成功发现了几个严重的安全隐患，并被分配了 CVE 编号。今天就通过这三个 CVE 案例，来聊聊如何用“代码”来找“代码中的漏洞”。
在渗透测试或者日常抓包中，很多 App/小程序/系统服务不会尊重系统代理，导致传统 HTTP/S 代理和 SSL 旁路方案很难覆盖全流量，特别是 TLS、国密或自定义协议的场景。TUN 虚拟网卡 + MITM 的透明劫持可以把“无法挂代理”的流量也收入囊中。
同时在渗透或抓包场景，单一默认代理往往不够：不同域名/网段需要不同出口或直连，认证/链式代理容易失效，临时切换又怕漏配。全局代理规则能把流量按需分流，减少失败和重传。
Yakit MITM 新增了 TUN 劫持模式，全局代理规则设置，让我们一起来看看吧
在传统的渗透测试中，我们常常在客户端与服务器之间架设窃听设备，我们拦截、观察、篡改真实的通信。这种模式有效，但存在固有缺陷：
• 状态污染 (State Contamination): 每次测试都会在服务器上留下痕迹。测试支付功能会产生订单，测试删除功能会销毁数据，测试登录会更新 last_login 时间。测试环境很快会变得“脏”，难以重置。
• 不可控的依赖 (Uncontrollable Dependencies): 后端可能不稳定，网络可能有延迟，依赖的第三方服务可能宕机。这些因素都会干扰我们对客户端行为的精确分析。
• 危险操作的顾虑 (Fear of Destructive Actions): 在测试“注销账户”、“清空数据”等功能时，我们总是束手束脚，因为一次误操作就可能导致测试账号失效，打断测试节奏。
所以我们引入了一个新的热加载函数：我们不再去完成真实的通信，而是为客户端创建一个完全受控的响应模拟器。在这个模拟器中，客户端以为它在与真实的服务器对话，但实际上它的一举一动都在我们的掌控之下，且永远不会触及真实后端。整个过程不会与后端服务器发生任何实际的网络通信，因此它非常干净、快速且安全。
最近有用户希望完全控制证书里 Subject/Issuer 的字符串，但手敲 OpenSSL 命令既枯燥又容易写错。于是我们把原本的 Yak 脚本封装成 GUI 插件：在 Yakit 的「证书生成」里，默认只露三个字段--证书类型、通用名（CN）、组织（O）。点击“额外参数”还能展开国家/省份/城市、有效期、DNS/IP 等高级选项，全部支持多值输入。最终生成的 PEM 证书和私钥自动保存到临时目录，并在界面里弹出可复制的路径，一键就能拿去用。
C 语言历经数十载发展，始终在编程语言领域占据重要地位，其设计理念深刻影响了后续众多编程语言的演进。在编写 C 语言安全规则时可以发现，其漏洞更多源于对语言本身特性的不当使用，而非网络层面的安全问题。许多著名的 CVE 漏洞都源于一些特定的编程场景：
遗憾的是，当前 IRify 对控制流的信息处理非常有限，不能像 Fortify 那样进行指针别名分析和深入的污点传播，因此像内存重复释放和空指针解引用这种需要精确控制流信息的漏洞就很难使用 Syntaxflow 规则精确定位。
目前正在做的工作是尽可能完善 C 语言的底层逻辑，让它尽可能和当前的编译逻辑相兼容。
在日常渗透测试里，WebFuzzer 已经成了各位读者最常使用的模块：发/改包、测试 Payload、复现漏洞，基本都离不开它。但对于一些特殊的场景，诸如“并发抢订单”“库存被超刷”这类必须多条请求同时冲击的场景，单个 Web-fuzzer 还是力不从心--多个标签页来回点既耗时间，也很难保持同样节奏。
为了解决这个缺口，我们把 WebFuzzer 做成“组”：一次把多个 webfuzzer 标签拉进同一个组，统一设置并发线程、重复次数、随机延迟等关键参数，最后一键发起，让不同请求同时发送。
接下来就围绕这项能力，介绍它适用的场景、靶场演示方式，以及在实际测试中如何快速上手。
之前我们发布了 IRify 性能升级的第一篇技术文档，在文中详细阐述了针对 IRify 编译后端进行的一系列基础性架构优化。通过将指令间的引用从内存指针迁移为持久化 ID，并引入 Fetch 和 Save 异步 I/O 抽象，我们成功地将编译器的核心计算逻辑与缓慢的数据库持久化操作解耦，在数据库模式下获得了约20%的显著性能提升。
然而，性能优化的征程永无止境。解决一个瓶颈，往往会使下一个瓶颈凸显出来。当后端的数据库持久化不再是主要制约因素后，我们发现，编译器前端在文件处理和 AST（抽象语法树）解析阶段的固有串行性，成为了限制编译总吞吐量的“新墙”。
本文将聚焦于我们进行的第二阶段深度优化，详细介绍如何通过构建一个高效的异步处理管道（Pipe），彻底重塑了前端编译流程，并进一步完善了后端的并发数据处理模型，以应对前端带来的数据洪流，最终将 IRify 打造成真正意义上的高并发编译引擎。
随着国家网络安全战略的深入实施，国密算法（SM2、SM3、SM4 等）在我国关键信息基础设施和重要领域得到了广泛应用，旨在构建自主可控、安全可靠的密码体系。国密 TLS（GMTLS）作为其在传输层安全协议的体现，正逐步取代传统的 RSA/ECC TLS 协议。然而，这种安全性的提升也给传统的网络分析工具，尤其是中间人（MITM）类工具带来了新的挑战。近期我们收到了部分用户咨询有关双向认证的问题，问题大致集中在：
在之前的推文中已经简单介绍了流量分析功能以及工作流程，
在“让历史流量开口说话”之后，我们更希望它能自己“做总结”。
本篇文章将带你深入了解 Yakit 流量分析功能中的两个热加载入口-- analyzeHTTPFlow 与 onAnalyzeHTTPFlowFinish 并通过真实的安全分析场景展示它们的组合威力。