35条新增Semgrep规则：基础设施、供应链和Ruby

我们发布了另一组自定义Semgrep规则，使我们的公共规则总数达到115条。本篇博客将简要介绍新规则，然后深入探讨两个Semgrep功能：正则模式（特别是与通用模式的对比）以及对Terraform和Nomad等技术的HCL语言支持。借助这些功能，我们可以在不仅仅是应用程序代码中搜索安全漏洞。此次新发布与我们现有的Semgrep规则集合、公共CodeQL查询和测试手册一起，作为我们长期努力与安全社区分享技术专业知识的一部分。

Semgrep是一个功能强大的工具，包含许多可挖掘的角落，以从静态分析工具中获得最大价值。与我们之前的Semgrep规则发布帖子一样，本文将重点介绍一些有趣的Semgrep功能。公开发布规则是一个很好的开始，但我们觉得通过解释规则编写的原因可以做得更好。

本次发布，我们专注于与GitHub Actions中缺乏短期OIDC令牌相关的供应链问题；Terraform代码中的基础设施问题、Nomad作业和不安全的数据库连接；以及Ruby代码中的一般应用程序安全问题。许多Ruby规则是在我们最近的Ruby Central（rubygems.org）审计期间编写的。我们很快将发布有关此审计的更多信息。

事不宜迟，以下是我们新增的规则：

Ruby规则

action-dispatch-insecure-ssl：发现具有不安全SSL设置的Rails应用程序。
action-mailer-insecure-tls：发现具有不安全TLS设置的ActionMailer SMTP配置。这些设置不要求建立成功、加密、验证的TLS连接。设置enable_starttls: true并将openssl_verify_mode设置为验证对等方。
active-record-encrypts-misorder：发现序列化之前加密的ActiveRecord值。序列化属性的声明应在加密声明之前。
active-record-hardcoded-encryption-key：发现硬编码的ActiveRecord加密密钥。
global-timeout：发现Timeout::timeout（或timeout）的使用。设置全局超时可能导致在传递的代码块中的任何地方引发异常。这排除了通常与从异常中恢复相关的任何可能的清理操作。这可能导致拒绝服务、数据完整性失败和一般可用性问题。相反，优先使用库的内置超时功能（如果有），以确保处理按预期进行。如果没有内置超时功能，则考虑实现它。
faraday-disable-verification：发现禁用SSL/TLS验证的Faraday HTTP请求。
ruby-saml-skip-validation：为$KEY禁用了SAML响应验证。
yaml-unsafe-load：发现对unsafe_load的YAML调用。这可能导致反序列化错误和RCE。
rails-cookie-attributes：发现具有不安全属性的Rails cookie设置。
rails-cache-store-marshal：发现配置为允许封送处理的Rails缓存存储。从Rails 7.1开始，默认序列化程序是:marshal_7_1。如果攻击者可以将数据注入缓存存储（SSRF等），则当对象后来被反序列化时，他们可以实现代码执行。考虑使用:message_pack序列化程序或自定义序列化程序。
json-create-deserialization：发现json_create类方法。这意味着正在发生自定义JSON反序列化。这可能导致RCE和其他反序列化类型的错误。应审计使用情况，并至少进行模糊测试。
insecure-rails-cookie-session-store：发现缺少SameSite=Secure的Rails会话cookie。从Rails 7.2开始，会话cookie默认为SameSite=Lax。
rest-client-disable-verification：发现禁用SSL/TLS验证的RestClient HTTP请求。

正则模式规则

postgres-insecure-sslmode：发现禁用SSL验证的PostgreSQL连接字符串。
mongodb-insecure-transport：发现不安全的MongoDB连接，优先通过设置tls=true连接选项并确保适当验证来使用TLS加密传输。
mysql-insecure-sslmode：发现禁用SSL验证的MySQL连接字符串。

通用模式规则

amqp-unencrypted-transport：发现未加密的AMQP连接，优先使用TLS加密的amqps://传输。
redis-unencrypted-transport：发现未加密的Redis连接，优先使用TLS加密的rediss://传输。
node-disable-certificate-validation：设置此环境变量会禁用TLS证书验证。这使得TLS以及扩展的HTTPS变得不安全。强烈不鼓励使用此环境变量。

HCL规则

aws-oidc-role-policy-duplicate-condition：发现具有重复条件的GitHub Actions的AWS角色策略。这会覆盖先前的条件，最后一个具有重复键的条件“获胜”。这可能会破坏访问控制并允许未经授权的访问。
aws-oidc-role-policy-missing-sub：发现缺少OIDC主题的GitHub Actions的AWS角色策略。这意味着任何GitHub仓库都可以在CI中承担此角色。
vault-hardcoded-token：发现具有硬编码令牌的Terraform Vault实例。
vault-skip-tls-verify：发现禁用TLS验证的Terraform Vault实例。
root-user：发现使用root用户的Nomad任务。
docker-hardcoded-password：发现使用具有硬编码密码的Docker身份验证的Nomad任务。
docker-privileged-mode：发现以特权模式使用Docker容器的Nomad任务。
tls-hostname-verification-disabled：发现禁用服务器主机名验证的Nomad tls块。
podman-tls-verify-disabled：发现使用禁用注册表TLS验证的Podman的Nomad任务。

