这门课排出来的时候实验手册上就一句话完成 Web 应用安全基础实验内容包括环境搭建、协议分析与会话劫持。我当时以为很简单结果前前后后折腾了两个星期。做完之后回头想这其实是整个 Web 安全课程里含金量最高的一课——它把网络协议、HTTP 机制、身份认证和安全攻击串成了一条完整的线。先说这个实验适合谁如果你正在学 Web 安全、在做网络协议分析的课程设计或者准备打 CTF 但看不大懂抓包数据这篇内容踩过的坑和完整步骤可以直接照着操作。整套环境都是本地虚拟机搭建不涉及任何真实业务系统你在一台普通电脑上就能完整体验。我会按实验本身的顺序来讲先想清楚要做什么和为什么再把环境搭起来然后用 Wireshark 和 Burp 把 HTTP 协议分析透最后用 Cookie 把一场会话劫持从头到尾演一遍。1. 实验目标与思路拆解1.1 这个实验究竟在考察什么实验名字里三个关键词每一个都不是装饰。环境搭建考察的是你能否在可控条件下构造一个靶场协议分析考察的是你能不能看懂网络上真实流动的数据会话劫持则是前两项的交叉考核——你要理解 Session 的生成、传递和验证机制才能解释为什么一个简单的 Cookie 能变成攻击者的入场券。我身边不少同学第一反应是直接去搜会话劫持 exp想在真实站点上试一下这其实走错了方向。这个实验的重点不在打进去而在看懂过程。你只有先把 HTTP 无状态、Cookie 携带、Session 服务端存储这三个概念吃透劫持实验才不是机械地抄别人步骤。课程在做前置铺垫时前面还有 IP 协议分析、DNS 协议分析这类实验它们解决的是数据包怎么走的问题而 Web 安全实验要解决的是应用层怎么识别一个人的问题两者正好衔接。更直白地说这个实验考的是三层递进关系。第一层是你会不会搭环境这是动手能力。第二层是你能不能用抓包工具把一次 HTTP 请求拆成裸数据来分析这是观察能力。第三层是你能不能利用协议设计中被忽略的信任假设去复现攻击这是安全的思维模式——站在攻击者角度想问题。1.2 为什么是这三项技术的组合如果你只学协议分析不碰安全你会觉得 Cookie 只是个普通字段。如果你只学攻击不学协议你会不知道为什么改了 Cookie 就能伪装身份。这个实验的精妙之处就是把两者强行绑定在一起。举个例子TCP 三次握手建立连接、HTTP 请求在连接上发送、服务器通过响应头里的 Set-Cookie 下发 Session ID、浏览器后续请求通过 Cookie 头把 Session ID 送回——这一整条链路里Web 安全的攻防点到处都是。会话劫持的核心是服务器只凭 Cookie 里的 Session ID 来判断你是谁而这个 ID 在网络上是可被截获、可被伪造、可被重放的。如果不先把协议链路看明白你压根不知道攻击要落在哪个环节。后面我会反复提到一个观点安全实验的本质是验证协议的信任假设。HTTP 信任了 Cookie 里的一个随机字符串会话劫持就是对这个信任的滥用。我们从协议分析和攻击复现两个方向逼近同一个问题互为印证。1.3 环境选型为什么这么定这个实验我推荐三个角色一台靶机虚拟机、一台装有抓包和篡改工具的攻击机、一条能隔离的网络。具体选型上我用了 VirtualBox Ubuntu 20.04 做靶机物理机 Windows 装工具做攻击端网络模式选择仅主机Host-Only。为什么不选自己手写一个带登录功能的站点因为 DVWA 这类现成靶场自带多种安全级别可以在一套代码里对比低安全级别和高安全级别下 Cookie 行为的不同比自己写省事且更贴近真实场景。为什么不用桥接网络直接挂到局域网里因为实验里的攻击手法如果跑在真实局域网里很容易误伤其他设备而且 IP 分配不可控。仅主机网络相当于在虚拟机和物理机之间拉了一条私有网线隔离效果好IP 还能固定下来。至于工具抓包用 Wireshark数据包修改和重放用 Burp Suite。这两个都是安全从业者的日常工具免费版就够用后面我会标注清楚每一步用的是哪个模块。2. 环境搭建一台靶机、一套工具链2.1 网络模式与 IP 规划先说网络这是第一个大坑。很多人在实验里用的是 NAT 模式虚拟机虽然能上网但物理机访问不到虚拟机的 Web 服务浏览器里怎么敲 IP 都是拒绝连接。原因很简单NAT 模式下虚拟机对外是隐藏的数据出去要经过宿主机的地址转换外部主动发起的请求进不来。正确做法是在 VirtualBox 里给靶机添加第二块网卡选仅主机网络。装完系统后我在 Ubuntu 里把网卡配置成静态 IP10.10.10.10子网掩码 255.255.255.0。物理机同样在这个网段比如10.10.10.1。两边互相 ping 得通实验网络就通了。# Ubuntu 22.04 用 netplan 配置静态 IP sudo nano /etc/netplan/01-network-manager-all.yaml # 写入以下配置 network: version: 2 ethernets: enp0s8: dhcp4: no addresses: [10.10.10.10/24] sudo netplan apply注意仅主机网络的默认网段经常是 192.168.56.x这没问题。我这里特意选 10.10.10.x 是为了避免和家里路由器网段冲突实际以你的 VirtualBox 全局设置里看到的网卡信息为准。IP 规划这事其实很值得多想一步。固定靶机 IP 不仅是为了方便浏览器访问更重要的是后面的协议分析实验里Wireshark 过滤条件可以直接写ip.addr 10.10.10.10一眼就能把靶机相关流量筛出来数据包干净很多。2.2 DVWA 靶场部署步骤DVWADamn Vulnerable Web Application是我最喜欢的 Web 安全入门靶场没有之一。它的部署依赖 LAMP 环境也就是 Linux、Apache、MySQL、PHP。先装基础组件再把 DVWA 源码放到 Web 目录下。整个过程用下面的命令就能走通我在安装过程中碰到的两个典型问题会单独标注。# 更新并安装 LAMP 环境 sudo apt update sudo apt install -y apache2 mysql-server php php-mysqli libapache2-mod-php git # 拉取 DVWA 源码并放到网站根目录 cd /var/www/html sudo git clone https://github.com/digininja/DVWA.git sudo mv DVWA dvwa # 准备 DVWA 配置文件 cd /var/www/html/dvwa/config sudo cp config.inc.php.dist config.inc.php # 创建测试文件验证 PHP 是否正常 echo ?php phpinfo(); ? | sudo tee /var/www/html/test.php这里有个很多人必踩的坑DVWA 的 config.inc.php 里数据库密码默认是空字符串但 MySQL 8 默认 root 用的是 auth_socket 认证PHP 连数据库时会报 Access denied。我当时卡了很久最后是在 MySQL 里创建了一个专用账号给 DVWA 用再把 config 里的密码改成这个账号的密码。CREATE USER dvwalocalhost IDENTIFIED BY dvwa_pass; GRANT ALL PRIVILEGES ON dvwa.* TO dvwalocalhost; FLUSH PRIVILEGES;完成之后访问http://10.10.10.10/dvwa/setup.php点页面下方的Create / Reset Database按钮DVWA 会自动建库并初始化数据。看到绿色提示就说明环境通了。整个实验完全本地化不依赖任何在线的免费 Web 服务器网络断了也不影响。2.3 工具链装配与关键验证靶机就绪后物理机上要装三样东西Wireshark、Burp Suite Community 免费版、Firefox 浏览器及 Cookie-Editor 插件。Wireshark 抓包需要管理员权限安装时务必把 WinPcap 或 Npcap 核心组件勾选上否则抓不到任何数据包。Burp Suite 打开后默认会监听本机 8080 端口我需要在浏览器里把流量转到它的监听端口上。这一步很多人容易漏掉不设置的话 Burp 只会空转什么都拦截不到。Firefox 在连接设置里选择手动配置HTTP 和 HTTPS 都填127.0.0.1:8080。工具装完先做个验证打开 Wireshark 选择仅主机网卡开始抓包然后用浏览器访问http://10.10.10.10/dvwa/login.php。如果 Wireshark 里能看到大量 HTTP 流量、Firefox 那边的 Burp 拦截面板跳出了请求就说明整个实验的数据通路已经完全打通。请注意Burp 拦截模式默认是打开的看到请求被暂停在面板里是正常现象点击Forward按钮放行即可。3. 协议分析把 HTTP 和 Cookie 看穿3.1 一次登录请求的前世今生协议分析不是单纯地抓包看看而是要能讲清楚一个完整请求从用户按下回车到页面渲染中途经历了哪几层协议、每个字段是什么意思。我在这次实验里把下面四步完整过了一遍每一步都在 Wireshark 里有对应证据。第一步是 DNS 解析。浏览器先要把10.10.10.10这个 IP 解析出来——因为这里用的是 IP 直连DNS 界面很简单但如果换成域名就能在抓包里看到 DNS 请求和响应包。前置的头歌平台上做过的 DNS 协议分析实验在这里直接派上了用场。第二步是 TCP 三次握手。抓包列表里最显眼的就是三个连续的数据包SYN、SYN-ACK、ACK。这个过程的直观价值在于它让你意识到连接建立和应用层数据发送是分开的两件事HTTP 请求只是在三次握手完成之后通过这个已经建立的可靠通道发送的数据。第三步是 HTTP 请求与响应。Wireshark 里用过滤条件http就能把应用层流量筛出来。点开一个 POST 请求包能看到请求行、头部字段和数据体。第四步是浏览器渲染这一步不在抓包范围内但值得心里过一遍浏览器拿到 HTML、CSS、JavaScript 之后再展示给用户。我建议你在做协议分析时不要只看 Wireshark 的解析结果而是右键把原始数据复制出来用十六进制和 ASCII 对照着看一遍。你会直观地看到 HTTP 头部其实都是明文Cookie 字段就这样赤裸裸地躺在数据包里。这也是后面会话劫持能成立的物理基础。3.2 Session 与 Cookie 的工作机制HTTP 协议本身是无状态的意思是服务器处理完一个请求后不会自动记住这个客户端是谁。但 Web 应用几乎都有登录功能登录成功之后服务器得知道接下来这段对话属于 admin 这个用户于是 Session 机制出现了。整个机制可以缩成一句话用户登录成功后服务器在内存或数据库里创建一个会话对象生成一个随机字符串作为 Session ID通过响应头Set-Cookie: PHPSESSIDxxxx下发给浏览器浏览器再次请求时在请求头里带上Cookie: PHPSESSIDxxxx服务器根据这个 ID 查出对应的会话对象才知道当前用户是谁。我在 DVWA 环境里用登录请求验证了这一点。响应包里清清楚楚写着 Set-Cookie 头请求包里则有对应的 Cookie 头。这里值得写一段类比Cookie 就像你进游泳馆时发的手环手环上的号码就是 Session ID服务台那边登记着号码对应的人是哪个会员。服务员不认人脸只认手环号码。会话劫持的本质就是捡到或偷看到别人的手环号码然后让服务员用这个号码去服务台查出对方的信息。3.3 抓包实操分析一次完整登录这部分我逐步记录了自己的实际抓包过程。先清空浏览器缓存和历史记录打开 Wireshark 选择仅主机网卡过滤条件设为http ip.addr 10.10.10.10。接着打开无痕窗口访问 DVWA 登录页输入 admin / password点击登录然后回到 Wireshark 停止抓包。抓包结果里按顺序能看到次数不多、但信息量很足的请求。第一个是 GET 请求登录页面第二个是 POST 提交账号密码。点开 POST 包里的HTML Form URL Encoded字段能看到usernameadminpasswordpassword数据体是明文的。响应包里则有两个关键头Location: index.php表示登录成功跳转Set-Cookie: PHPSESSIDXXXX表示服务端下发了会话凭据。同样的流量在 Burp Suite 里看起来更舒服。HTTP History 面板能按时间列出所有经过的请求和响应点开任一条就能看到完整的头和体。我第一次做的时候两边对照着看很快记住了一件事服务器识别身份并不靠请求里的用户名它只认 Cookie 里的 PHPSESSID 值。这个认知直接决定了后面实验的操作方式。4. 会话劫持实验在靶场上完整复现4.1 劫持原理为什么 Cookie 就是身份凭证会话劫持Session Hijacking的教科书定义是攻击者通过某种手段获取合法用户的 Session ID然后使用该 ID 与服务器交互从而伪装成该用户执行操作。原理听起来简单但每一步都需要落到协议细节上。首先Session ID 必须通过某种方式从浏览器传到服务器这个传递通道如果是明文 HTTP局域网内任何一台设备上的抓包工具都能看到完整的 Cookie 头。其次服务器默认把收到的 Session ID 当作有效凭据不校验请求来源是否真的是当初领取该 Session ID 的浏览器。最后只要攻击者拿到的 Session ID 还没过期他就能一直以受害者的身份访问应用。我当时的实验思路是先让浏览器 A 登录 DVWA 拿到一个合法的 PHPSESSID然后在浏览器 B 里把这个 PHPSESSID 写入 Cookie如果刷新后 B 直接进入登录状态就说明服务器只认 Session ID不认客户端这个假设被验证了。实验本身不需要注入、不需要破解任何东西就是直接使用了协议的设计逻辑特别适合用来建立协议信任可以被滥用的安全直觉。提示本实验完全用于本地靶场教学环境会话劫持手法不应在任何未授权系统上尝试。安全测试的基本原则是先授权后测试这个习惯从入门第一天就要养成。4.2 复现步骤全记录从复制 Cookie 到修改重放具体操作我拆成了五个步骤每一步都有明确的观察目标。第一步在 Firefox 里打开 DVWA 登录页登录成功。登录完成后不要关页面调出 Cookie-Editor 插件可以看到当前 Cookie 列表里有一个名字为PHPSESSID的项点击它查看 value复制这串值。这个值就是服务器分配给当前浏览器的会话编号。第二步打开 Firefox 的另一个无痕窗口相当于另一个浏览器访问http://10.10.10.10/dvwa/login.php。这时候它是未登录状态页面停留在登录表单。打开 Cookie-Editor把刚才复制的 PHPSESSID 值作为一个新 Cookie 写入这个窗口Domain 填10.10.10.10Path 填/。第三步在同窗口里直接访问http://10.10.10.10/dvwa/index.php。按 F5 刷新页面直接进入了 admin 的登录后界面没有出现登录表单。到这一步复现已经成功了第二个浏览器拿到了第一个浏览器的 Session ID服务端认为它们是同一个用户。第四步用 Burp 把这条链路再做一遍来加深理解。回到正常窗口先在 Burp 里确认拦截开关打开然后刷新 DVWA 页面。当请求停在 Burp 的拦截面板时找到Cookie头手动把它改成第一步里记录的 PHPSESSID 值再点 Forward 放行。页面同样进入了登录状态。第五步做一次对照实验。在 Wireshark 里再次抓包对比未登录请求和登录后的请求。未登录请求的 Cookie 头要么不存在要么是服务器新下发的陌生 Session ID登录后的请求Cookie 头和浏览器的 PHPSESSID 一一对应。如果翻看响应包还能看到Set-Cookie里是否有HttpOnly、Secure、SameSite这些属性它们直接决定了劫持能否得手。我建议你把步骤 3 的刷新操作重复几遍每次刷新都确认页面状态。你会发现攻击的价值在于持久性只要服务器端的会话没过期被伪造的 Session ID 就能一直使用这比一次性注入的攻击更有威胁。4.3 从攻击反推防御为什么 HTTPS 和 HttpOnly 能挡住攻击完成复现后我强烈建议你做一次防御视角回看否则这个实验的意义就削弱了一半。会话劫持的根源在于 Cookie 数据被明文传递、Session ID 能被第三方读取。顺着这个思路防御手段其实是可以推理出来的。第一个手段是启用 HttpOnly 属性。它的作用是禁止 JavaScript 读取document.cookie。注意它防的不是抓包而是 XSS 攻击——即使攻击者注入了脚本也无法直接拿到 Cookie 值。这个属性对抓包式劫持没用但防住了 XSS 这条最常见的窃取路径。第二个手段是启用 Secure 属性。这个属性告诉浏览器只有在 HTTPS 连接下才允许把这个 Cookie 发出去。加上 HTTPS 加密后即使 Wireshark 在同一网段抓包看到的也是 TLS 密文Session ID 不会以明文形式暴露。攻击者拿不到可用的 Cookie上一节那些修改重放的操作就全都不成立了。第三个手段是缩短会话生命周期。服务端设置不活跃超时时间比如 20 分钟后自动销毁 Session登录成功后立即重置 Session ID防止会话固定攻击——也就是攻击者先把自己拿到的 Session ID 塞给受害者等受害者登录成功后再用同一个 ID 顶替进去。DVWA 高安全级别会展示部分这些配置的作用你不妨把 DVWA Security 从 low 切到 high重新做一遍同样的操作看看哪里开始行不通了。这些手段我整理成了一张对照表方便你理解每个防御点对应哪种攻击路径。防御手段作用链路防住的攻击防不住的攻击全站 HTTPS Secure Cookie传输加密明文抓包窃取 Cookie本机被控后的直接读取HttpOnly禁止脚本读 CookieXSS 窃取 Cookie抓包、中间人SameSite限制跨站携带 Cookie部分 CSRF同站内的恶意操作会话超时 / 登录后重置 Session ID缩短有效时间窗口长期复用旧 ID瞬时窗口内的重放异常检测 / 绑定 IP、设备指纹增加攻击者伪装成本大范围 Cookie 盗用伪造指纹的定向攻击5. 常见问题与排查技巧实录5.1 实验中的高频报错与解决办法这个实验虽然步骤清晰但我在实际操作中还是踩了不少坑也帮同学排查过几次。下面这五个问题是最常出现的整理成速查表供你直接对照。问题现象可能原因排查思路和解决动作浏览器访问 10.10.10.10 拒绝连接靶机 Apache 没启动或网卡 IP 配错先在靶机上执行ip addr确认 IP再sudo systemctl status apache2看服务状态DVWA 页面提示无法连接数据库MySQL 账号密码没同步到 config 文件核对config.inc.php里的数据库用户名和密码用 mysql 客户端命令行测试连接DVWA 页面白屏没有按钮config 文件缺失或目录权限不足确认存在config.inc.php并给hackable/uploads目录设置 777 权限浏览器访问时 Wireshark 里看不到 HTTP 流量抓包网卡选错或浏览器走了缓存重新选择仅主机网卡清浏览器缓存后强制刷新过滤条件换成tcp.port 80试试Burp 拦截面板里没有请求浏览器没有配置到 Burp 监听端口确认 Firefox 连接设置里 HTTP/HTTPS 都填了 127.0.0.1:8080Burp 的监听状态是 Running修改 Cookie 后仍然无法进入登录状态复制的 PHPSESSID 不对或会话已过期重新登录一次用 Cookie-Editor 核对域名和路径字段改完直接访问 index.php 刷新除了表里的问题还有个隐蔽的小坑如果你用的是 Chrome 而不是 FirefoxBurp 配置到系统代理之后 Chrome 可能不走自定义设置而且 Chrome 对自签名证书的管理比 Firefox 麻烦。Firefox 做这种安全实验的体验明显更顺我建议全程统一用 Firefox避免工具兼容性问题消耗时间。5.2 避坑技巧与个人实操心法几个容易被忽略的操作细节值得单独拿出来说。第一做会话劫持实验时两个浏览器窗口一定要隔离 Cookie 存储最好一个普通窗口一个无痕窗口否则浏览器共享 Cookie 会导致第二个窗口不需要改也能进入登录状态的假象。第二Wireshark 抓包时如果数据量太大先按tcp.stream eq 0只看第一对 TCP 连接一条流一条流地分析比全部混在一起看高效得多。第三修改 Cookie 值的实验动作最好慢一点、分步做——先看服务端响应再改请求再观察效果形成完整的因果链。我自己在整个实验里最深的体会是安全攻击一点也不神秘它就是利用设计者没有意识到的信任假设。DVWA 靶场里低安全级别和普通站点的差别往往只是一个Secure标志位或者一道 HTTPS 配置。攻击者能做到哪一步很大程度上取决于应用开发者少做了哪一步,这才是这门实验真正想传递的思维方式。实验做完之后如果你想继续往里走我建议两个方向。一是去玩 CTF 的 Web 入门题很多题目本质上就是在练习协议分析加 Cookie 利用ctfshow 这类平台上有系统的 Web 技能树配合这次实验建立的思路会顺手很多。二是从攻击视角转向防御视角用 Acunetix 这类漏洞扫描器去扫描 DVWA对照报告里描述的漏洞成因把你四十分钟就能复现的实验过程变成三十秒就能识别的风险画像。这条路走通之后Web 安全的大门才算真正推开。