构建安全的Web应用：理解客户端与服务器端授权的边界

本文深入探讨了web应用中用户授权的安全性问题，指出客户端脚本（如带有`defer`标签的重定向脚本）无法有效阻止恶意用户绕过验证。文章强调了服务器端授权机制（如会话、jwt）的重要性，并提供了确保用户访问权限的正确实践，以构建真正安全的web应用，避免将核心安全逻辑暴露给客户端。

在Web应用开发中，确保用户拥有访问特定内容的权限是至关重要的。然而，许多开发者在实践中常会误将授权逻辑放置于客户端，认为通过JavaScript脚本进行检查和重定向足以保障安全。本文将详细阐述为何客户端授权机制是不可靠的，并提供正确的服务器端授权实践。

客户端授权的固有风险

将用户授权逻辑（例如，通过检查Cookie中的token来判断用户是否授权，并立即重定向未授权用户）置于客户端脚本中，即使该脚本带有defer标签，也存在严重的安全性漏洞。defer标签虽然可以延迟脚本的执行直到文档解析完毕，但它并不能阻止用户或恶意机器人绕过或篡改该脚本。

1. 用户完全控制客户端代码： 所有在用户浏览器中执行的代码，都完全受用户控制。这意味着用户可以通过多种方式来绕过你的客户端授权逻辑：

• 禁用JavaScript： 这是最直接且最有效的方式。如果用户禁用JavaScript，你的重定向脚本将根本不会执行，页面内容可能会直接加载。
• 浏览器开发者工具： 现代浏览器都提供了强大的开发者工具，允许用户：
  • 修改DOM： 在脚本执行前或执行时，用户可以检查并修改HTML结构，移除或禁用特定的脚本标签。
  • 篡改脚本： 用户可以在运行时调试和修改JavaScript代码，例如，直接跳过重定向逻辑。
  • 拦截网络请求： 用户可以拦截并修改发送到服务器的请求，甚至阻止某些响应，从而绕过客户端的检查。

2. defer标签的局限性：defer标签的作用是优化页面加载性能，确保脚本在HTML解析完成后、DOMContentLoaded事件触发前执行。它与安全性无关，无法提供任何安全保障。无论脚本何时执行，只要它在客户端运行，就面临被篡改或绕过的风险。

3. 永不信任客户端： 这是Web安全领域的一条黄金法则。客户端发送的任何数据、执行的任何逻辑，都应被视为不可信的。任何基于客户端判断的授权，都形同虚设。

正确的实践：服务器端授权

确保用户授权的唯一可靠方法是在服务器端进行验证。服务器拥有对数据和业务逻辑的完全控制权，并且其代码无法被用户直接访问或篡改。

1. 核心原则：在服务器端进行所有安全决策 服务器在响应任何请求之前，必须首先验证用户的身份和权限。只有当用户被确认为已授权时，服务器才应发送受保护的内容。否则，服务器应直接执行重定向或返回错误信息。

2. 常见的服务器端授权机制：

• 会话（Session）：

  

  秒哒

  秒哒-不用代码就能实现任意想法

  349

  查看详情
  • 用户登录成功后，服务器会创建一个会话，并生成一个唯一的会话ID。
  • 这个会话ID通常存储在服务器端（如内存、数据库或文件系统），并关联用户的身份和权限信息。
  • 服务器将这个会话ID通过Cookie发送给客户端。
  • 客户端在后续请求中会携带这个会话ID（Cookie），服务器接收到后，会根据会话ID查询其内部存储，验证用户身份和权限。
  • 如果验证失败，服务器直接拒绝请求或重定向。

• JSON Web Tokens (JWT)：

  • 用户登录成功后，服务器会生成一个JWT，其中包含用户的身份信息和签名。
  • JWT通常通过HTTP响应体发送给客户端，客户端将其存储在本地（如LocalStorage）。
  • 客户端在后续请求中将JWT作为Authorization头部（Bearer Token）发送给服务器。
  • 服务器接收到JWT后，会验证其签名，解析其中的用户信息，并据此判断用户权限。
  • JWT的优点是无状态，服务器无需存储会话信息，但需要妥善管理密钥和刷新机制。

3. 服务器端授权流程示例：

以下是一个概念性的服务器端授权流程，无论使用何种技术栈，其核心逻辑都是一致的：

1. 用户发起对受保护资源的请求 (例如: GET /dashboard)
        ↓
2. 服务器接收到请求
        ↓
3. 服务器检查请求中是否包含有效的身份凭证 (例如: 会话Cookie, JWT)
        ↓
4. 如果凭证缺失或无效：
   - 服务器立即执行重定向到登录页 (例如: HTTP 302 Location: /login)
   - 或返回未授权错误 (例如: HTTP 401 Unauthorized)
   - 终止请求处理
        ↓
5. 如果凭证有效：
   - 服务器根据凭证验证用户身份
   - 服务器进一步检查用户是否拥有访问该资源的权限 (授权)
        ↓
6. 如果用户无权访问：
   - 服务器返回禁止访问错误 (例如: HTTP 403 Forbidden)
   - 终止请求处理
        ↓
7. 如果用户已授权且有权限：
   - 服务器处理请求，从数据库或其他数据源获取受保护内容
   - 服务器将受保护内容发送给客户端

示例伪代码（PHP）：

<?php
// 假设这是一个服务器端脚本
session_start(); // 启动会话管理

// 检查用户是否已登录（例如，会话中是否存在用户ID）
if (!isset($_SESSION['user_id']) || empty($_SESSION['user_id'])) {
    // 用户未登录或会话无效，执行服务器端重定向
    header('Location: /login.php'); // 重定向到登录页面
    exit(); // 终止脚本执行，确保不会发送任何内容
}

// 进一步检查用户权限（如果需要更细粒度的授权）
// 例如，只有管理员才能访问此页面
// if ($_SESSION['user_role'] !== 'admin') {
//     header('Location: /access_denied.php');
//     exit();
// }

// 用户已登录且有权限，可以安全地加载页面内容
echo "<h1>欢迎来到受保护的仪表板！</h1>";
// ... 从数据库获取并显示用户专属数据 ...
?>

注意事项与总结

• 永远不要将安全核心逻辑暴露在客户端。 客户端脚本只应处理用户界面交互和数据展示，不应承担身份验证或授权的责任。
• 服务器端验证是唯一可靠的防线。 所有的用户输入、身份凭证和权限检查都必须在服务器端进行。
• 前端重定向仅用于用户体验。 如果你的前端应用需要根据用户状态进行路由跳转，这可以在客户端实现，但其前提是服务器已经验证了用户的访问权限。客户端的重定向只是为了更好的用户体验，而不是作为安全机制。
• 安全性是一个多层面的问题。 除了授权，还需要考虑身份验证、输入验证、数据加密、CSRF/XSS防护等多个方面。

通过将授权逻辑从客户端转移到服务器端，开发者可以构建出更加健壮和安全的Web应用程序，有效防止恶意用户绕过安全检查，保护敏感数据和功能。

以上就是构建安全的Web应用：理解客户端与服务器端授权的边界的详细内容，更多请关注php中文网其它相关文章！