后端安全

后端系统负责处理应用中最敏感的一些部分，包括用户凭证、个人数据、财务记录以及内部服务通信。如果这些系统被攻破，影响可能非常严重，从数据泄露到整个服务中断都有可能发生。

安全机制的作用是严格控制谁可以访问系统，以及他们被允许执行哪些操作。如果没有这些控制，任何客户端都可能访问或修改关键数据。

常见威胁包括未经授权的访问尝试、大规模数据泄露，以及旨在利用系统漏洞的恶意攻击。这些威胁在生产环境中持续存在，必须主动防御。

从高层来看，后端安全在客户端和系统之间引入了一层保护。每个请求在到达应用逻辑之前，都必须先通过安全控制。这些控制确保只有有效且经过授权的操作才会被执行。

身份验证是保护后端系统的第一步。它回答一个基本问题：“是谁在发起这个请求？”在允许任何操作之前，系统必须验证请求者的身份。

这个过程通常涉及凭据。用户可能输入密码、提供会话令牌，或者使用 API key。在更高级的方案中，Google 等身份提供方或企业身份验证系统可以代表应用程序验证身份。

一旦凭据通过验证，系统就会认为该身份已被确认。这并不意味着用户可以做任何事——它只是在确认他们是谁。至于他们被允许做什么，则由授权单独处理。

如果没有身份验证，系统就无法区分合法用户和恶意行为者，从而使安全访问控制变得不可能。

一旦用户通过身份验证，系统就知道他们是谁，但仍然需要确定他们被允许执行哪些操作。这就是授权的作用。

授权通过检查权限来工作。例如，普通用户可能只能查看自己的数据，而管理员可能有权删除账户或修改系统设置。这些规则通过角色、访问控制列表或基于策略的系统来强制执行。

这个过程遵循一个简单的流程：经过身份验证的用户发起请求，系统检查其权限，然后允许或拒绝该操作。

如果没有正确的授权，已通过身份验证的用户可能会访问或修改他们不应访问的数据，从而导致严重的安全漏洞。

OAuth 是一种为委托访问而设计的协议。用户不会把密码之类的凭据分享给多个应用程序，而是通过受信任的提供商（例如 Google）进行身份验证，然后由该提供商通过令牌向应用程序授予有限访问权限。

这个流程通常如下：用户选择使用某个提供商登录，提供商对用户进行身份验证，然后向应用程序发放访问令牌。这个令牌代表用户的授权，可用于访问特定资源。

这种方式提高了安全性，因为应用程序从不会看到或存储用户的真实凭据。它还允许对应用程序可以访问的数据进行细粒度控制。

OAuth 被广泛用于“使用 Google 登录”、“使用 Facebook 登录”以及类似集成，从而实现安全的第三方身份验证和受控的数据共享。

JSON Web Tokens (JWTs) 是在无状态系统中维护身份验证的一种常见方法。用户登录后，服务器会生成一个 JWT 并发送给客户端。随后，客户端会在未来的请求中包含这个令牌，通常放在 HTTP Authorization header 中。

JWT 包含诸如用户 ID、权限和过期时间等编码信息。这些数据由服务器签名，因此后端可以验证令牌是否被篡改。

由于该令牌携带了所有必要的身份信息，服务器无需为每个用户存储会话数据。这使得 JWT 高效且可扩展，尤其适用于分布式系统。

不过，JWT 必须谨慎处理。如果令牌泄露，在过期之前都可能被用来冒充用户。正确设置过期时间以及在客户端安全存储都至关重要。

以明文形式存储密码是一个严重的安全漏洞。如果数据库被攻破，攻击者会立即获得所有用户的密码。为防止这种情况，系统会改为存储密码的哈希版本。

哈希函数接收一个输入（密码）并生成一个固定长度的输出（哈希值）。这个过程是单向的，也就是说，从哈希值反推出原始密码在计算上是不可行的。

当用户登录时，系统会对输入的密码进行哈希，并将其与存储的哈希值进行比较。如果匹配，就说明密码正确，而不会暴露原始值。

现代哈希算法，如 bcrypt、Argon2 和 PBKDF2，故意设计得较慢，并包含加盐等特性，以抵御暴力破解和预计算攻击。这使它们比基础哈希函数安全得多。

跨站请求伪造（CSRF）发生在恶意网站诱使用户的浏览器向另一个用户已经认证的网站发送请求时。由于浏览器会自动包含会话 cookie，服务器会认为该请求是合法的。

例如，如果用户登录了一个银行应用并访问了一个恶意网站，该网站可能会触发一个隐藏请求来转账。服务器会处理该请求，因为它看到了有效的会话，尽管用户并没有打算执行这个操作。

为了防止 CSRF 攻击，系统会使用 CSRF token 和 same-site cookie 等技术。CSRF token 是包含在请求中的唯一值，服务器会对其进行验证，以确保请求来自正确的应用。Same-site cookie 会限制 cookie 的发送时机，从而降低跨站请求的风险。

如果没有适当的 CSRF 防护，攻击者就可以利用受信任的用户会话，在无需直接获取用户凭据的情况下执行有害操作。

当应用程序在网页中包含不受信任的用户输入，但没有正确进行验证或转义时，就会发生跨站脚本攻击（XSS）。这使攻击者能够注入脚本，并在其他用户的浏览器中运行。

例如，如果评论字段允许原始 HTML 或 JavaScript，攻击者就可以插入一段脚本，使其在其他用户查看页面时执行。该脚本可能窃取 cookies、捕获用户输入，或代表用户执行操作。

为了防止 XSS，系统必须将所有用户输入视为不受信任的内容。输入清理会移除潜在危险内容，而输出转义可确保数据以文本形式渲染，而不是作为可执行代码。内容安全策略（CSP）通过限制允许运行的脚本，增加了额外的保护层。

如果没有适当的防御，XSS 漏洞可能会危及用户账户，并削弱整个应用程序的安全性。

后端系统依赖敏感凭证与数据库、外部服务和内部组件进行通信。这些密钥包括 API keys、数据库密码和加密密钥，所有这些都必须防止未经授权的访问。

将密钥直接存储在代码或配置文件中是一个重大的安全风险。如果代码库被暴露，所有嵌入的凭证都会立即泄露。相反，密钥应存储在专门设计用于安全存储和受控访问的系统中。

AWS Secrets Manager 和 HashiCorp Vault 等 secrets manager 提供凭证的集中存储、访问控制和自动轮换。对于更简单的设置，有时会使用环境变量，但它们仍然需要谨慎处理。

正确的密钥管理可以降低凭证泄露的风险，并确保系统能够安全地访问所需资源，而不会暴露敏感信息。

速率限制不仅仅是一个性能工具——它还是一种关键的安全机制。通过控制客户端可以发送多少请求，系统可以防止诸如暴力破解登录尝试或拒绝服务攻击之类的滥用。

例如，限制登录尝试次数可以降低密码猜测攻击的有效性。同样，强制执行 API 请求配额可以防止单个客户端压垮后端服务。

这个过程很直接：传入请求会根据定义的限制进行检查，如果超过阈值，请求就会被拒绝或延迟。这样可以确保公平使用并保护系统资源。

当与其他安全措施结合使用时，速率限制会显著增强系统对恶意流量和滥用行为的抵御能力。