本文深入探讨了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）：
用户登录成功后，服务器会创建一个会话，并生成一个唯一的会话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 "欢迎来到受保护的仪表板！
";// ... 从数据库获取并显示用户专属数据 ...?>
注意事项与总结
永远不要将安全核心逻辑暴露在客户端。 客户端脚本只应处理用户界面交互和数据展示，不应承担身份验证或授权的责任。服务器端验证是唯一可靠的防线。 所有的用户输入、身份凭证和权限检查都必须在服务器端进行。前端重定向仅用于用户体验。 如果你的前端应用需要根据用户状态进行路由跳转，这可以在客户端实现，但其前提是服务器已经验证了用户的访问权限。客户端的重定向只是为了更好的用户体验，而不是作为安全机制。安全性是一个多层面的问题。 除了授权，还需要考虑身份验证、输入验证、数据加密、CSRF/XSS防护等多个方面。
通过将授权逻辑从客户端转移到服务器端，开发者可以构建出更加健壮和安全的Web应用程序，有效防止恶意用户绕过安全检查，保护敏感数据和功能。
以上就是构建安全的Web应用：理解客户端与服务器端授权的边界的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1531628.html
微信扫一扫 
支付宝扫一扫 
