DVWA Weak Session IDs High 的 Cookie dvwaSession 刷新不出来的原因是什么？
摘要：在做 DVWA 的 Weak Session IDs（会话 ID 安全性不足）High 难度实验时，发现了一个很奇怪的问题：按照正常流程点击 Generate 按钮，不管是用浏览器的开发者工具、Cookie 编辑插件，还是 HackBar，
DVWA Weak Session IDs High 难度踩坑记录：Cookie 为什么死活看不到？
发布时间： 2026-03-01
分类： Web 安全 / DVWA 实战
前言
在做 DVWA 的 Weak Session IDs（会话 ID 安全性不足）High 难度实验时，发现了一个很奇怪的问题：按照正常流程点击 Generate 按钮，不管是用浏览器的开发者工具、Cookie 编辑插件，还是 HackBar，都看不到 dvwaSession 这个 Cookie。
这不是操作问题，而是一个真实的 Bug，根源涉及到浏览器对 Cookie 规范的实现细节。本文记录完整排查过程，并深入解释背后的原因。
实验环境
DVWA（本地 phpStudy 搭建）
访问地址：http://dvwa:8564
难度：High
工具：Burp Suite、浏览器 F12
一、各难度 Session ID 生成方式
在分析问题之前，先了解 DVWA 各难度的实现方式：
难度
生成方式
安全问题
Low
数字递增（1、2、3...）
完全可预测，直接枚举
Medium
Unix 时间戳
可根据时间推算
High
MD5(递增数字)
看似随机，实则可预测
Impossible
真随机数 + 时间戳 + 盐值
安全
High 难度的核心源码如下：
$_SESSION['last_session_id_high']++;
$cookie_value = md5($_SESSION['last_session_id_high']);
setcookie("dvwaSession", $cookie_value, time()+3600,
"/vulnerabilities/weak_id/", $_SERVER['HTTP_HOST'], false, false);
逻辑很清晰：每次点击 Generate，将一个递增的数字做 MD5，结果作为 Cookie 写入浏览器。
理论上，访问几次后应该能看到类似这样的 Cookie：
dvwaSession=c4ca4238a0b923820dcc509a6f75849b （MD5(1)）
dvwaSession=c81e728d9d4c2f636f067f89cc14862c （MD5(2)）
dvwaSession=eccbc87e4b5ce2fe28308fd9f2a7baf3 （MD5(3)）
但实际上浏览器里根本看不到这个 Cookie。
二、排查过程
步骤 1：确认功能是否正常运行
页面没有报错，看起来一切正常。
步骤 2：检查浏览器 Cookie
打开 F12 → Application → Cookies：
只能看到 PHPSESSID 和 security，dvwaSession 不见了。
步骤 3：换工具确认
分别尝试了：
浏览器自带开发者工具
Cookie Editor 插件
HackBar
结果一致，全都看不到 dvwaSession。
步骤 4：用 Burp Suite 抓包
在 BP 的 HTTP History 里找到 Generate 的请求，查看响应包：
响应包里能看到：
Set-Cookie: dvwaSession=d3d9446802a44259755d38e6d163e820;
expires=...;
Max-Age=3600;
path=/vulnerabilities/weak_id/;
domain=dvwa:8564
服务器确实发送了 Set-Cookie，但浏览器就是不存！
步骤 5：定位问题
仔细看 Set-Cookie 的内容，发现问题所在：
domain=dvwa:8564
domain 字段里包含了端口号。
三、根本原因：Cookie 规范不支持端口号
RFC 6265 的规定
Cookie 的行为由 RFC 6265 规范定义，其中明确指出：
Cookie 的作用域由 domain、path、secure 属性决定，端口号不参与 Cookie 的作用域判断。
这意味着 Cookie 的 domain 字段设计上就不支持带端口号，这是一个历史遗留问题——Cookie 规范诞生于网站几乎都使用标准端口（80/443）的年代，端口的区分从未被纳入考虑。