YAML规则

jfrog-hardcoded-credential：发现长期访问密钥。相反，优先使用JFrog临时OIDC安全凭据。
aws-secret-key：发现长期访问密钥。相反，优先使用AWS角色承担和临时OIDC安全凭据。
gcp-credentials-json：发现长期访问密钥。相反，优先使用GCP工作负载身份联合和临时OIDC安全凭据。
rubygems-publish-key：发现长期访问密钥。相反，优先使用RubyGems受信任发布和临时OIDC安全凭据。
vault-token：发现长期访问密钥。相反，优先使用Vault角色承担和临时OIDC安全凭据。
pypi-publish-password：发现长期访问密钥。相反，优先使用PyPI受信任发布和临时OIDC安全凭据。
azure-principal-secret：发现长期访问密钥。相反，优先使用Azure订阅ID和临时OIDC安全凭据。

Semgrep不仅适用于编程语言

本系列的第一篇文章包括对两个较少知的Semgrep功能的观点：通用模式和YAML支持。本文介绍了两个额外的考虑因素：正则表达式与通用模式以及HashiCorp配置语言（HCL）对基础设施即代码（IaC）安全的支持。我们将继续将Semgrep应用于所有形式的文本数据的趋势。

启发式：正则表达式与通用模式

正则表达式模式是Semgrep的另一个较少知的功能。这就是所谓的pattern-regex操作符和regex语言。但为什么你想在Semgrep规则中使用正则表达式？这不是违背了像Semgrep这样的静态分析工具的目的吗？为什么不直接使用ripgrep或经典grep？通用模式不是使regex模式变得多余吗？

以下启发式将帮助你理解何时使用regex模式。你对以下问题的“是”回答越多，你就越应该使用regex模式。

启发式#1：你正在寻找的文本通常跨越单行代码吗？

在正则表达式中处理多行空白是很痛苦的。如果你发现自己正在搜索多行模式，并且无法使用特定语言的规则，那么通用模式可能最适合你。所以请记住：当使用regex模式时，你正在搜索的文本几乎总是跨越单行。

启发式#2：这种模式存在于许多语言或类型的文本文件中吗？

Semgrep的美妙之处在于它是一个一站式商店，适用于所有文本分析。如果你正在搜索的文本可能存在于许多语言中，那么它可能适合regex模式。例如，考虑URL参数。如果你正在搜索，比如sslmode=disable，那么以下正则表达式将是一个很好的开始：[?&]sslmode=(disable|allow|prefer)。这很棒，因为它将在任何语言中的任何PostgreSQL库的任何连接URI中找到这个不安全的URL参数。我们不必为不同的库和语言编写单独的规则。它还会在shell脚本、文档、CI作业等中找到这种模式。

启发式#3：你想与他人分享你的正则表达式吗？

再次，Semgrep的美妙之处在于它将ripgrep或经典grep等工具的功能整合到一个工具下。ripgrep在你快速迭代正则表达式并在代码中搜索模式时可能很有用，但Semgrep规则在编码、测试和发布正则表达式时真正闪耀。你的正则表达式发现将存在于你的Python和Kubernetes发现旁边，你可以从一个位置跟踪所有发现并管理规则。

启发式#4：你需要匹配特定字符或字符类吗？

Regex模式和通用模式通常服务于类似的需求。我们之前的帖子讨论了通用模式的优势，那么你何时应该使用regex模式？当你想要匹配特定字符或字符类，或使用其他正则表达式功能（如交替）时，regex模式优于通用模式。例如，在上面的sslmode正则表达式中，我们搜索由字符类?和&前缀的sslmode。这两个前缀使我们额外确信我们找到的实际上是一个URL参数。据我们所知，在通用模式中没有简单的方法来表达这一点。我们总是可以使用pattern-either，但对于更复杂的表达式，这可能会变得非常冗长。另一方面，通用模式的主要优势是它支持省略号操作符（即…），这允许轻松跳过多行模式中使用的非匹配元素和空白。

如你所见，通常有多种方法在Semgrep中搜索特定的代码模式。上述启发式为你何时可能想使用regex模式提供了一个良好的基线。更重要的考虑是regex模式存在，并且它是你在搜索文本数据时工具带中的一个宝贵工具。

HCL支持和IaC安全

基础设施即代码（IaC）已经改变了云管理。它通过版本控制环境带来了更快的部署、改进的一致性和可重复性，以及更好的安全性，这些环境以前依赖于手动配置。通过编码基础设施，组织可以将这些定义与CI/CD管道无缝集成，从而实现自动化测试、部署和静态分析。

HashiCorp配置语言（HCL）是许多IaC工具的基础，包括Terraform、Nomad和Consul。认识到IaC日益增长的重要性，Semgrep在2021年引入了HCL支持。通过专用的HCL支持，Semgrep现在允许采用统一的方法，将相同水平的审查应用于应用程序代码和基础设施配置，确保它们在CI/CD管道中和谐地工作。

