[Playbook] WebSocket 진단 Cheat Sheet

목차

이 문서는 WebSocket 진단 중 어느 지점을 조작할지 정하고 다음 테스트를 고르기 위한 빠른 참고서다. WebSocket을 통해 드러나는 개별 취약점의 페이로드 문법은 각 주제의 Playbook으로, 상세 풀이는 Write-up으로 연결한다.

승인된 테스트 환경과 실습에서만 사용한다. WebSocket 메시지는 다른 사용자에게 즉시 중계되는 경우가 많으므로, 처음부터 실행 페이로드를 보내지 않고 무해한 marker로 도달 지점만 확인한다. CSWSH는 연결 수립 여부까지만 확인하고, 실제 사용자 데이터를 외부로 전송하지 않는다.

30초 진단 흐름

1. WebSockets history에서 엔드포인트, 핸드셰이크, 메시지 형식을 기록한다.
2. 클라이언트가 값을 인코딩·검증하는지, 프록시에서 원문을 보내면 통과하는지 비교한다.
3. 메시지가 나에게만 돌아오는지, 다른 사용자에게 중계되는지 확인한다.
4. 핸드셰이크에 CSRF 토큰과 Origin 검증이 있는지 확인한다.
5. 메시지, 핸드셰이크, 연결(CSWSH) 중 조작할 지점을 선택한다.

1. 연결 파악

페이로드보다 먼저 연결 자체를 기록한다. WebSocket은 핸드셰이크 한 번으로 이후 모든 메시지의 권한과 컨텍스트가 결정되므로, 연결 정보가 곧 공격면의 범위다.

Sec-WebSocket-Key와 Sec-WebSocket-Accept는 규격상 핸드셰이크 확인용 값이며 인증이나 CSRF 방어 역할을 하지 않는다. 예측 불가능한 값처럼 보이지만 방어로 계산하지 않는다.

• 개념: WebSocket 토픽 정리

2. 클라이언트 측 처리 우회

브라우저 입력창을 거치는 검증과 인코딩은 방어가 아니다. 메시지는 프록시에서 직접 만들어 보낼 수 있으므로, 같은 값을 두 경로로 보내 비교하는 것이 첫 단계다.

입력창으로 전송한 값 ↔ 프록시에서 직접 전송한 값

JSON 메시지는 message, user, room처럼 필드가 여러 개인 경우가 많다. 한 필드가 안전하게 처리된다고 나머지도 같다고 보지 않고, 필드별로 서로 다른 marker를 넣어 도달 지점을 분리한다.

• 실습: 메시지 조작으로 클라이언트 측 인코딩 우회

3. 메시지 기반 취약점

원문 전송이 통과했다면, 그 값이 최종적으로 어디에서 해석되는지에 따라 취약점 종류가 갈린다.

메시지가 다른 사용자에게 중계되는 구조는 Stored XSS와 성격이 같다. 저장 후 조회를 기다리는 대신 즉시 전파되므로, 실제 서비스에서는 무해한 marker 단계에서 멈추고 영향 범위를 먼저 판단한다.

수신 측 sink 확인은 XSS 진단과 동일하다. innerHTML로 삽입하는 구조에서는 <script>가 DOM에 보여도 실행되지 않으므로, 파싱 직후 자동으로 발생하는 이벤트를 사용해야 한다.

• 원리: InnerHTML과 Script 태그 분석

4. 핸드셰이크 조작

Repeater에서 WebSocket URL 옆의 연필 아이콘으로 새 연결을 수립하거나 기존 연결을 복제·재연결하면서 핸드셰이크 요청을 직접 편집할 수 있다. 메시지 단위 방어가 촘촘해도 연결 단계에서 무력화되는 경우가 있으므로 항상 함께 확인한다.

핸드셰이크를 다시 만들어야 하는 상황은 헤더 조작으로 공격면을 넓힐 때, 공격 시도로 끊긴 연결을 되살릴 때, 만료된 토큰을 갱신할 때다.

• 실습: 핸드셰이크 조작으로 IP 차단·필터 우회

5. CSWSH 빠른 확인

세 조건이 모두 성립하면 Cross-Site WebSocket Hijacking이 가능하다.

1. 핸드셰이크 인증이 쿠키에만 의존한다.
2. CSRF 토큰이나 예측 불가능한 값이 없다.
3. 서버가 Origin을 검증하지 않는다.

브라우저는 WebSocket 연결에 동일 출처 정책을 강제하지 않고 Origin 헤더만 전달하므로, 교차 출처 차단 여부는 전적으로 서버 검증에 달려 있다.

PoC는 데이터 유출 전에 연결 수립 여부만 확인한다.

<script>
    const ws = new WebSocket('wss://<target-host>/chat');
    ws.onopen = () => console.log('opened');
    ws.onclose = (e) => console.log('closed', e.code);
</script>

연결이 열리면 세션 쿠키가 교차 사이트 요청에 실렸다는 뜻이다. 메시지 전송과 응답 수집으로 확장하는 단계는 실습 환경에서만 진행한다. 세션 쿠키의 SameSite 설정도 함께 확인한다. None이면 교차 사이트 요청에 쿠키가 자동으로 첨부된다.

• 실습: Cross-site WebSocket hijacking

6. 차단에 막혔을 때

WebSocket은 차단이 메시지 하나에 그치지 않고 연결 전체에 적용되는 경우가 많다. 어느 단위로 차단됐는지를 먼저 구분해야 다음 시도를 고를 수 있다.

차단 사유가 {"error":"Attack detected: Event handler"}처럼 그대로 노출되면 필터가 무엇을 보고 판단했는지 알 수 있다. 이벤트 핸들러라면 HTML 속성 이름이 대소문자를 구분하지 않는다는 점을, 특정 문자라면 대체 문법을 먼저 확인한다.

7. 특수·예외 상황

아래 항목은 일반 흐름에 맞지 않을 때만 확인한다.

Quick Checklist

• 엔드포인트·핸드셰이크·메시지 형식을 먼저 기록했는가?
• 입력창 전송과 프록시 원문 전송 결과를 비교했는가?
• JSON 필드별로 도달 지점을 분리해 확인했는가?
• 메시지가 다른 사용자에게 중계되는 구조인지 확인했는가?
• 값이 최종적으로 해석되는 지점(수신 측 sink·DB·파서)을 특정했는가?
• 핸드셰이크 헤더를 근거로 보안 결정을 내리는지 확인했는가?
• CSWSH 성립 조건 세 가지를 각각 확인했는가?
• 차단이 메시지·연결·IP 중 어느 단위인지 구분했는가?