尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

CodeQL 1.26 Python 分析改进深度解读:共享数据流库迁移与污点追踪能力增强

CodeQL 1.26 Python 分析改进深度解读:共享数据流库迁移与污点追踪能力增强 静态分析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点击查看免费下载本文基于仓库 change-notes/1.26/analysis-python.md 展开。该文档记录了 CodeQL 1.26 版本对 Python 语言分析的全量变更6 个安全查询迁移到共享数据流框架、多个序列化/Web/数据库/命令执行库的建模改进以及 f-string 污点追踪等新能力。读完本文你将掌握这些变更对 Python 安全分析结果的具体影响、底层数据流库的实现原理以及如何在当前仓库源码中定位、验证每一项改进。一、版本背景与变更主线CodeQL 1.26 是 Python 分析的一个重要分水岭。按文档所述The following changes in version 1.26 affect Python analysis in all applications即这些变更对所有应用场景下的 Python 分析包括 GitHub Advanced Security 的 code scanning、LGTM 等均生效。本次变更的核心主线可以概括为三条数据流引擎统一多个安全查询从各自独立的旧数据流实现迁移到共享的shared数据流与污点追踪库整体分析更稳健、更精确安全敏感库的建模扩展序列化库PyYAML、dill、pickle、marshal、Web 框架Django、Flask、数据库 APIPEP-249 系、命令执行库Fabric、Invoke以及安全相关的标准库模块均获得新建模语言级污点传播补全新增对 f-string 字符串格式化的污点追踪支持堵住了此前通过 f-string 拼接敏感数据时的传播盲区。这三条主线互相配合更统一的引擎 更完善的库模型 更细的语言构造覆盖共同构成了整体更稳健、更准确more robust and accurate的分析结果。二、六类安全查询迁移到共享数据流库2.1 受影响的查询清单文档明确列出了因底层数据流库变更而产生不同结果Different results的查询Query预期影响变更说明py/unsafe-deserialization结果发生变化底层数据流库已变更详见下文py/path-injection结果发生变化底层数据流库已变更详见下文py/command-line-injection结果发生变化底层数据流库已变更详见下文py/reflective-xss结果发生变化底层数据流库已变更详见下文py/sql-injection结果发生变化底层数据流库已变更详见下文py/code-injection结果发生变化底层数据流库已变更详见下文结果发生变化是 CodeQL 变更记录中典型的双向表述——既可能意味着更多的漏洞被检出新库模型打通了此前断掉的传播路径也可能意味着更少的误报新框架的精度控制更严格。文档特别强调CherryPy 等尚未建模的框架可能出现暂时的结果丢失a temporary loss of results这一点在迁移期属于预期内的取舍。2.2 从查询源码看迁移后的实现形态以py/unsafe-deserialization为例当前仓库中的查询位于 python/ql/src/Security/CWE-502/UnsafeDeserialization.ql。其查询体本身极简依赖关系清晰地展示了共享数据流库的接入方式import python import semmle.python.security.dataflow.UnsafeDeserializationQuery import UnsafeDeserializationFlow::PathGraph from UnsafeDeserializationFlow::PathNode source, UnsafeDeserializationFlow::PathNode sink where UnsafeDeserializationFlow::flowPath(source, sink) select sink.getNode(), source, sink, Unsafe deserialization depends on a $., source.getNode(), user-provided value关键点在于查询通过semmle.python.security.dataflow.UnsafeDeserializationQuery引入统一的数据流配置模块该模块位于 python/ql/lib/semmle/python/security/dataflow/ 目录下路径图PathGraph与flowPath谓词来自共享数据流框架这解释了文档所说底层数据流库已被改变的具体含义——查询的骨架不变但驱动它的引擎换成了统一的共享数据流实现该查询元数据中标注precision high、security-severity 9.8说明迁移后的反序列化查询仍保持高精度、严重级别漏洞的定位。其余五个查询path-injection、command-line-injection、reflective-xss、sql-injection、code-injection在仓库中的对应位置分别为python/ql/src/Security/CWE-022/PathInjection.qlpython/ql/src/Security/CWE-078/CommandInjection.qlpython/ql/src/Security/CWE-079/ReflectedXss.qlpython/ql/src/Security/CWE-089/SqlInjection.qlpython/ql/src/Security/CWE-094/CodeInjection.ql2.3 旧查询的保留文档注明已更新查询的原始版本被保留于experimental/Security-old-dataflow目录。需要指出的是在当前仓库快照中该目录已不存在可以推断随着后续版本迭代该实验性保留目录已被清理或迁移到了其他位置。如需对照旧实现可以在仓库历史版本中检索Security-old-dataflow路径。这一做法体现了 CodeQL 社区变更不破坏可复现性的工程习惯——实验性目录用于在迁移期间对照新旧结果差异。三、序列化库建模改进文档列出的四个序列化库建模改进均服务于py/unsafe-deserialization查询的精确度PyYAMLyaml.load非安全加载器等入口的污点建模增强能够识别用户可控输入流入yaml.load导致的任意代码执行dill作为 pickle 的增强变体支持函数与类对象序列化其loads/load入口被纳入反序列化漏洞建模picklepickle.loads/pickle.load等核心入口的建模改进覆盖更多参数形式与包装调用marshalmarshal.loads/marshal.load入口建模marshal虽官方不建议用于不可信数据但仍被纳入安全建模。这些库的共同特点是反序列化不可信数据可导致任意代码执行。改进建模意味着py/unsafe-deserialization能更完整地追踪外部输入 → 反序列化入口的完整链路从而在不同输入形态bytes、file-like 对象、Base64 编码串下减少漏报。四、Web 框架建模Django、Flask 与 Werkzeug MultiDict4.1 Django 与 FlaskDjango建模获得改进但文档明确标注了一个已知边界——基于类的响应处理器class-based response handlers建模目前仍不完整。这意味着 Django 的TemplateView、View子类等类视图场景中部分污点传播路径可能尚未覆盖函数式视图则获得更完整的建模。Flask建模改进覆盖请求处理、响应生成等核心链路。Flask 的request对象request.args、request.form、request.json等是 Web 安全分析中最常见的污点来源之一。在仓库中Flask 模型位于 python/ql/lib/semmle/python/frameworks/Flask.qllWerkzeug 模型位于 python/ql/lib/semmle/python/frameworks/Werkzeug.qll。4.2 Werkzeug MultiDict 支持文档新增的 Support for WerkzeugMultiDict 是本次变更的一个细节亮点。MultiDict是 Werkzeug 用于表示 HTTP 表单/查询参数的容器类型允许一个键对应多个值如?tagatagb。此前若该容器类型未被建模从request.args.getlist(tag)取出的值无法作为污点源参与后续传播本次支持补上了这一环节。仓库中对应的建模实现为 python/ql/lib/semmle/python/frameworks/Multidict.qll。可以推断其建模方式为将MultiDict及其变体如ImmutableMultiDict的读取操作get、getlist、__getitem__、迭代等声明为读取步骤从而让多值表单参数的每个值都能携带污点继续流动。五、PEP-249 数据库 API 支持5.1 覆盖的库文档宣布新增对Python Database API Specification v2.0PEP-249的完整支持首批覆盖三个库MySQLdb对应MySQL-python及mysqlclient包mysql-connector-pythonMySQL 官方连接器django.dbDjango 的数据库抽象层这一支持的意义在于统一数据库访问层建模。此前 SQL 注入类查询需要为每个数据库驱动单独建模执行入口而 PEP-249 定义了统一的Connection/Cursor接口与execute/executemany方法约定一次建模即可惠及所有遵循该规范的驱动并为后续扩展如psycopg2、sqlite3铺平道路。5.2 源码实现证据仓库中的共享建模位于 python/ql/lib/semmle/python/frameworks/PEP249.qll。其核心结构包括PEP249ModuleApiNodePEP249.qll抽象模块 API 节点标识实现了 PEP-249 的数据库模块DatabaseCursorPEP249.qll统一描述游标对象的execute/executemany/executescript等执行入口并支持在 Connection 上直接调用 execute这一非标准但常见的写法异步数据库扩展AsyncDatabaseCursor、AwaitedAsyncExecuteMethodCall等处理 asyncio 驱动的特殊执行语义SQL 需 await 后才真正执行。具体到 MySQLdbpython/ql/lib/semmle/python/frameworks/MySQLdb.qll 中的建模极其简洁class MySQLdb extends PEP249::PEP249ModuleApiNode { MySQLdb() { this API::moduleImport(MySQLdb) } }即通过API::moduleImport(MySQLdb)识别模块其余所有安全相关语义游标、执行入口、SQL 参数处理全部继承自共享的 PEP-249 模型。这正是统一建模价值的直接体现——新增一个驱动的成本从为每个入口写模型降为一行声明。该目录下还可见PyMySQL.qll、Aiomysql.qll、Peewee.qll等同类文件印证了这一建模模式在仓库中的普遍应用。六、命令执行库与标准库安全模块建模6.1 命令执行库Fabric 与 InvokeFabric自动化部署库fabric.api.run/local等接口存在命令注入风险面InvokeFabric 2.x 的底层任务执行库invoke.run等接口同理。两者的建模改进使py/command-line-injection能覆盖通过这类库间接执行 shell 命令的场景。6.2 标准库安全模块文档提到的四个标准库模块建模改进——os、popen2、platform、base64——各有关注点osos.system、os.popen、os.spawn*等命令执行/进程派生入口是命令注入分析的核心 sink 集合popen2popen2.popen2/popen3/popen4等Python 2 时代的命令执行入口建模改进保障旧代码库仍可被准确分析platformplatform.popen已废弃但存在等入口的建模base64编码/解码函数b64encode/b64decode等参与污点传播的建模——恶意输入常经 Base64 编码混淆后到达反序列化或命令执行入口此前的 TODO 注释见 TaintTrackingPrivate.qll 附近 Handle encode/decode from base64/quopri表明这类编解码传播是持续演进的方向。七、新增 f-string 污点追踪支持7.1 变更内容文档最后一条库变更Added taint tracking support for string formatting through f-strings即新增对f-string 字符串格式化的污点追踪支持。f-stringf...是 Python 3.6 的格式化语法其花括号表达式会在运行时求值。此前若污点追踪未把表达式值 → f-string 结果字符串视为传播步骤那么fSELECT * FROM users WHERE id{user_input}这类拼接将无法从user_input流向 SQL 执行入口造成py/sql-injection等查询的漏报。7.2 源码实现位置该支持的具体实现位于共享污点追踪库 python/ql/lib/semmle/python/dataflow/new/internal/TaintTrackingPrivate.qllor // f-strings nodeTo.asExpr().(Fstring).getAValue() nodeFrom.asExpr()这条规则的含义是如果nodeFrom对应的表达式是某个 f-stringFstring的值getAValue()且nodeTo是该 f-string 本身则存在一条从前者到后者的污点传播步骤。也就是说f-string 内任意插值表达式的污点会传播到整个 f-string 结果字符串随后再经由字符串运算继续流动。值得注意的是同一谓词中还包含%格式化Mod、str.format_map、字符串乘法等相邻规则说明该文件集中定义了字符串构造类传播步骤f-string 规则与它们构成互补的完整集合。八、迁移取舍与已知边界文档坦诚指出了迁移期的两个边界理解它们有助于正确解读分析结果未建模框架可能暂时丢结果共享框架已建模的库如 Django、Flask分析更准但 CherryPy 等尚未建模的 Web 框架可能出现暂时性结果缺失。这类缺口属于迁移路线图上的已知项而非永久回归。Django 类视图建模不完整基于类的响应处理器class-based response handlers仍是当前建模的薄弱点使用 Django 类视图的项目可能因此出现漏报。从仓库结构看Python 的框架建模统一收敛在 python/ql/lib/semmle/python/frameworks/ 目录该目录下还有Aiohttp.qll、Peewee.qll、PyMySQL.qll等持续扩充的模型文件读者可据此判断某个框架当前是否已被建模以及建模的成熟度。九、如何在当前仓库中定位与验证这些变更9.1 查询源码入口所有迁移后的安全查询都位于 python/ql/src/Security/ 下按 CWE 编号组织的目录中查询 ID文件路径py/unsafe-deserializationpython/ql/src/Security/CWE-502/UnsafeDeserialization.qlpy/path-injectionpython/ql/src/Security/CWE-022/PathInjection.qlpy/command-line-injectionpython/ql/src/Security/CWE-078/CommandInjection.qlpy/reflective-xsspython/ql/src/Security/CWE-079/ReflectedXss.qlpy/sql-injectionpython/ql/src/Security/CWE-089/SqlInjection.qlpy/code-injectionpython/ql/src/Security/CWE-094/CodeInjection.ql9.2 数据流库与模型库共享污点追踪实现python/ql/lib/semmle/python/dataflow/new/核心步骤见 TaintTrackingPrivate.qll框架与库模型python/ql/lib/semmle/python/frameworks/安全数据流配置模块python/ql/lib/semmle/python/security/dataflow/。9.3 运行方式这些查询以标准 CodeQL 查询的形式组织在 Python 分析套件中套件配置见 python/config 下的无扩展名文件可使用 CodeQL CLI 对 Python 数据库执行分析codeql database create db --languagepython codeql database analyze db python/ql/src/codeql-suites/python-security-and-quality.qls --formatsarif-latest --outputresults.sarif具体套件文件名以 python/config 目录实际内容为准。分析结果的差异相比 1.26 之前版本正是本文所述变更的直接体现。十、总结CodeQL 1.26 的 Python 分析变更是一次系统性的质量升级引擎层面将六类核心安全查询迁移到共享数据流框架用统一、可扩展的架构替换各自为政的旧实现模型层面大幅扩充了序列化、Web、数据库、命令执行领域的库覆盖并以 PEP-249 为锚点实现了数据库驱动的声明式建模语言层面补上了 f-string 污点传播这一长期盲区。对安全研究者而言理解这些变更的底层实现尤其是 TaintTrackingPrivate.qll 中的传播规则与 PEP249.qll 的统一建模有助于准确解读分析结果的变化并为后续版本的新库建模提供可直接参照的范本。赞分享静态分析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 1.18 JavaScript 分析改进详解数据流、污点追踪库与新安全查询CodeQL 1.18 JavaScript 分析改进详解数据流、污点追踪库与新安全查询 本篇技术指南完整解读 CodeQL 1.18 版本中 JavaScr静态分析SAST应用安全漏洞扫描代码质量CodeQL 1.26 C/C 分析改进解析查询精度调整与库级污点流模型扩展CodeQL 1.26 C/C 分析改进解析查询精度调整与库级污点流模型扩展 本文基于 CodeQL 仓库中 1.26 版本的 C/C 分析变更说明静态分析SAST应用安全漏洞扫描代码质量CodeQL Python 分析 1.24 改进解析污点追踪解包赋值、Value API 扩展与 Web 框架污点源模型CodeQL Python 分析 1.24 改进解析污点追踪解包赋值、Value API 扩展与 Web 框架污点源模型 本文基于 CodeQL 仓库中 ch静态分析SAST应用安全漏洞扫描代码质量上一篇如何优化InvSR的采样步数提升速度与画质的平衡技巧下一篇Lynis项目新增对Garden Linux操作系统的支持创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表