software

安全不是特性，它是基础

发布: (2025年12月29日 GMT+8 00:37)
11 min read
原文: Dev.to

Source: Dev.to

请提供您希望翻译的完整文本内容，我将为您翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。

我硬着头皮学到的教训

大约在我职业生涯的第十年，我经历了一次至今仍让人毛骨悚然的安全事件。

我们正在为一家金融客户开发在线交易系统。团队里的一名年轻程序员在编写查询订单历史的接口时，为了走捷径，直接拼接了 SQL 字符串。是的，你没看错——最经典、 textbook 级别的 SQL‑injection 漏洞。😈

黑客利用了这个漏洞，绕过了身份验证，直接窃取了整张用户表。等我们发现时，已经为时已晚。

接下来的几个月里，我们整个团队陷入了噩梦：

  • 配合调查，
  • 安抚客户，
  • 修复漏洞，
  • 审计公司所有其他项目以排查类似风险。

公司的声誉和业务受到严重损害。这次事件给了我职业生涯中最深刻的教训：在 Web 开发的世界里，安全永远是第一位。

为什么“以后再做安全”是致命的误解

许多开发者，尤其在项目期限紧迫时，会把安全视为一个“功能模块”。

“我们先实现主要功能，等下一个迭代再加入安全。”

这是一个致命的误解。安全不是可以在房子建好后再涂上的油漆。它是必须在挖第一铲土时就考虑的基础和结构。

如果你的基础不牢固，无论上面的建筑多么宏伟，最终都注定会倒塌。 😨

“做错事”的经典案例

以下列出了一些最常见的漏洞。它们可以出现在任何语言中，但某些语言和框架更容易导致这些错误。

1. SQL 注入 – 将命令与数据混淆

这个错误的根本原因是把“命令”当成了“数据”。你本来期望 $username 是数据，但通过字符串拼接，它就有机会变成一条“命令”。

2. 跨站脚本 (XSS)

当其他用户访问此页面时，恶意的 JavaScript 将在他们的浏览器中执行。它可以窃取 cookie、伪造请求，后果不堪设想。

3. 跨站请求伪造 (CSRF)

想象一下，你已经登录了银行网站 mybank.com。随后在另一个浏览器标签页中，你不小心点击了恶意站点 evil.com。该恶意站点可能隐藏了一个表单，自动向 mybank.com/transfer 提交转账请求。由于你的浏览器已经保存了 mybank.com 的登录 cookie，银行服务器会把这个请求视为合法！于是，你在不知情的情况下把钱转给了黑客。 💸

这些漏洞之所以常见，是因为在许多旧的技术栈中，不安全的写法往往是最简单、最直观的方式。要实现安全，需要额外的、有意识的努力。

默认安全：现代框架哲学

一个负责任的现代框架生态系统应该是 “默认安全”。这意味着：

  • 编写代码的最简单、最直观的方式也应该是最安全的方式。
  • 你应该需要额外努力 去绕过 安全机制，而不是去启用它们。

Hyperlane 框架及其周边的 Rust 生态系统就是这种哲学的典范。

Hyperlane（以及 Rust）如何帮助构建安全基础

sqlx – 安全的数据库交互

我们在之前的文章中已经讨论过，Hyperlane 生态系统推荐使用 sqlx 进行数据库交互。它的核心特性之一是 参数化查询 和 编译时检查。

// Example of a parameterized query with sqlx
let row = sqlx::query!("SELECT * FROM users WHERE username = $1", username)
    .fetch_one(&pool)
    .await?;
  • $1 告诉驱动程序：“把这个第一个参数当作纯数据处理，无论它包含什么。”
  • 数据库永远不会把它当作 SQL 来解析，从而消除 SQL 注入的可能性。
  • sqlx 在 编译时 连接到你的数据库，以验证 SQL 语法是否有效以及返回类型是否匹配你的 User 结构体。双重保险，万无一失！ ✅

通过模板引擎实现 XSS 防护

从文档中我们看到提到“对 XSS 攻击的额外防护”。在现代 Web 框架中，这通常通过集成默认进行 HTML 转义 的模板引擎来实现。

在 Rust 生态系统中，像 Tera 或 Askama 这样的模板引擎遵循“默认安全”原则。

{{ username }}          {# 自动转义 #}
{{ username | raw }}    {# 有意关闭转义 #}

如果 username 包含 alert('hacked')，引擎会将其渲染为无害的纯文本，而不是可执行脚本。只有在使用特殊的 “raw” 过滤器时才会关闭这层安全阀。设计得真好！ 😌

CSRF 防护 – 基于 Token 的中间件

从 Hyperlane 生态系统的日志中我们看到 X‑CSRF‑TOKEN 的提及。这表明框架设计者已经充分考虑了 CSRF 防护。一个典型的基于 Token 的 CSRF 中间件在 Hyperlane 架构中的实现大致如下：

  1. 生成 Token – 用户登录后，中间件生成一个随机、唯一的 CSRF Token，将其存入用户会话（Context 的属性中），并通过 Set‑Cookie 响应头发送给客户端。
  2. 在表单中嵌入 Token – 前端在渲染表单时，从 Cookie 中读取 CSRF Token 并作为隐藏字段加入表单。
  3. 验证 Token – 当用户提交表单时，另一个中间件检查所有 “不安全” 请求（POST、PUT、DELETE 等），将表单中的 Token 与会话中的 Token 进行比较。
    • 若两者匹配，请求被视为合法并通过 next() 传递给下一个处理器。
    • 若不匹配，请求立即被拒绝。 🛡️

安全响应头 – HSTS

我们还看到诸如 Strict-Transport-Security 的安全响应头。这表明框架的设计鼓励开发者使用其他最佳实践，例如 HSTS，以防止中间人攻击。

Rust 的固有安全性

由于 Hyperlane 基于 Rust 构建，它天然免受一整类内存安全错误（缓冲区溢出、使用后释放等）的影响，而这些问题在许多其他语言中屡见不鲜。这种底层安全进一步增强了基于该技术栈构建的应用程序的整体安全姿态。

要点

  • 安全必须从第一天起就内置。
  • 选择一个 现代、默认安全的技术栈（例如 Hyperlane + Rust + sqlx）。
  • 利用框架提供的 参数化查询、自动 HTML 转义、CSRF 令牌 和 安全头部。
  • 记住：编写代码的 最简 方法也应该是 最安全 的方法。

通过采用这些实践，你将避免我曾经历的噩梦，并构建建立在坚实安全基础上的应用程序。

低级语言中的安全漏洞

不当的内存管理（例如，缓冲区溢出和悬空指针）仍然是 Web 服务器或用 C/C++ 编写的模块中的主要安全威胁来源。
选择 Rust 就像给你的房子穿上一副盔甲。 💪

安全至上的思维方式

Security isn’t a checklist you can simply tick off. It’s a mindset and a practice that runs through the entire software development lifecycle. It starts with:

  • 你选择的语言
  • 你依赖的框架
  • 你遵循的架构

默认安全框架

一个优秀的框架生态系统不会把全部安全负担都压在个人开发者身上。通过提供 secure‑by‑default 工具和模式，它：

  • 使得犯下基本但常见的安全错误变得困难
  • 将安全变成一种自然的习惯

实际限制

没有任何技术能够让你 100 % 无忧。业务逻辑漏洞仍需由开发者发现并修复。然而，选择像 Hyperlane 和 Rust 这样从底层就为安全而设计的技术栈，能够让你在攻防永无止境的竞争中处于更有利的位置。 ❤️

*GitHub Home*
Back to Blog

相关文章

阅读更多 »