本文介绍了LICMA，一个用于检测多语言密码API误用的静态分析工具，重点研究了Python环境中加密库的误用情况。通过对GitHub上895个流行Python项目的分析，发现52.26%的项目存在加密API误用，误用率低于Java和C。LICMA利用规则和后向切片算法识别潜在和确定的误用，并对比了Python与其他语言的差异，强调了API设计对降低误用的影响。实验表明，Python的加密库设计可能有助于减少某些类型的误用，如ECB模式的使用。
本文目标：速读论文 “Python Crypto Misuses in the Wild” 。
无论是之前的 CryptoGuard 还是其他的静态工具，大部分都在研究 Java 和 C 上的密码 API 误用，针对其他语言的检测还没怎么发现，你以为只有你想得到这一点吗👻，这不就来了嘛 —— 该论文发布于 2021 年的 ESEM ，这个月刚发布没多久/(ㄒoㄒ)/~~，所以 idea 也需要抢的呀！这就马不停蹄地来研究研究，Python 有什么不一样的！
文章工作一览
- 实现了首个多语言密码误用的分析工具，并使用规则检测五个不同 Python 库以及标准 Java 库的常见误用。
◾ LICMA 实现可以在GitHub上使用。 - 分析了来自 GitHub 的895个流行的Python应用程序和51个MicroPython项目，以识别误用。
- 分析显示52.26%使用加密API的项目误用了相应的库；在1501个错误中，只有7%是在应用程序代码中。
- 分析用 MicroPython 编写的嵌入式应用程序，揭示了混合分析的重要性 —— 唯一的密码调用是在项目附带的C代码中进行的
- 文章结果与 Android应用 和 C固件镜像 比对，证实：固执的 API 设计实际上可以帮助开发人员避免误用。
- 本文的动机之一：通过实证来阐明 Python加密库 是否有助于开发人员编写更安全的代码（对比以前在 Java 或 C 中所揭示的研究）。
◾ 文章观察到Python中的误用比Java和C中发生的频率要低。
◾ ECB作为加密模式的误用在 Java 和 C 中是最常见的，而 Python 应用程序明显减少了这种用法，这种差异很可能由于 Python 库的设计而造成的。 - 未来探索：验证这些结果是否适用于其他语言，如Rust和Go。
LICMA：直接上设计！
是的，该文设计的静态工具就叫 LICMA ：
👻定规则
- 将 源代码文件 解析为各自的 抽象语法树(AST) 。
- 使用 Babelfish 创建一个 通用抽象语法树(UAST) ，即其 AST 元素与其特定语言元素结合在一起。（后文统称为AST）
- 根据 AST ，使用 LICMA 分析，以 识别 加密规则的潜在误用。
👻分析规则
- 基于上述规则，检查违规——源代码中是否存在规则违规。存在则触发后向分析，通过 XPath 过滤 AST ，创建后向切片。
- ① 后向切片算法(BSA) 识别 所有源代码行（依据切片标准，以前的文章中提到过，这可能是函数调用参数等）。
- ② BSA 确定 参数是否为“硬编码”、“局部赋值”、“全局赋值”。满足则返回相应值，根据规则中定义的函数进行检查。
- 一般步骤：查找函数调用者，检查其参数，返回分析的结果；
- 工具停止运行条件：已返回了相应值 || 没有其他需要分析的调用者。
👻LICMA 可能会检测出两种情况：
- 潜在的误用 —— 可能由于未调用而无法确定是否为严重的误用（需要人工检查以确定其是否有害）；
- 确定的误用 —— 确实使用了不安全的选项（能解析各自的加密参数）。
实验见 gap
实验使用 Python 项目、MicroPython 项目的两个数据集，它们代表了使用 Python 的两个截然不同的领域 —— 从服务器和桌面使用到底层嵌入式代码。
本文实现了 Python 和 Java 分析组件。
◾ 对于Python，涵盖 5 个不同的加密模块：cryptography、M2Crypto、PyCrypto、PyNaCl、ucryptolib。删除了已弃用的 Keyczar 模块，并添加了 MicroPython 库的 ucryptolib 。使用 JCA 定义的6条规则，但并不全部适用于 Python ，比如 Python 没有用静态种子初始化的安全随机数生成器，这与其 API 的设计有关。
代码来源： Python 项目、MicroPython 项目。
-
针对来自 GitHub 的 Python 项目。
◾ 对开源Python代码评估其密码误用。
① 爬取并下载了 GitHub 星标排名前895的 Python repositories；
② 为每个项目下载了 Python 标准依赖关系管理器 pip （在14442个 Python 包中，有3420个是唯一的）。
◾ 精简数据集并测试
① 分析工作以文件为单位，仅包含规则中含函数调用的源代码文件，例如 AES.new(…) 。
② 过滤生产代码，忽略在应用程序执行期间不存在的测试代码
═▶ 得到了946个源文件（来自155个不同的 repositories）
═▶ 发现 Babelfish 无法解析其中的 35 个文件，并且有 50 个文件至少有一个规则的 AST XPath 查询达到了最大递归深度。
这85个解析失败分布在61个不同的项目中，但每个项目又至少能解析成功一个使用了加密的文件🐾也就是说，这85个文件是确定的误用（我们认为它肯定有问题但没匹配到相应规则），其他的都是潜在的误用（可能找全了，也可能没找全）
综上，LICMA 分析了155个 Python repositories 中的861个不同文件。在被分析的155个包含加密用法的Python应用程序中，有52.26%至少有一次误用。 -
精选 Top MicroPython 项目。
◾ 对Python应用程序集评估其密码误用。
① 爬取并下载了51个 MicroPython 项目，它们被声明为最热门的 MicroPython 项目；
② 为每个项目下载了 Python 标准依赖关系管理器 pip （得到113个依赖项和1个重复依赖项）。
◾ 精简数据集并测试
同上②
这些步骤产生了 5 个文件，它们似乎使用了 LICMA 支持的 Python 加密库。
注： LICMA 和过滤步骤中包含了 MicroPython 加密库 —— ucryptolib 。
作者手动分析 MicroPython 应用程序的数据集，表示实验可能错过了五种加密用法。 -
对比其他工具
① 前面提到 JCA 定义的6条规则并不全部适用于 Python，所以排除一部分规则。
② 显式使用 ECB 模式；针对 API 设计而隐式使用此 block 模式
③ 只考虑确定的结果（CryptoLint 和 CryptoREX 不区分潜在的误用和明确的误用）。
④ 只比较百分比而非绝对数字，仅关注总体分布和API设计对密码误用的影响。（CryptoREX 在过滤之前只报告了成功解压的固件映像的详细信息，可能作者得不到其代码） -
评估发现
开发人员通过使用依赖项而不是直接使用各自的加密库来引入他们的大多数误用。
不可不提的小缺陷
◾ 本文的结果可能不能推广到 特定的Python应用程序 以及 不太流行的或源代码封闭的项目 中去；
◾ 静态分析仅限于 Babelfish 的性能，特别是其过滤函数的递归最大深度。
◾ Babelfish 只为单个文件创建 AST，无法解决多个文件上的误用问题（无法批量处理）。
◾ Python是一种动态类型语言，本文的静态分析可能忽略了一些误用（漏报）。
◾ 研究对比未必准确。
就读到这里啦，idea有了就要立马行动起来呀
不然就会被抢先/(ㄒoㄒ)/~~
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
