Web 开发

在网络安全的世界里，哈希（Hashing） 是最基础但经常被误解的概念之一。它是保护你密码、验证下载完整性以及驱动区块链的隐形盾牌。 但是，哈希到底是什么？为什么我们不能“解密”它？最重要的是，如果它是不可逆的，网站是如何知道你输入了正确的密码呢？ 1. 什么是哈希函数？ 密码哈希函数是一种数学算法，它将任意大小的输入（或“消息”）转换为固定大小的字符串（通常称为“摘要”）。这个字符串通常看起来像一串随机的字母和数字。 哈希的金科玉律： 确定性： 相同的输入始终会产生完全相同的哈希值。 计算高效： 算法应该足够快，以便实际应用。 固定输出大小： 无论你对一个单词还是对整个图书馆的书进行哈希处理，输出的长度都是一样的（例如 SHA-256 为 256 位）。 雪崩效应： 输入的极小变化（如更改一个字母）都会导致完全不同的哈希结果。 2. 为什么哈希是不可逆的？ 与 加密（Encryption） 不同，加密是一条双行道（你可以使用密钥加密然后解密），而 哈希 是一条单行道。一旦你得到了一个哈希值，你就无法“反推”得到原始数据。 “混合颜料”的比喻 想象你有一桶蓝色颜料和一桶黄色颜料。如果你把它们混合，你会得到绿色。虽然用蓝色和黄色调配绿色很容易，但从物理上讲，要把那桶绿色颜料完美地分离回原来的蓝色和黄色桶里是不可能的。 数学原因：信息丢失 哈希算法的设计初衷就是有意丢弃信息。例如，如果你有一个简单的“哈希规则”：“将数字相加并取最后一位数字”，那么： 输入 15 -> 1+5 = 6 输入 24 -> 2+4 = 6 如果你只看到结果 6，你根本无法知道原始输入是 15、24、33 还是其他任何组合。在 SHA-256 等现实世界的算法中，复杂性是天文数字，但原理是一样的：信息被压缩并丢弃。 3. 如果哈希不可逆，密码匹配是如何工作的？ 这是最常见的问题：如果网站将我的密码存储为哈希值且无法还原，它是如何知道我登录正确的呢？

在现代 Web 领域，安全不仅仅是一个功能，它是基础。随着应用程序变得越来越互联，理解跨域和跨服务器处理请求的微妙之处对于任何开发者来说都至关重要。 今天，我们将深入探讨每个 Web 开发者都应该掌握的三个核心概念：SSRF、CSRF 和 CORS。虽然它们听起来像字母缩写汤，但它们代表了 Web 应用程序安全的前线。 1. SSRF (服务端请求伪造) SSRF 是一种漏洞，攻击者可以通过它迫使服务端应用程序向攻击者选择的任意域名发起 HTTP 请求。 工作原理 想象一个 Web 应用程序接收一个 URL 作为输入（例如，用于获取个人资料图片或预览链接），然后从服务器向该 URL 发起请求。如果应用程序没有正确验证该 URL，攻击者就可以提供内部 IP 地址或回环地址（127.0.0.1）。 作为代理的服务器可能会从不向公共互联网开放的内部服务中获取敏感数据，例如： 云元数据： 在 AWS/GCP 上访问 169.254.169.254 以获取 IAM 凭据。 内部管理面板： 访问 Jenkins 或 Kubernetes 控制面板等内部工具。 端口扫描： 发现内部网络中运行的其他服务。 防御措施 白名单： 仅允许向预定义的信任域名列表发起请求。 输入验证： 确保 URL 使用允许的协议（例如仅限 https://），且不指向内部 IP 范围。 网络隔离： 确保 Web 服务器对内部资源的访问受到限制。 2. CSRF (跨站请求伪造) CSRF 是一种攻击，它诱导受害者的浏览器在受害者当前已登录的另一个网站上执行非预期的操作。

JSON Web Tokens (JWT) 已成为在各方之间以 JSON 对象形式安全传输信息的行业标准。在会话管理方面，开发者经常面临一个关键的架构决策：实现应该是无状态 (Stateless) 还是有状态 (Stateful)？ 这两种方法各有千秋，选择哪一种完全取决于应用的规模、安全要求和基础设施。 1. 无状态 JWT 实现 在纯无状态实现中，所有会话数据（用户 ID、角色、过期时间）都直接存储在 JWT 内部。服务器不需要在数据库或缓存中存储任何会话信息。 工作原理： 用户登录。 服务器生成一个包含用户详情的 JWT，并使用密钥对其进行签名。 服务器将 JWT 发送给客户端。 对于后续的每个请求，客户端都会发送该 JWT。 服务器验证签名并信任其中的数据，无需查询数据库。 优点： 可扩展性： 由于服务器不需要查找会话数据，因此更容易在多个服务器之间进行水平扩展。 性能： 减少了每个请求的数据库/缓存延迟。 去中心化： 非常适合微服务架构，不同的服务可以独立验证令牌。 缺点： 撤销问题： 令牌一旦发行，在过期前一直有效。如果不引入某种状态，很难在过期前撤销特定令牌（例如，如果用户注销或被封号）。 令牌大小： 在 JWT 中存储过多数据会导致头部过大，增加每个 HTTP 请求的开销。 2. 有状态 JWT 实现 有状态实现结合了 JWT 的便携性和传统会话的可控性。在这种模型中， JWT 通常包含一个唯一的会话 ID，而服务器在数据存储（如 Redis 或 SQL 数据库）中维护活跃会话的记录。