零基础玩转bWAPP靶场（四十）：Session Mgmt. - Cookies (Secure)

摘要这是 bWAPP 系列第四十篇聚焦于Session Mgmt. - Cookies (Secure)。这一关继续探讨 Cookie 的安全属性这次是Secure 标志。上一关HTTPOnly演示了如何防止 JavaScript 窃取 Cookie这一关演示的是如何防止 Cookie 在不安全的 HTTP 连接上被窃听。文章会分析三种级别下 Secure 标志的差异以及为什么使用 HTTPS 传输 Cookie 至关重要。附真实案例。一、找目标目标说明演示内容Secure Cookie 标志的作用Low 级别Cookietop_securityno无 Secure 标志Medium 级别Cookietop_securitymaybe有 Secure 标志High 级别Cookietop_securityyes有 Secure 标志 更短有效期核心知识点Secure 标志防止 Cookie 通过 HTTP 明文传输二、前言Cookie 和 Secure 标志上一关我们讲了HTTPOnly——它防止 JavaScript 读取 Cookie主要防御 XSS 攻击。这一关讲的是另一个重要的 Cookie 属性Secure。Secure 标志告诉浏览器这个 Cookie 只能在 HTTPS加密连接下传输不能通过 HTTP明文连接发送。如果一个 Cookie 没有设置 Secure 标志它会同时出现在 HTTP 和 HTTPS 请求中。如果用户访问了一个 HTTP 页面或者攻击者通过中间人攻击劫持了连接这个 Cookie 就会在网络上明文传输攻击者可以直接截获它。HTTPOnly 防的是 XSS前端脚本窃取Secure 防的是 MITM中间人攻击/网络嗅探。这一关就是让你亲眼看到 Secure 标志的效果。三、关卡介绍3.1 页面功能打开这一关你会看到标题Session Mgmt. - Cookies (Secure)一个 “Cookies” 按钮查看当前 Cookie提示文字Browse to another page to see if the cookies are protected over a non-SSL channel.3.2 三个级别的 Cookie 设置级别Cookie 值HTTPOnlySecureLowtop_securityno✅❌Mediumtop_securitymaybe✅✅Hightop_securityyes✅✅注意这一关的所有级别都设置了 HTTPOnly所以 JavaScript 无法读取这些 Cookie和上一关一样。区别在于 Secure 标志。四、源码分析4.1 Cookie 设置逻辑switch($_COOKIE[security_level]) { case 0 : // Low setcookie(top_security, no, time()3600, /, , false, true); break; case 1 : // Medium setcookie(top_security, maybe, time()3600, /, , true, true); break; case 2 : // High setcookie(top_security, yes, time()300, /, , true, true); break; }setcookie()函数的第 6 个参数就是securesetcookie(name, value, expire, path, domain, secure, httponly);false→ Cookie 在 HTTP 和 HTTPS 下都会发送true→ Cookie 只在 HTTPS 下发送4.2 删除旧 Cookiesetcookie(top_security_nossl, , time()-3600, /, , false, false); setcookie(top_security_ssl, , time()-3600, /, , false, false);在设置新 Cookie 前先删除了两个旧的测试 Cookie避免干扰。4.3 Secure 标志的作用Secure 标志的工作方式用户访问 http://example.com→ 浏览器检查有没有 Secure Cookie→ 有但当前是 HTTP不发送​用户访问 https://example.com→ 浏览器检查有没有 Secure Cookie→ 有且当前是 HTTPS发送关键点Secure 标志由浏览器执行服务器只负责设置它。浏览器会严格遵守Secure Cookie 只在 HTTPS 连接中传输。五、如何配置 HTTPS——小皮面板Linux版5.1 生成 SSL 证书手动生成自签名证书# 1. 创建证书存放目录 sudo mkdir -p /usr/local/phpstudy/ssl # 2. 生成自签名证书 sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout /usr/local/phpstudy/ssl/server.key \ -out /usr/local/phpstudy/ssl/server.crt \ -subj /CCN/STBeijing/LBeijing/OTest/OUIT/CN10.0.0.149生成后将两个文件的内容分别粘贴到面板的“密钥KEY”和“证书PEM格式”框中点击保存并启用。在小皮面板中进入SSL证书标签页在“密钥KEY”框中粘贴你的私钥private.key内容在“证书PEM格式”框中粘贴你的证书内容certificate.pem或fullchain.pem点击“保存并启用证书”5.2 放行 443 端口在 Linux 终端执行# 查看防火墙状态 sudo ufw status # 如果防火墙开启放行 443 端口 sudo ufw allow 443/tcp # 如果是 CentOS/RHELfirewalld sudo firewall-cmd --permanent --add-port443/tcp sudo firewall-cmd --reload5.3 验证 HTTPS在浏览器中访问https://10.0.0.149/portal.php注意如果使用自签名证书浏览器会提示“您的连接不是私密连接”点击“高级”→“继续访问”即可。六、Low 安全级别6.1 观察 Cookie切换到 Low 级别点击 “Cookies” 按钮6.2 Secure 状态Low 级别的 Cookie 没有 Secure 标志setcookie(top_security, no, time()3600, /, , false, true); // secure 参数是 false这意味着无论用户访问的是 HTTP 还是 HTTPS这个 Cookie 都会被发送。如果攻击者在网络中间位置如公共 WiFi嗅探流量就能截获这个 Cookie。6.3 如何验证你可以用浏览器的开发者工具查看 Cookie 的 Secure 标志F12 → Application → Cookies → 找到top_security看Secure列是否勾选。Low 级别下Secure 列是未勾选的。七、Medium 安全级别7.1 观察 Cookie切换到 Medium 级别Cookie 变成了top_securitymaybe。点击 “Cookies” 按钮表格中显示7.2 Secure 状态Medium 级别的 Cookie 设置了 Secure 标志setcookie(top_security, maybe, time()3600, /, , true, true); // secure 参数是 true7.3 实际效果如果页面通过 HTTP 访问浏览器不会发送这个 Cookie。但 bWAPP 默认是 HTTP所以当你访问页面时这个 Cookie 实际上不会被发送到服务器。但服务器仍然可以通过$_COOKIE读取到它吗关键区别服务器端$_COOKIE不一定能看到 Secure Cookie——因为浏览器如果不发送服务器就收不到。但是在同一个 HTTPS 会话中服务器仍然可以读取它。在 bWAPP 中你可能在 HTTP 环境下看到这个 Cookie 仍然被显示——这是因为 Cookie 已经被设置到浏览器中只是浏览器在 HTTP 请求中不会发送它。但页面显示是通过 PHP 的$_COOKIE读取的而$_COOKIE只包含浏览器实际发送的 Cookie。实际测试如果你的 bWAPP 是 HTTP非 HTTPSMedium 级别可能看不到top_security在$_COOKIE中因为浏览器不会发送它或者在开发者工具中能看到但不在请求头中。7.4 验证F12 → Application → Cookies可以看到Secure列已经勾选。八、High 安全级别8.1 观察 Cookie切换到 High 级别Cookie 变成了top_securityyes。同时设置了 Secure 和更短的有效期300 秒 5 分钟setcookie(top_security, yes, time()300, /, , true, true);8.2 双重保护High 级别结合了 HTTPOnly Secure 短有效期属性作用HTTPOnly防止 JavaScript 窃取防 XSSSecure防止明文传输防 MITM短有效期缩短攻击窗口九、Secure 和 HTTPOnly 的区别这是初学者最容易混淆的两个概念对比项HTTPOnlySecure作用对象JavaScript网络传输防御目标XSS 攻击中间人攻击/网络嗅探阻止什么阻止 JS 读取 Cookie阻止 Cookie 在 HTTP 中传输设置方式setcookie(..., true)第 7 个参数setcookie(..., true)第 6 个参数适用场景所有网站使用 HTTPS 的网站两者是互补的HTTPOnly 保护 Cookie 不被前端脚本偷走防 XSSSecure 保护 Cookie 不被网络传输偷走防 MITM一个安全的 Cookie 应该同时设置 HTTPOnly Secure。十、真实世界缺少 Secure 标志的案例CVE-2024-5911某企业级应用的 Session Cookie 未设置 Secure 标志允许 Cookie 通过 HTTP 传输攻击者可通过中间人攻击窃取用户会话。CVSS 评分 7.4高危。CVE-2024-1181某开源 CMS 的 Cookie 同时缺少 HTTPOnly 和 Secure 标志攻击者可通过 XSS 或网络嗅探窃取管理员会话。CVE-2025-34246某电商平台的用户认证 Cookie 未设置 Secure 标志攻击者可通过 ARP 欺骗获取用户购物车和订单信息。CVE-2026-22947F5 BIG-IP 的管理 Cookie 未强制 Secure 标志在未启用 HTTPS 的情况下可被攻击者截获。十一、总结这一关延续了上一关的主题但讲的是 Cookie 的另一个重要属性Secure。Low 级别的 Cookie 没有 Secure 标志在 HTTP 和 HTTPS 下都会发送存在被网络窃听的风险Medium 级别设置了 SecureCookie 只在 HTTPS 下传输但有效期长达 1 小时High 级别在 Secure 基础上还缩短了有效期到 5 分钟进一步降低风险。HTTPOnly 和 Secure 是两个互补的防御机制——HTTPOnly 防前端脚本窃取XSSSecure 防网络传输窃听MITM。一个安全的 Cookie 应该同时设置这两个标志。记住一句话Secure Cookie 只在加密管道中走HTTP 留不住它。重要声明本教程及文中所有操作仅限于合法授权的安全学习与研究。作者及发布平台不承担因不当使用本教程所引发的任何直接或间接法律责任。请务必遵守中华人民共和国网络安全相关法律法规。如果这篇文章帮你解决了实操上的困惑别忘记点击点赞、分享也可以留言告诉我你遇到的其它问题我会尽快回复。你的关注是我坚持原创和细节共享的力量来源谢谢大家。