静态分析SAST应用安全漏洞扫描代码质量【免费下载链接】codeqlCodeQL: the libraries and queries that power security researchers around the world, as well as code scanning in GitHub Advanced Security项目地址https://gitcode.com/gh_mirrors/co/codeql点击查看免费下载CodeQL 的 C# 分析库在 5.1.3 版本中针对 ASP.NET 与 .NET 场景做了两项重要的安全分析改进一是修订System.Uri的模型以更精确地追踪受污染 URItainted URI在代码中的流动二是首次为 Blazor 父组件向子组件传递[Parameter]的过程建立数据流建模。本文以仓库中csharp/ql/lib/change-notes/released/5.1.3.md的官方变更记录为骨架深入System.model.yml与Components.qll的实现源码帮助你理解这两项改进的底层原理、实际影响以及如何利用它们编写更准确的 C# 安全查询。版本背景5.1.3 在 C# 分析库演进中的位置CodeQL 的 C# 分析库位于仓库csharp/ql/lib/目录对应 QL 包codeql-csharp通过版本化的变更记录change-notes来追踪每次发布的用户可见变化。5.1.3 的完整变更内容见 csharp/ql/lib/change-notes/released/5.1.3.md全部归入Minor Analysis Improvements次要分析改进类别The models forSystem.Urihave been modified to better model the flow of tainted URIs.Modeled parameter passing between Blazor parent and child components.与相邻版本对照见 csharp/ql/lib/CHANGELOG.md可以看到一条清晰的演进脉络5.1.0System.Net.Http.HttpRequestMessage与System.UriBuilder的模型被修改以更好建模受污染 URI 的流动Blazor[Parameter]字段若绑定到page指令路由中的变量被建模为远程流源remote flow source。5.1.3把System.Uri本体也纳入受污染 URI 建模体系同时补上 Blazor 组件间父→子参数传递这一数据流缺口。5.1.4Blazor 支持进一步改进——属性以字符串字面量而非nameof表达式指定时也能被正确识别。也就是说5.1.3 是 CodeQL 团队围绕URL/URI 污点流与Blazor 组件数据流两条主线持续加固的中间里程碑。改进一System.Uri模型的修订与受污染 URI 流动MaD 模型CodeQL 描述 .NET API 行为的方式CodeQL 使用MaDModel as Data机制以 YAML 数据行的形式描述 .NET 框架 API 的 taint、summary、sink 等行为C# 提取器的模型文件位于csharp/ql/lib/ext/与csharp/ql/lib/ext/generated/modelgenerator/下。System.Uri的手工模型集中在 csharp/ql/lib/ext/System.model.yml。5.1.3 的修订modified即针对这些数据行。一条典型的 MaD 行结构如下- [System, Uri, False, TryCreate, (System.String,System.UriCreationOptions,System.Uri), , Argument[0], Argument[2], taint, manual]其字段依次为命名空间、类型名、是否泛型、方法名、完整签名、泛型参数、输入from、输出to、流种类taint/value、来源manual表示手工维护区别于modelgenerator自动生成。5.1.3 后System.Uri的完整污染流覆盖从 System.model.yml 的当前实现看System.Uri在污染流建模上形成了闭环1. 构造函数taint 进入实例Uri(String)、Uri(String, Boolean)、Uri(String, UriKind)、Uri(String, UriCreationOptions)Argument[0]字符串源→Argument[this]新建实例taint。相对构造Uri(Uri, String)、Uri(Uri, String, Boolean)Argument[0]与Argument[1]都流向Argument[this]即基 URI 与相对路径任一方被污染组合结果即为受污染 URI。2. 工厂方法三种TryCreate重载字符串或基 URI 参数Argument[0]/Argument[1]→ 输出参数Argument[2]out 的Uritaint。即使解析失败走 out 参数污点也不会丢失。3. 属性与字符串化taint 流出实例AbsoluteUri、DnsSafeHost、LocalPath、OriginalString、PathAndQuery、Query、ToString()Argument[this]→ReturnValuetaint。由此外部输入的 URL 字符串 →new Uri(...)→uri.Query/uri.AbsoluteUri→ 拼进 SQL、重定向目标、日志或 HTTP 请求这条完整链路都能被数据流引擎追踪。这正是better model the flow of tainted URIs的落点此前若只有构造函数或只有 getter 的模型流会在中途断裂现在进、出两个方向都齐备。与之配套5.1.0 已把System.UriBuilder的各个属性Scheme、Host、Path、Query、Fragment等建模为独立的 taint 字段见 System.model.yml进一步补全了 URL 构建场景。对查询编写者的实际价值Open Redirect开放重定向uri.AbsoluteUri或uri.OriginalString直接作为Location跳转目标时污点可追溯到Request.QueryString等远程源。SSRF / 请求伪造Uri实例被用于HttpClient请求时其 Host/Path 的来源可被回溯。SQL/命令注入拼接uri.Query、uri.PathAndQuery进入字符串拼接 sink 时同样可被追踪。若要验证模型是否生效可在自己的查询中跟踪任意Uri派生值观察数据流路径是否跨越构造—访问属性的边界模型行本身也可作为自定义 MaD 扩展的参照范本。改进二Blazor 父子组件参数传递的建模问题背景组件化框架带来的数据流断层Blazor 中父组件通过RenderTreeBuilder.AddComponentParameter向子组件写入[Parameter]属性子组件内通过属性 getter 读取。这种跨组件、跨方法、经框架运行时注入的传值方式对传统过程内数据流分析是天然断层调用AddComponentParameter时值只是一个方法实参分析器并不知道它最终会落到子组件的哪个属性上。5.1.3 的改进正是为这条链补上建模。核心实现在 csharp/ql/lib/semmle/code/csharp/frameworks/microsoft/aspnetcore/Components.qll该文件被远程流源库 csharp/ql/lib/semmle/code/csharp/security/dataflow/flowsources/Remote.qll 以import ... aspnetcore.Components as Blazor的方式引用说明这套建模直接服务于远程流源与污点分析。关键实现机制拆解Components.qll通过三个层次的 QL 类协作完成建模1. 组件与属性的识别第 62-113 行MicrosoftAspNetCoreComponentsComponent凡是继承自ComponentBase或实现IComponent的类型即为 Blazor 组件。[Parameter]属性getAParameterProperty(name)只选取带MicrosoftAspNetCoreComponentsParameterAttribute的属性。路由参数getARouteParameter()从page /counter/{id:int}/{other?}/{*rest}这类路由模板中解析出id、other、rest支持:int类型约束、?可选、*catch-all再与[Parameter]属性按名称大小写不敏感匹配得到getARouteParameterProperty()。这部分在 5.1.0 已落地用于把路由绑定的参数标记为远程流源。2. 匹配OpenComponent/CloseComponent调用对第 183-208 行matchingOpenCloseComponentCalls在同一个可调用体内把RenderTreeBuilder.OpenComponentT/OpenComponent(Type)与其配对的CloseComponent按语句块内的索引匹配起来并解析出组件类型componentType从而确定这一段渲染代码打开的是哪个组件。3. 非局部跳转节点ComponentParameterJump第 210-265 行——本次改进的核心ParameterPassingCall识别RenderTreeBuilder.AddComponentParameter调用并解析出它写入的子组件属性。解析方式有两种参数名以nameof(...)表达式引用属性getAnAccess匹配或以字符串字面量给出属性名getArgument(1).(StringLiteral).getValue()匹配并校验该属性确属上面匹配到的组件类型且调用位置处于该组件的OpenComponent与CloseComponent之间。ComponentParameterJump extends DataFlow::NonLocalJumpNode把AddComponentParameter的第 3 个参数getParameterValue即传入的值作为跳转节点其getAJumpSuccessor指向子组件属性的访问点prop.getAnAccess()且preservesValue true原值保真传递。NonLocalJumpNode是 CodeQL C# 数据流库中的非局部跳转抽象专门连接那些跨越过程边界、由框架约定的隐式数据流动。ComponentParameterJump的加入让污点分析可以看穿AddComponentParameter直接建立父组件传入值 → 子组件[Parameter]属性 → 子组件内部消费点的完整数据流路径。一个可运行的实战场景// 父组件 Child TitleuserInput / // userInput 来自路由/查询参数远程源 // 子组件 Child.razor [Parameter] public string Title { get; set; } // 经 AddComponentParameter 注入 * 子组件内部 * a hrefTitleGo/a // 若直接输出构成反射型 XSS 风险在 5.1.3 之前Title的赋值来自框架内部的AddComponentParameter调用污点流在组件边界断裂5.1.3 之后userInput的污点可以沿ComponentParameterJump一路传播到a href渲染处的 sink配合 XSS 查询中的 HTML 注入 sink如MarkupString见 4.0.1 变更记录从而命中漏洞。与后续版本的衔接5.1.4见 CHANGELOG.md进一步改进属性名以字符串字面量形式传入AddComponentParameter时也能被识别——这在编译期优化后编译器以字符串常量替代nameof的场景下补上了 5.1.3 建模的最后一个匹配盲区。两版配合Blazor 组件参数链路的识别才算完整。小结变更记录如何指导查询与模型维护从 5.1.3 这份变更记录可以得到三点工程启示模型是数据流分析的地基。System.Uri的进/出双向 taint 行见 System.model.yml决定了一条跨框架边界的污染链能否被完整追踪编写安全查询前应优先核查所涉 API 的 MaD 模型覆盖。框架隐式数据流需要显式建模。Blazor 这类组件框架的运行时注入AddComponentParameter必须通过NonLocalJumpNode之类的跳转节点显式声明分析器才能跨越过程边界参见 Components.qll。版本记录即能力清单。csharp/ql/lib/CHANGELOG.md与change-notes/released/下的逐版本条目是你判断当前 CodeQL C# 分析能力边界、以及排查为什么某条流没被报出时的第一手依据。赞分享静态分析SAST应用安全漏洞扫描代码质量【免费下载链接】codeqlCodeQL: the libraries and queries that power security researchers around the world, as well as code scanning in GitHub Advanced Security项目地址https://gitcode.com/gh_mirrors/co/codeql点击查看免费下载相关推荐CodeQL C 库演进System.Text.StringBuilder 数据流与污点建模深度解析CodeQL C 库演进System.Text.StringBuilder 数据流与污点建模深度解析 导读 本文围绕 CodeQL C 库在 2021 年 4静态分析SAST应用安全漏洞扫描代码质量CodeQL C/C 库 2.0.2 分析改进解读fopen 污点流建模与 fgetc/getc 范围分析精度提升CodeQL C/C 库 2.0.2 分析改进解读fopen 污点流建模与 fgetc/getc 范围分析精度提升 导读 本文聚焦 CodeQL 仓库中静态分析SAST应用安全漏洞扫描代码质量CodeQL 1.24 C/C 分析改进全解析新查询、污点追踪库重构与库建模升级CodeQL 1.24 C/C 分析改进全解析新查询、污点追踪库重构与库建模升级 本篇指南完整梳理 CodeQL 1.24 版本针对 C/C 分析的所静态分析SAST应用安全漏洞扫描代码质量上一篇Flink DataStream 双流 Join 完全指南Window Join 与 Interval Join 实战与源码解析下一篇Data-Juicer 视频数据集路径配置指南相对路径与绝对路径在 Ray 集群中的正确使用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考