我们已经了解到，即使是最直接的Semgrep规则也可以发现2024年仍然构成风险的重大问题。以在开发期间禁用TLS验证的常见做法为例。如果此配置被无意中部署，它可能会暴露敏感数据。以下是如何使用Semgrep在Vault基础设施中轻松检测此类漏洞：

1
2
3
4
5
6
7
8
9


rules:
  - id: vault-skip-tls-verify
    message: |
      Found Terraform Vault instance with TLS verification disabled
    languages: [hcl]
    severity: WARNING
    patterns:
      - pattern-inside: provider "vault" { ... }
      - pattern: skip_tls_verify = true

图1：搜索禁用TLS验证的Semgrep规则（hcl/terraform/vault-skip-tls-verify.yaml）

另一个常见的错误是硬编码凭据——Semgrep可以轻松捕获的安全风险：

1
2
3
4
5
6
7
8
9


rules:
  - id: vault-hardcoded-token
    message: |
      Found Terraform Vault instance with hardcoded token
    languages: [hcl]
    severity: WARNING
    patterns:
      - pattern-inside: provider "vault" { ... }
      - pattern: token = "..."

图2：搜索硬编码Vault令牌的Semgrep规则（hcl/terraform/vault-hardcoded-token.yaml）

通过将此步骤与配置你的CI/CD管道以阻止具有未解决Semgrep发现的PR（我们的推荐实践之一）相结合，你可以轻松地将这些问题排除在生产基础设施之外。

HCL的结构化性质也使其特别有效地检测更复杂的模式，并确保我们尽可能降低误报。例如，考虑以下规则，该规则识别缺少OIDC主题的GitHub Actions的AWS角色策略——这是一个关键的错误配置，可能允许任何GitHub仓库在CI中承担该角色：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51


rules:
  - id: aws-oidc-role-policy-missing-sub
    message: |
      Found AWS role policy for GitHub Actions missing OIDC subject. This
      means any GitHub repository can assume this role in CI.
    languages: [hcl]
    severity: WARNING
    patterns:
      - pattern-inside: |
          {
            ...
            Statement = [...]
            ...
          }
      - pattern-inside: |
          {
            ...,
            "Action": "sts:AssumeRoleWithWebIdentity",
            ...
          }
      - pattern: |
          {
            ...
            "Condition": {
                ...
                "StringEquals": {
                    ...
                    "token.actions.githubusercontent.com:aud": ...,
                    ...
                }
                ...
            }
            ...
          }
      - pattern-not: |
          {
            ...
            "Condition": {
                ...
                "StringEquals": {
                    ...
                    "token.actions.githubusercontent.com:sub": ...,
                    ...
                    "token.actions.githubusercontent.com:aud": ...,
                    ...
                }
                ...
            }
            ...
          }
      # 剩余pattern-not被截断以节省空间

图3：搜索缺少OIDC主题的Semgrep规则（hcl/terraform/aws-oidc-role-policy-missing-sub.yaml）

GitHub Actions的角色策略可以通过多种方式配置，我们可以使用pattern-inside和pattern-not来正确上下文化我们正在寻找的模式（即，未定义主题的实例）。此规则是一个强大的例子，说明Semgrep如何帮助强制执行安全策略并防止可能导致严重漏洞的配置错误。

文本是通用接口

如果文本是通用接口，那么Semgrep可以帮助保护任意接口，从字节和字符串到IaC、YAML等。将Semgrep的力量与正则表达式、通用模式、YAML和IaC支持相结合，使我们能够超越编程语言中的代码。随着行业将所有内容转向“即代码”解决方案，我们需要能够将可扩展工具应用于供应链、CI/CD和IaC等领域。

借助IaC，你可以将静态分析的相同严谨性应用于你的基础设施，就像你对应用程序代码一样，早期发现问题并避免在生产中犯下代价高昂的错误——“左移”，正如它所说。针对生产环境的手动审计和动态扫描速度慢且扩展性不好。我们鼓励你尝试我们新发布的Terraform和Nomad规则，探索Semgrep的terraform规则，并考虑将它们纳入你的项目。据我们所知，这些是第一个针对Nomad的开源Semgrep规则——我们很高兴与社区分享这一事实，希望激励其他人在此基础上构建。

如果你有兴趣阅读我们关于Semgrep工作的更多信息，我们已经以多种方式使用其功能，例如保护机器学习管道、发现goroutine泄漏和保护Apollo GraphQL服务器。

如果你对为你的项目定制Semgrep规则感兴趣，请联系我们！

如果你喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News

35条新增Semgrep规则：基础设施、供应链与Ruby安全检测

Trail of Bits发布35条新增Semgrep规则，覆盖基础设施配置、供应链安全及Ruby代码审计，深入解析正则模式与通用模式的区别，并展示HCL语言在Terraform/Nomad中的安全检测实践。