[논문 분석] 웹소켓 보안 취약점 분석

 

<웹소켓의 원리>

 

 웹소켓(WebSocket)은 실시간 양방향 통신을 제공하는 프로토콜이고 클라이언트와 서버 간에 데이터를 주고받을 수 있다. 웹소켓은 HTTP 프로토콜 위에서 동작하며, 일반적인 HTTP 요청-응답 모델(클라이언트가 서버에 요청을 보내면, 서버는 응답을 반환하고 이로써 통신이 완료된다)과는 다르게 지속적인 연결을 제공하여 실시간으로 변경 사항이 저장된다. 이 연결이 계속 유지되어야 해서 트래픽이 많을 경우, 서버에 부담이 되고 연결이 끊어졌을 때 항시적인 대응이 필요하다. 

 

 웹소켓은 Polling 방식과 Comet 방식(Long Polling)의 단점을 보안하기 위해 탄생했다. 폴링의 경우 동일 기간 내에 갱신이 되는 경우에 적합하지만 채팅처럼 임의로 생성되는 데이터일 경우 대기시간이 발생한다. 롱폴링(코멧)은 대기 시간이 긴 만큼 서버에 부하가 걸릴 수 있다. 이러한 단점을 보완한 웹소켓은 실시간성 데이터에 효과적이다.

 

1. Polling 방식:
   • Polling은 클라이언트가 일정한 간격으로 서버에게 데이터를 요청하는 방식
   • 주기적으로 요청을 보내기 때문에 서버는 항상 새로운 데이터가 있는지 확인해야 한다.
   • 단점:
     • 불필요한 트래픽이 발생하여 서버 및 네트워크 부하가 증가합니다.
     • 실시간성이 떨어지고 지연이 발생할 수 있습니다.
2. Comet 방식:
   • Comet은 Long Polling 또는 HTTP Streaming이라고도 불리는 방식으로, 클라이언트가 서버에게 연결을 열어두고, 서버는 새로운 데이터가 있을 때까지 응답을 보류하는 방식입니다.
   • 클라이언트의 연결이 끊어지면 다시 연결을 시도하여 실시간 통신을 유지합니다.
   • 단점:
     • 클라이언트와 서버 간의 많은 연결을 열어두어야 하므로 서버 리소스 소모가 크고 확장성이 제한될 수 있습니다.
     • 일정 시간 동안 연결을 유지해야 하므로 서버와 클라이언트 간에 지연이 발생할 수 있습니다.
3. 웹소켓(WebSocket)
   • 핸드셰이크 후에 양방향 연결이 설정되며, 서버 또는 클라이언트가 새로운 데이터를 보낼 때마다 상대방에게 즉시 전달된다. 
     
     • 낮은 오버헤드: HTTP와 비교해 더 적은 오버헤드를 가지고 있어 효율적이다.
     • 지속적인 연결: 연결을 계속 유지하면서 클라이언트와 서버 간의 효율적인 양방향 통신을 가능하게 한다.
     • 프레임 구조: 프레임 구조를 사용하여 메시지를 나눠 전송함으로써 효율적인 데이터 교환을 지원한다.

 

 

브라우저와 웹 서버가 HTTP를 통해 WebSocket 연결을 시도하기 위 해 HandShake 과정(연결)이 이루어진다. 그리고 접속이 이루어지면 TCP채널 을 기반으로 WebSocket 프로토콜 RFC 6455을 사용하여 실시간 양뱡향 메시지 교환이 이루어진다. 즉 TCP채널을 이용한 소켓통신이 이루어지는 것이다. 실시간 통신을 기반으로 하는 웹 어플리케이션에서 사용하면 효과가 더 크다. 

 

 

 

 

<웹소켓의 특징이 어떻게 취약점과 연결 되는가>

 

1. 암호화를 제공하지 않는다.

따라서 중간자 공격 시, 공격자가 웹소켓 통신을 도청할 수 있고 이를 해결하기 위해 TLS(Transport Layer Security)나 SSL(Secure Sockets Layer)과 같은 암호화 프로토콜을 사용하여 웹 소켓 연결을 보호해야 한다. 이를 웹소켓의 기밀성 취약점이라고 한다. 웹소켓의 데이터는 평문으로 전송되며, 전송된 데이터를 검증하지 않는다. 이는 중간자 공격에 취약성을 드러내며 신뢰할 수 없는 연결을 의미하고 웹소켓은 사용자가 암호화 기법을 적용하지 않는 한 평문으로 통신하게 되는데, 이는 기밀성을 위협하는 취약점이 된다.

