bp靶场—websocket-messages to exploit vulnerabilities #
WebSocket 是一种在**单个 TCP 连接上进行全双工通信**的协议，允许客户端（如浏览器）和服务器之间实时交换数据，无需频繁的 HTTP 请求。它彻底改变了 Web 应用的实时性体验，广泛应用于聊天、实时数据监控、在线游戏等场景。是一个应用层协议 协议开头ws(http)或者wss(https)
BP介绍 #
BURP是可以抓取websocket数据的
可以发现我们输入什么我们发送服务器 服务器发送数据回来进行实时交互
F12也可以看数据发送
实验 #
这里要求我们注入xss 输入试试 - 发现不行
原来是进行了过滤我们修改抓包试试
可以看到这里的TYPE不是HTTP是WS 它们相互配合完成效果
成功
总结一下 #
websocket技术是一个实时交互技术 他和 HTTP区别有吗？
HTTP 协议的 “硬伤”：无法满足实时交互的核心需求 #
HTTP 是 “请求 - 响应” 模式的协议，即使通过技术手段 “保持连接”（如 HTTP/1.1 的 Connection: keep-alive 持久连接），也无法突破其本质限制：
-
通信方向受限：服务器不能主动发数据 HTTP 中，只有客户端主动发送请求（Request），服务器才能被动回应（Response）。服务器永远无法 “主动” 向客户端推送数据 —— 这是实时交互（如聊天、实时监控）的核心障碍。
例如：如果用 HTTP 做聊天软件，A 给 B 发消息后，服务器无法主动通知 B “有新消息”，B 必须不断手动刷新（或客户端定时发请求）才能收到，体验极差。
-
“保持连接” 不等于 “实时双向通信” HTTP/1.1 的
keep-alive确实能让 TCP 连接复用（避免每次请求重新握手），但连接的控制权仍在客户端：- 客户端不发请求时，服务器无法利用这个连接 “主动说话”；
- 连接的超时时间由服务器或客户端控制（通常几秒到几分钟），到期后会自动断开，无法 “永久保持”。
-
轮询 / 长轮询的低效性 为了模拟 “实时性”，HTTP 场景下常采用两种妥协方案，但都有明显缺陷：
-
轮询
：客户端每隔几秒发一次请求（如 “有新消息吗？”），服务器回复 “有 / 没有”。
- 问题：大量无效请求（比如 90% 的请求都是 “没有新消息”），浪费带宽和服务器资源；延迟高（至少等于轮询间隔）。
-
长轮询
：客户端发请求后，服务器不立即回复，而是 “挂起” 请求，直到有数据时才响应（或超时后回复空），客户端收到后立刻再发新请求。
- 问题：服务器需要维持大量 “挂起的请求”，消耗内存；超时机制仍会导致延迟；本质还是客户端 “被动等待”，而非服务器 “主动推送”。
-
websocket—–
二、WebSocket 的核心价值：解决 HTTP 的 “被动性” #
WebSocket 正是为解决上述问题而生，它的设计直接瞄准 “实时双向通信”：
- 全双工通信：服务器和客户端可随时互发数据
WebSocket 连接建立后，客户端和服务器地位平等 —— 双方可以在任何时候主动向对方发送数据，无需等待对方请求。
- 例如：聊天场景中，A 发消息后，服务器可立即通过 WebSocket 主动推送给 B，B 无需任何操作就能实时收到。
- 一次握手，永久连接（按需）
WebSocket 连接通过 HTTP 握手升级而来（仅一次 HTTP 请求），之后彻底脱离 HTTP 协议，基于纯 TCP 进行双向通信：
- 连接一旦建立，除非主动断开（客户端 / 服务器调用关闭），否则会一直保持；
- 数据传输时无需携带 HTTP 头部（仅少量 WebSocket 帧协议开销），比 HTTP 轮询高效 10 倍以上。
- 极低延迟和资源消耗
- 没有 HTTP 轮询的 “无效请求” 和 “头部冗余”（HTTP 头部通常几百字节到几 KB，WebSocket 帧头部仅 2-10 字节）；
- 服务器无需维持大量 “挂起的请求”，一个 WebSocket 连接即可支撑双向实时通信，资源占用极低。
WebSocket 的典型场景 #
正因为解决了 HTTP 的核心限制，WebSocket 成为实时交互场景的 “最优解”：
- 即时通讯（聊天软件、客服系统）；
- 实时数据监控（股票行情、系统监控面板）；
- 协作工具（多人在线文档、白板）；
- 在线游戏（实时同步玩家操作和状态）；
- 直播弹幕、实时投票等。
HTTP 协议的设计初衷是 “客户端请求 - 服务器响应” 的单向交互，即使保持连接，也无法突破 “服务器不能主动推送” 的本质限制；而 WebSocket 专为 “双向实时通信” 设计，通过一次连接实现全双工数据传输，彻底解决了 HTTP 在实时场景下的低效和延迟问题。