Rust 连续第五年成为最受喜爱的编程语言。它是我们新的安全救星吗？

过去几年里，全球的软件工程师似乎对 Rust 编程情有独钟。这门由 Mozilla 开发的相对较新的系统编程语言，已经俘获了 Stack Overflow 社区的心。作为一个极其挑剔的群体，当他们连续五年将某项技术评为“最受喜爱的编程语言”时，我们确实应该予以高度关注。

Rust 编程语言融合了常用语言中已知且实用的元素，并采用了一种摒弃复杂性、同时引入高性能与安全性的独特理念。目前它仍处于学习曲线中，许多开发者还没有机会深入使用它——在 Stack Overflow 的受访者中，仅有 5.1% 的人经常使用它。尽管如此，不可否认的是，它是一门令人兴奋的语言，且比 C 和 C++ 等前辈拥有更强大的安全火力。大规模普及需要行为和技术层面的双重变革……但就目前而言，它在理论层面已经吸引了开发者的广泛关注。

……但请等一下，我们还需要强调一点：必须指出的是，Rust 是一门优先考虑内存安全并致力于根除与常见内存管理问题相关的安全漏洞的编程语言。这些问题固然重要（无疑也让许多应用安全团队头疼不已），但它们并非我们面临的唯一安全编码挑战。

Rust 究竟能预防什么？在安全领域，我们还有哪些地方依然暴露在风险之中？让我们来深入剖析这位最新的编程“独角兽”：

现代内存安全系统编程的新前沿

Mozilla 的研发团队开展了许多令人惊叹的项目，投资 Rust 编程作为开源领域的先驱也不例外。他们的介绍视频深入阐述了其核心理念，主题非常明确：当前的软件安全方法存在缺陷，而 Rust 正是为了解决大部分此类问题而设计的。

这看起来似乎过于简单，尤其是考虑到我们几乎每天都要面对大规模的数据泄露——就像最近 EasyJet 报道的那起骇人听闻的失误一样。数以百万计的数据记录频繁遭到泄露，几乎总是源于 Web 应用程序漏洞、安全配置错误或网络钓鱼攻击。C++ 等语言已经存在了几十年，但这并没有让开发者掌握到足以实现安全编码最佳实践的程度。为什么 Rust 会有所不同？新语言以前也出现过，它们并没有找到根除常见漏洞的方法，也不可能确保编写的任何代码在编译时就完美无缺。

尽管概念简单，但有时正是简单的答案才能解决复杂的问题。Rust 在各个层面都是内存安全系统编程的一场革命，它在许多方面兑现了自己的承诺……对于那些容易引入错误并导致严重后果的开发者来说，它无疑是救星。Java、C、C++，甚至 Kotlin 和 Golang 等较新的语言，对于缺乏安全意识的开发者来说依然相当“无情”。在这些语言中，没有内置的警告，也没有明显的迹象表明刚刚编译出的强大功能背后隐藏着安全隐患。

那么，让我们深入探讨一下：

是什么让 Rust 如此安全？

通常，开发者的首要目标是构建功能，确保其可用且用户友好——甚至可能将其视为值得在简历上展示的成就。开发者编写出优秀软件、发布并转向下一个大项目，这是完全正常的。此时，安全团队会检查漏洞，如果发现问题，他们“完成”的应用程序可能会被退回给团队进行热修复。这个问题可能很简单，也可能超出了开发者修复的合理范围。

问题在于，在表面层面上，这些安全漏洞根本不明显。如果扫描、测试和人工代码审查未能发现它们，那么攻击者就有可能利用这个小小的机会窗口来利用该漏洞。

现在，Rust 试图从源头上阻止许多漏洞进入代码：如果存在语法错误或其他会导致整个软件开发生命周期（SDLC）中出现生产问题的内存安全漏洞，它干脆就不会编译。这是设计上的内存安全编程，确保无法访问无效内存（无论软件如何执行）。鉴于所有安全漏洞中 70% 都是由内存管理相关问题引起的，这是一项了不起的成就。

Rust 将标记并预防：

• 缓冲区溢出
• 释放后使用
• 重复释放
• 空指针解引用
• 使用未初始化内存

如果我们对比 Rust 和 C++ 的代码片段，就会发现前者在默认情况下是安全的。来看看这个缓冲区溢出漏洞的示例：

#include <iostream></iostream>
#include <string.h></string.h>
int main( void ) {
char a[3] = "12";
char b[4]= "123";
strcpy(a, b); // 缓冲区溢出，因为 b 的长度大于 a
std::cout << a << "; " << b << std::endl;
}

对比