평문으로 통신하는 웹소켓

 

웹소켓 프레임에 노출되는 평문 데이터

 

평문 데이터를 암호화 하지 않고 보낼 경우 위와 같이 데이터가 노출된다.

 

2. 통신 도중 데이터 조작 위험이 있다. 그리고 변조 여부를 확인하지 않는다.

이를 방지하기 위해 HMAC(Hash-based Message Authentication Code)를 활용한 서명 검증처럼 무결성을 보장하기 위한 메커니즘을 구현해야 한다.

 

3. 공격자가 클라이언트와 서버 간 연결을 탈취할 수 있고 웹소켓 프로토콜은 Handshake 과정 중에 클라이언트를 인증할 수 있는 어떤 방법도 제공하지 않는다.

 따라서 웹소켓이 취할 수 있는 방법은 오직 HTTP 연결 쿠키나 HTTP 인증정보, TLS(Transport Layer Security) 인증 정보 뿐이다. 하지만 HTTP와 웹소켓이 Handshake 과정을 거치는 동안 HTTP의 모든 인증정보를 웹소켓에 넘기는 것으로 나타났다. 이 정보는 CSRF(Cross-Site Request Forgery) 공격에 취약점을 드러낸다.

 이를 Cross-Site WebSocket Hijacking (CSWSH) 취약점라고 하는데 악의적인 웹페이지로 웹소켓 연결에 대한 정보를 획득하고, 유저의 계정에 접근 가능하다. 이를 방지하기 위해 적절한 권한 검증 및 인증 정보를 보호하기 위한 안전한 전송 방법을 사용해야 한다. 

 

4. 프록시 서버나 방화벽 등이 웹소켓 연결을 잘못 인식하거나 오용하는 경우가 발생할 수 있다.

만약 이렇게 되면 공격자는 특정 패턴을 이용해 두 개의 다른 HTTP 요청을 하나의 웹소켓 연결로 해석하도록 유도한다. 이를 방지하기 위해 웹 서버와 프록시 서버의 설정을 신중히 조정해야 한다.

 

 

 

<웹소켓의 취약점>

 

웹 소켓은 사용자 측에서 보면 브라우저에서 사용자의 별도의 허가 없이도 다른 도메인으로 연결 요청을 할 수 있으며, 요청이 발생했다는 사실을 따로 사용자에게 알려주지 않는다. 따라서 공격자는 사용자의 브라우저에 임의의 악성 스크립트를 실행하여 사용자 모르게 브라우저를 통해 다른 도메인에 있는 시스템과 통신 채널을 형성한 후 데이터 송수신이 가능하다.

 

 또한 웹 소켓을 사용하는 서버 측에서 보면 Web Socket API 는 일반적으로 Well-Known 포트들에 대한 접근이 기본적으로 차단되도록 구성되어 있지만, 각 시스템들의 Up/Down 여부 확인이 가능하며 이 는 공격자 입장에서 유용한 정보가 될 수 있다. 웹 소켓을 통해 포트 스 캐닝이 가능해진다. 또한 웹 소켓의 서버를 마음대로 제어할 목적으로 웹 소켓 서버에 서비스 거부(Dos) 공격을 할 수도 있으며 프록시 서버를 공격, 웹 소켓 트래픽을 이용하여 장애를 일으킬 수 있고 트래픽을 모니터링 하여 중간에 메시지를 탈취할 수도 있다.

 

 

<웹 스토리지>

웹 스토리지는 세션 스토리지와 로컬 스토리지로 나뉘며, 웹 스토리지를 사용하여 클라이언트 측에서 저장된 데이터를 웹소켓을 통해 서버로 전송하거나 서버에서 받은 데이터를 클라이언트에 저장하는 등의 활용이 가능하다. 웹 스토리지를 사용하여 클라이언트 측에서 데이터를 로컬에 저장하고, 웹소켓을 통해 서버로부터 실시간 업데이트를 수신하여 저장된 데이터를 업데이트할 수 있다.

 

<논문 분석>

https://www.dbpia.co.kr/journal/detail?nodeId=T13968895

HTML5 기반 웹소켓 보안 취약점과 대응방안에 대한 연구 | DBpia