WebSocket 연결은 초기 **HTTP** 핸드셰이크를 통해 설정되며, **장기간 유지**되어 트랜잭션 시스템이 필요하지 않고 언제든지 양방향 메시징이 가능하도록 설계되었습니다. 이로 인해 WebSockets은 실시간 금융 데이터 스트림과 같은 **낮은 지연 시간 또는 서버에서 시작되는 통신**이 필요한 애플리케이션에 특히 유리합니다.
WebSocket 연결 설정에 대한 자세한 설명은 [**여기**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc)에서 확인할 수 있습니다. 요약하면, WebSocket 연결은 일반적으로 다음과 같이 클라이언트 측 JavaScript를 통해 시작됩니다:
-`Connection` 및 `Upgrade` 헤더는 WebSocket 핸드셰이크의 시작을 알립니다.
-`Sec-WebSocket-Version` 헤더는 원하는 WebSocket 프로토콜 버전을 나타내며, 일반적으로 `13`입니다.
-`Sec-WebSocket-Key` 헤더에는 Base64로 인코딩된 무작위 값이 전송되며, 이는 각 핸드셰이크가 고유함을 보장하여 캐싱 프록시 문제를 방지하는 데 도움이 됩니다. 이 값은 인증을 위한 것이 아니라 응답이 잘못 구성된 서버나 캐시에 의해 생성되지 않았음을 확인하기 위한 것입니다.
- 서버의 응답에 있는 `Sec-WebSocket-Accept` 헤더는 `Sec-WebSocket-Key`의 해시로, 서버가 WebSocket 연결을 열기로 의도했음을 확인합니다.
현재 로컬 네트워크에서 클라이언트가 **HTTP 웹소켓**에 연결되어 있는 것을 발견하면 [ARP Spoofing 공격](../generic-methodologies-and-resources/pentesting-network/#arp-spoofing)을 시도하여 클라이언트와 서버 사이에서 MitM 공격을 수행할 수 있습니다.\
* **Burp Suite**는 일반 HTTP 통신과 유사한 방식으로 MitM 웹소켓 통신을 지원합니다.
* [**socketsleuth**](https://github.com/snyk/socketsleuth) **Burp Suite 확장 프로그램**을 사용하면 Burp에서 웹소켓 통신을 더 잘 관리할 수 있습니다. **히스토리**를 얻고, **가로채기 규칙**을 설정하고, **일치 및 대체** 규칙을 사용하며, **Intruder** 및 **AutoRepeater**를 사용할 수 있습니다.
* [**WSSiP**](https://github.com/nccgroup/wssip)**:** "**WebSocket/Socket.io Proxy**"의 약자로, Node.js로 작성된 이 도구는 클라이언트와 서버 간의 모든 WebSocket 및 Socket.IO 통신을 **캡처, 가로채기, 사용자 정의 메시지 전송** 및 보기 위한 사용자 인터페이스를 제공합니다.
* [**wsrepl**](https://github.com/doyensec/wsrepl)은 특히 펜테스트를 위해 설계된 **대화형 웹소켓 REPL**입니다. **들어오는 웹소켓 메시지를 관찰하고 새로운 메시지를 보내는** 인터페이스를 제공하며, 이 통신을 **자동화**하기 위한 사용하기 쉬운 프레임워크를 제공합니다. 
* [**https://websocketking.com/**](https://websocketking.com/)은 **웹소켓을 사용하여 다른 웹과 통신**하기 위한 웹입니다.
* [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket)은 다른 유형의 통신/프로토콜과 함께 **웹소켓을 사용하여 다른 웹과 통신**하기 위한 웹을 제공합니다.
[**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course)에서 웹소켓을 사용하여 웹을 실행하는 코드를 찾을 수 있으며, [**이 게시물**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/)에서 설명을 찾을 수 있습니다.
**Cross-site WebSocket hijacking** 또는 **cross-origin WebSocket hijacking**은 WebSocket 핸드셰이크에 영향을 주는 **[Cross-Site Request Forgery (CSRF)](csrf-cross-site-request-forgery.md)**의 특정 사례로 식별됩니다. 이 취약점은 WebSocket 핸드셰이크가 **CSRF 토큰**이나 유사한 보안 조치 없이 **HTTP 쿠키**만을 사용하여 인증하는 경우 발생합니다.
그런 다음, 예를 들어, **웹소켓****서버**가 "**READY"**라는 메시지를 보내면 사용자의 대화 **기록을 다시 보냅니다**. 따라서 연결을 설정하는 **간단한 XSS** (희생자 사용자를 인증하기 위해 **쿠키**가 **자동으로 전송**됨) "**READY**"를 **보내면** 대화 **기록을 검색**할 수 있습니다.
이 블로그 포스트 [https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/](https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/)에서 공격자는 웹 소켓 통신이 발생하는 도메인의 **하위 도메인**에서 **임의의 JavaScript를 실행**하는 데 성공했습니다. **하위 도메인**이기 때문에 **쿠키**가 **전송**되었고, **Websocket이 Origin을 제대로 확인하지 않았기 때문에** 이를 통해 통신하고 **토큰을 도용**할 수 있었습니다.