GitHub Actions加强Checkout安全性，防御"pwn request"攻击

在开发者环境中网络攻击愈演愈烈的背景下，GitHub近日强化了actions/checkout的安全机制，旨在拦截"pwn request"攻击。这类攻击利用pull_request_target工作流触发器的不安全使用，以完整的工作流权限执行攻击者的恶意代码。

2024年6月18日正式发布的actions/checkout v7，现在会在pull_request_target或workflow_run事件中自动拦截并终止工作流，防止其拉取未经审核的Fork拉取请求代码。

GitHub在V7更新日志中说明，今后开发者若需绕过上述检查，必须在actions/checkout中显式添加allow-unsafe-pr-checkout选项以主动声明豁免。

这一变化标志着GitHub正式迈入"默认安全"的新时代——安全策略将由GitHub平台统一定义，而非依赖开发者的个人判断。作为该计划的一部分，新的默认设置将于7月16日回溯适用至所有受支持的主要版本。

GitHub解释道："固定到浮动主版本标签（例如actions/checkout@v4）的工作流将自动获得此次更新，而固定到特定SHA、次版本号或补丁版本的工作流不受此次回溯影响，需通过Dependabot或既有升级流程手动升级。"

不过，更新日志也补充指出，由于pwn request攻击的触发方式不止一种，"未来版本可能会对其他事件进行进一步的安全加固"。

值得注意的是，外界对GitHub的批评在于：这一已被业内熟知多年的漏洞，GitHub却迟迟未能修复。

问题的根源在于GitHub Actions的工作流触发机制。其中，pull_request触发器在处理第三方Fork时不会授予API密钥、服务Token及凭据等敏感信息的访问权限，但这一限制也导致某些自动化流程无法正常运行。因此，部分开发者转而使用pull_request_target触发器，因为它能够授予所需的访问权限。

攻击者随即发现，当pull_request_target与actions/checkout配合不当、拉取不受信任的Fork代码时，便为仓库及其敏感信息留下了后门。

换言之，pull_request_target本身并无问题——在正确使用的情况下它是合法且安全的——问题出在错误的使用方式上。正如GitHub更新日志所言："在上述工作流中拉取来自Fork的未经审核的拉取请求头部代码，通常会让攻击者控制的代码以工作流的完整权限执行。"

actions/checkout v7的到来有望改变这一局面，无论工作流配置如何，都将自动拦截高风险操作。

然而，目前已有大量损失发生。近期，开源仓库持续遭受TeamPCP黑客组织的攻击，攻击手段多样，其中就包括pwn request。一个典型案例是上月该组织发动的攻击——利用pwn request漏洞，成功入侵了170个npm包，其中包括TanStack Router生态系统。更为尴尬的是，在另一起无关pwn request的独立事件中，GitHub自身也遭到入侵，攻击者从公司约3800个内部仓库中窃取了源代码。

亡羊补牢，犹未为晚。GitHub已开始采取行动，推进一系列平台安全改革，包括本月初对npm中自动安装脚本执行行为的限制。

Q&A

Q1：actions/checkout v7是如何防御pwn request攻击的？

A：actions/checkout v7会在pull_request_target或workflow_run事件触发时，自动拦截并终止试图拉取未经审核的Fork拉取请求代码的工作流。开发者若确有需要绕过此检查，必须在配置中显式添加allow-unsafe-pr-checkout选项，主动声明豁免意图，从而将安全责任明确化，而非依赖默认行为。

Q2：pull_request_target触发器为什么会带来安全风险？

A：pull_request_target本身是合法且安全的触发器，问题出在错误的使用方式上。当开发者将其与actions/checkout配合使用、且不加限制地拉取来自外部Fork的未审核代码时，攻击者便可借此让恶意代码以工作流的完整权限（包括访问API密钥、服务Token等敏感信息）执行，从而实现对仓库的入侵。

Q3：此次GitHub安全更新会影响所有版本的工作流吗？

A：并非所有版本都会自动受到影响。固定到浮动主版本标签（如actions/checkout@v4）的工作流将在7月16日回溯更新后自动获得新的安全默认设置；而固定到特定SHA、次版本号或补丁版本的工作流不会自动更新，需要开发者通过Dependabot或手动升级流程进行版本升级。