pub fn main() {
let mut a: [char; 2] = [1, 2];
let b: [char; 3] = [1, 2, 3];
a.copy_from_slice(&b);
}

Rust 会抛出安全警告，并在运行时执行到 copy_from_slice 函数时触发恐慌（panic）以防止缓冲区溢出，但不会在编译时进行拦截。

从这个意义上说，它确实属于那种“左移”语言。它会高亮显示错误，强制开发者学习编写代码的正确方式，从而避免引入内存相关的安全漏洞。因此，能否按时交付取决于开发者是否保持专注、及时修复问题并严格遵循开发路径。

这种语言的方法看似简单，但能实现如此强大的逻辑实属壮举，而且它确实言出必行。从安全角度来看，Rust 是一个巨大的飞跃……如果能有更多人使用它就好了。Dropbox 等公司正在大规模企业应用中率先使用它，这令人欣慰。但我们不能急于得出结论，认为仅仅因为采用率问题就阻碍了我们迈向更安全的未来，这背后还有更多考量。

Rust 的清算时刻。

这里存在几个小（好吧，其实是大）问题，即使用 Rust 编程时引入漏洞的灵活性比看起来要大。它 无法 解决那些持续导致数据泄露、项目延期以及不安全编码文化盛行的 OWASP Top 10 关键漏洞。此外，它还存在一种“天使与魔鬼”的动态关系，或者更广为人知的说法：安全 Rust 与不安全 Rust。
‍

正如 官方文档 所述，安全 Rust 是 Rust 的“正统”形式，而不安全 Rust 包含了一些被认为“绝对不安全”的函数，尽管它们有时是必要的——例如在需要与其他语言进行集成时。然而，即使在不安全 Rust 中，额外功能的列表仍然是有限的。在不安全 Rust 中，可以在 unsafe 代码块内执行以下操作：

• 解引用原始指针
• 调用不安全函数（包括 C 函数、编译器内置函数和原始分配器）
• 实现不安全特征（traits）
• 修改静态变量
• 访问联合体字段。

即使在所谓的“不安全”模式下，Rust 编程的一大超能力依然有效：即“借用检查器”。它通常通过静态代码分析来防止内存问题、并行计算中的冲突以及许多其他错误。这种分析在不安全代码块中依然会进行检查，只是在某些情况下，编写不安全结构时需要付出更多努力，因为编译器不会像平时那样提供指导。

对于大多数经验丰富的开发者来说，这似乎不是什么大问题——毕竟，我们习惯于通过折腾来榨取应用程序的最佳性能并开启一些更酷的功能——但这可能会打开一个导致严重配置错误和安全漏洞的黑洞：未定义行为。与 C 或 C++ 相比，使用 Rust 编程（即使是不安全用法）能很好地锁定漏洞的可能性，但调用未定义行为仍然存在风险。

我们是否不再需要依赖开发者主导的安全编码了？

还记得我之前提到 Rust 包含知名语言的组件吗？Rust 的主要安全漏洞之一就是，它确实包含了一些知名语言的组件——即 C 语言。

Rust 仍然是一种“安全编程语言”，但同样，引入人为因素后，事情就可能变得棘手。开发者仍然可以对其进行调整，使其在不报错的情况下运行（这很有吸引力，因为这解锁了更多功能）。本质上，即使在安全状态下，开发者仍然可以随心所欲地“不安全”操作，因为在事情真正变得一团糟之前，他们还有一层指导和保护。

随着我们深入研究，上述两种情况都会变得更加危险。因为 Rust 的结果与扫描工具类似——正如没有一种万能的 SAST/DAST/RAST/IAST 工具能扫描出所有漏洞、攻击向量和问题一样，Rust 也做不到。即使使用 Rust，某些漏洞仍然很容易被引入。

运行不安全 Rust 时的未定义行为风险可能会引发整数溢出问题。而总体而言，即使是安全的配置也无法防止人为错误导致的配置失误、业务逻辑漏洞，或使用存在已知漏洞的组件。如果这些问题不及时修补，仍会构成非常现实的威胁。在像纯 Rust 这样“默认安全”的环境中，如果开发者认为所有重大问题都会被自动捕获，甚至可能导致某种自满行为。

我发现 Rust 就像一位编程导师——一位资深工程师，他花时间坐在经验不足的开发者身边，审查他们的工作，指出潜在的错误，提出优化建议，并在某些情况下确保代码在正确之前不会被编译。然而，Rust 程序员最好还是自己学习理论并致力于最佳实践，因为导师总有放手的一天，你可不想在那时陷入困境。

准备好立即发现并修复常见的 Rust 漏洞了吗？参与挑战。