Burp Suite로 WebRTC 실시간 통신 보안 점검

소개

WebRTC는 브라우저 기반 실시간 미디어와 데이터 전송을 지원한다. 서비스에는 음성, 영상, 그리고 데이터채널이 포함된다. 따라서 WebRTC 특유의 통신 흐름과 신호 교환(SDP, ICE 등)을 이해하지 못하면 보안 취약점을 놓치기 쉽다. 본문은 Burp Suite로 WebRTC/Real-time 통신을 검사하는 현실적 절차와 핵심 포인트를 설명한다.

WebRTC 핵심 개념 요약

처음 접하는 사람도 이해할 수 있도록 핵심만 짚는다.

• SDP(Session Description Protocol): 세션 매개변수와 코덱 정보를 주고받는 텍스트
• ICE(Interactive Connectivity Establishment): 피어 간 연결 후보(서버, 호스트, 릴레이)를 협상하는 과정
• STUN/TURN: NAT 환경에서 연결을 돕는 서버
• DataChannel: 브라우저 간 임의 데이터 전송 채널

Burp Suite 준비

필수 구성

Burp를 중간자(Man-in-the-Middle) 프록시로 사용한다. HTTPS 트래픽 가로채기를 위해 브라우저에 Burp CA 인증서를 설치해야 한다. 또한 브라우저의 프록시 설정을 Burp로 향하도록 변경한다.

브라우저와 인증서

• Burp에서 Proxy를 실행하고 인터셉트를 활성화
• 브라우저에 Burp CA를 추가해 인증서 경고 제거
• WebRTC는 DTLS로 미디어를 암호화하지만, 시그널링(예: REST, WebSocket)은 프록시로 가로챌 수 있음

트래픽 캡처와 시그널링 검사

대부분의 WebRTC 취약점은 시그널링 단계에서 발견된다. 시그널링은 보통 HTTP, HTTPS, WebSocket으로 이루어진다. Burp의 Proxy와 WebSockets 탭을 활용해 메시지를 분석한다.

SDP와 ICE 분석

SDP 내용에서 코덱, 엔코더 옵션, 포트와 후보 정보를 확인한다. ICE 후보에 TURN 서버가 포함되어 있는지, 호스트 IP(사설 IP)가 노출되는지 살핀다. SDP 변조를 통해 미디어 스트림이 의도대로 협상되는지 확인한다.

DataChannel 및 WebSocket

DataChannel은 브라우저 내부에서는 SCTP/DTLS 위에서 동작하지만, 시그널링으로 생성된 메시지에 취약점이 있을 수 있다. WebSocket 메시지를 통해 인증 토큰, 세션 식별자, 권한 정보가 유출되는지 확인한다.

실제 검사 절차

아래 절차를 차례로 수행하면 핵심 취약점을 빠르게 찾을 수 있다.

• 1) 브라우저 프록시를 Burp로 설정하고 Burp CA 설치
• 2) 서비스의 시그널링 엔드포인트(REST, WebSocket)를 식별
• 3) 신규 통화나 데이터 채널 생성 시의 시그널링 메시지를 캡처
• 4) SDP를 확인해 민감 정보 노출 여부 점검
• 5) 인증 토큰 재사용, 권한 우회 가능성 검사
• 6) ICE 후보에 사설 IP 노출, TURN 설정 오류 확인

샘플 코드: SDP 변조 예시

브라우저 콘솔에서 테스트할 때 사용할 수 있는 간단한 SDP 변조 스니펫(예시). 실제 서비스에 적용 전에는 테스트 환경에서만 사용한다.

const pc = new RTCPeerConnection();
pc.createOffer().then(offer => {
  let sdp = offer.sdp;
  // 예: 오디오 코덱 우선순위 변경
  sdp = sdp.replace(/m=audio .*\r\n/, 'm=audio 9 UDP/TLS/RTP/SAVPF 111 0 8\r\n');
  const modified = new RTCSessionDescription({ type: 'offer', sdp });
  return pc.setLocalDescription(modified);
});

검사 포인트 요약

• 시그널링 메시지에 인증 정보가 노출되는지 여부
• SDP에 불필요한 내부 네트워크 정보(사설 IP) 노출
• TURN 서버 인증 설정의 적절성
• DataChannel을 통해 전송되는 민감 데이터의 암호화 여부
• WebSocket 통신의 무결성 및 인증 검증

추가 팁과 한계

Burp는 시그널링을 잘 분석할 수 있지만, 미디어 스트림(RTP/DTLS)을 직접 복호화하지는 못한다. 미디어 내용 분석이 필요하면 서버 로그, TURN 서버 설정, 또는 클라이언트 측 디버깅 도구를 병행한다. 또한 시험은 합법적 범위 내에서 수행한다.

맺음말

Burp Suite를 활용한 WebRTC 점검은 시그널링 중심의 분석으로 충분히 많은 취약점을 발견할 수 있다. SDP와 ICE, 시그널링 메시지를 중심으로 우선 검사한 뒤 필요시 미디어 레벨 검사를 확장하는 방식이 현실적이다. 점검 결과는 권한 검증과 토큰 관리, TURN 구성 개선으로 이어져야 한다.