WebSocket
: 브라우저와 웹 서버가 하나의 소켓 채널로 실시간 양 방향 통신할 수 있게 HTML5에서 제공하는 순수 웹 기반의 통신기술
:브라우저와 웹 서버가 HTTP를 통해 WebSocket 연결을 시도하기 위해 HandShake 과정이 이루어진다. 그리고 접속이 이루어지면 TCP채널을 기반으로 WebSocket 프로토콜 RFC 6455을 사용하여 실시간 양뱡향 메시지 교환이 이루어진다. 즉 TCP채널을 이용한 소켓통신이 이루어지는 것이다.
+) WebSocket의 특징
1. 양방향 통신 : 데이터의 송수신을 동시에 처리할 수 있는 방법, 지속적으로 connection을 유지하기 때문에 실시간으로 변경이 가능하다.
2. 실시간 네트워킹 : 웹 환경에서 연속된 데이터를 빠르게 노출하는 것
3. 최초 HTTP를 통해 연결되고 이후 일정 시간이 지나면 HTTP 연결은 자동으로 끊어지고, WebSocket connection은 유지된다.
+) WebSocket 의 일반적인 취약점
- Broken authentication
:공격자가 인증을 우회하게되면 계정의 모든 데이터와 기능에 액세스할 수 있게 된다.
이를 방지하려면 쿠키나 token을 사용하여 Websocket 연결을 설정하기 전에 handshake를 인증해야한다.
-쿠키 인증: 쿠키로 인증할 때 브라우저는 WebSocket handshake를 사용하여 자동으로 쿠키를 서버로 보낸다. 이 때 Cross-Site WebSocket Hijacking에 주의해야한다.
-토큰 인증: 브라우저는 WebSocket 연결 요청을 할 때 임의의 헤더를 허용하지 않으므로, 토큰을 서버로 보내려면 다른 매체를 찾아야한다. 쿼리 문자열에 인증 토큰을 보내는 방법을 사용하면, 쿼리 문자열이 URL의 일부를 형성하게 되어, 공격에 사용할 수 있기 때문에 주의해야한다.
다른 방법은 수명이 긴 인증 토큰을 사용하여 인증서비스에서 임시 일회성 토큰에 대한 HTTP 요청을 만드는 것이다.
쿼리 문자열에 WebSocket 연결과 함께 이 일회성 토큰을 보낸 다음 서버 측에서 중단한다. 하지만 이 경우에도 토큰이 실수로 공유되거나 하는 경우에 더 이상 사용될 수 없다.
2. Broken access control
: 사용자가 접근할 권한이 없는 작업에 접근할 수 있게 될 때 발생하는 취약점이다. 이 취약점은 모든 데이터의 무단 정보 공개, 수정, 삭제 등으로 이어질 수 있다.
3. Insecure Direct Object References
: access control 취약성의 하위 범주이다. 이 취약성을 통해 공격자는 WebSocket 요청에서 파일 이름 또는 쿼리 매개 변수와 같은 직접개체 참조를 조작하여 Websocket 애플리케이션을 악용할 수 있다.
IDOR 공격에서는 사용자가 특정 데이터에 액세스할 수 있는지 여부를 확인하지 못하는 액세스 제어 검사가 누락되어 요청이 성공하게 된다. 이 공격의 영향으로 무단 데이터 노출, 개인 식별 정보 유출 등의 문제가 발생할 수 있다.
4. Injection atacks (SQL Injection, XSS ,etc..)
: 인젝션 공격은 공격자가 응용 프로그램 처리의 취약성을 악용하기 위해 응용 프로그램에 데이터를 보내려는 시도이다.
HTTP의 가장 일반적인 취약점 중 하나이며, 민감한 정보를 전송하고 상승된 권한을 자주 실행하는 WebSocket에도 적용된다.
일반적인 유형에는 공격자가 데이터베이스 쿼리를 조작하는 SQL 삽입과, 다른 사용자가 보는 웹 페이지에 악성 스크립트를 삽입하는 XSS가 포함된다.
이 공격을 방지하기위해서는
-사용자 입력에서 특수문자를 쿼리 또는 명령에 통합하기 전에 이스케이프한다. 이렇게 하면 코드로 해석되는 것을 방지할 수 있다.
-사용자가 제공한 모든 입력을 신뢰할 수 없는 것으로 처리한다.
-안전하지 않은 것으로 간주되는 HTML 태그와 같은 원치않은 키 문자를 검사하고 제거한다
5.DoS
: DoS 공격은 WebSocket 구현의 취약점을 악용하여, WebSocket 서버를 충돌시켜 실제 사용자가 액세스할 수 없도록 한다.
WebSocket 서버에 트래픽을 플러딩하거나 충돌을 일으키는 정보를 전송하게 된다.
이를 방지하려면
-인증된 사용자만 WebSocket 연결을 열 수 있도록 공격자가 많은 수의 연결 요청으로 WebSocket 서버를 플러딩하는 것을 방지한다.
-유효하지 않은 토큰을 사용하는 DoS 공격을 빠르게 거부할 수 있도록 인증 메커니즘이 효율적인지 확인한다.
-특정 기간동안 동일한 ip 주소에서 WebSocket 서버로 수행할 수 있는 요청 수 를 제한한다.
6. Cross-site WebSocket hijacking
:악의적인 행위자가 사용자가 현재 있는 출처가 아닌 다른 출처(사이트)에 무단 WebSocket 연결을 할 때 발생하는 취약점이다. WebSocket 핸드셰이크 요청이 인증을 위해 HTTP 쿠키에만 의존하고 토큰 기반 인증을 사용하는 경우 관련이 없는 경우에 발생한다.
최소한 사이트 간 WebSocket 하이재킹 공격이 성공하면 악의적인 행위자가 설정된 WebSocket 연결을 악용하여 사용자의 동의 없이 사용자를 대신하여 작업을 수행할 수 있으며, 이로 인해 데이터가 손상되거나 의도하지 않은 작업이 실행될 수 있다.
대부분의 경우 사용자는 너무 늦을 때까지 자신이 악용되었다는 사실을 알지 못하므로 자신의 데이터에 대응하고 방어하기가 어렵다.
이를 방지하기 위해서는
-서버 측에서 들어오는 WebSocket 연결의 출처를 확인한다. Origin 헤더를 확인하여 신뢰할 수 있는 도메인의 연결만 허용합니다. 예기치 않거나 승인되지 않은 출처의 연결을 거부한다.
-세션 개별 토큰을 사용자 세션에 도입한 다음 서버로 전송되는 WebSocket 연결 요청에 포함한다. 이 토큰은 악의적인 행위자에게 알려지지 않으므로 요청을 위조하기가 어렵다.
7. Sensitive information disclosure over a network
: WebSocket을 통해 한 클라이언트에서 다른 클라이언트로 중요한 정보를 전송할 때 네트워크를 통과해야 한다. 악의적인 행위자는 취약성을 악용하여 통신을 도청하고 계정 세부 정보, 민감한 건강 데이터, 개인 통신 및 지적 재산과 같은 개인 식별 정보를 훔칠 수 있다. 일반적으로 중간자 공격이라고 한다.
* WebSocket이 나오기 전까지의 통신 방식
: 양방향 통신과 실시간 네트워킹을 가능하게 했던 방법
1.Polling : 일정한 주기로 서버에 요청을 보내는 방법
불필요한 Request와 Connection을 생성하여 서버에 부담을 준다. 요청 주기가 짧을수록 부하는 커진다.
요청주기가 짧으면 실시간처럼 보이겠지만 실제로 실시간은 아니다. HTTP 통신을 하기 때문에 Request,Response 헤더가 불필요하게 크다.
-polling 방식을 사용하는 경우
: 응답을 실시간으로 받지 않아도 되는 경우, 다수의 사용자가 동시에 사용하는 경우 (ex. facebook 웹 채팅, google 메신저..)
2. Long Polling : Polling 과 비슷하지만 주기적으로 요청을 보내는 방법이 아니라 특정 시간동안 기다리는 방법
:불필요한 요청을 보내지않아 Polling보다 좋아보이지만, 동시 다발적인 요청과 응답이 생기면 부하가 발생할 수 있다.
HTTP 통신을 하기 때문에 Polling과 동일하게 Request, Response 헤더가 불필요하게 크다.
-Long Polling 방식을 사용하는 경우 : 응답을 실시간으로 받아야하는 경우, 적은 수의 사용자가 동시에 사용하는 경우
3. Streaming: 이벤트가 발생했을 때 응답을 내려주되, 응답을 완료시키지 않고 계속 연결을 유지하는 방식
:Long Polling에 비해 응답마다 다시 요청을 하지 않아도 되서 효율적이지만, 연결 시간이 길어질수록 연결 유효성 관리의 부담이 발생한다.
+) WebSocket 동작 과정
웹소켓의 동작 과정은 크게 세가지로 나눌 수 있다.
빨간색 박스 - Opening Handshake
노란색 박스 - Data transfer
보라색 박스 - Closing Handshake
Handshake
: 접속 요청은 HTTP로 한 뒤에, 웹 소켓 프로토콜로 변경된다.
웹 소켓 프로토콜로 변경되기 위한 HTTP 헤더는 아래와 같다.
요청 헤더
GET /chat HTTP/1.1
: 웹소켓의 통신 요청에서 HTTP 버전은 1.1 이상이어야 하고, GET 메서드를 사용해야 한다.
Upgrade
: 프로토콜을 전환하기 위해 사용하는 헤더, 웹소켓 요청 시에는 websocket이라는 값을 가지고, 이 값이 없거나 다른 값이면 cross-protocol attack으로 간주하여 웹소켓 접속을 중지시킨다
Connection
: 현재의 전송이 완료된 후, 네트워크 접속을 유지할 것인가에 대한 정보, 웹소켓 요청 시에는 반드시 upgrade라는 값을 가지고 이 값이 없거나 다른 값이면 웹소켓 접속을 중지시킨다.
Sec-WebSocket-Key
:유효한 요청인지 확인하기 위해 사용하는 키 값
Sec-WebSocket-Protocol
:사용하고자 하는 하나 이상의 웹소켓 프로토콜 지정
Sec-WebSocket-Version
:클라이언트가 사용하고자 하는 웹소켓 프로토콜 버전.
Origin
:CORS 정책으로 만들어진 헤더.
Cross-Site Websocket Hijacking과 같은 공격을 피하기 위함.
응답 헤더
HTTP/1.1 101 Switching Protocols
: 101은 HTTP에서 WS로 프로토콜 전환이 승인 되었다는 응답코드
Sec-WebSocket-Accept
: 요청 헤더의 Sec-WebSocket-Key에 유니크 아이디를 더해서 SHA-1로 해싱한 후 base64로 인코딩한 결과, 웹 소켓 연결이 개시되었음을 알린다.
Data Transfer
Opening HandShake로 승인이 나고나면, Data transfer이 진행된다. 데이터는 메시지의 단위로 전달된다.
* 메시지: 여러 프레임이 모여서 구성되는 하나의 논리적인 메시지 단위
웹소켓 API
웹소켓 API에는 Open과 Message, Close, Error 등 네 개의 주요 이벤 트가 있다.
이들 이벤트는 각각 OnOpen, OnMessage, OnClose, onerror 함수를 구현하거나, addEventListener 메소드를 사용해 처리할 수 있다.
-OnOpen : OnOpen 이벤트는 연결이 성공적으로 이루어진 후 발생한다. 이는 클라이언트와 서버 사이의 초기 핸드쉐이크가 성공적으로 이루어졌으며, 응용프로그램이 이제 데이터를 전송할 준비가 돼 있음을 의미한다.
-OnMessage : OnMessage 이벤트는 서버의 전송을 기다리는 클라이언트의 귀 같은 역할을 담당한다. 서버가 데이터를 보낼 때마다 OnMessage 이벤트가 발생한다. 메시지에는 일반 텍스트뿐만 아니라 이미지나 바이너리 데이터를 포함할 수 있다.
-OnClose: OnClose 이벤트는 대화의 종료를 나타낸다. 이 이벤트가 발생하면, 연결을 다시 시작하지 않는 한 어떠한 메시지도 서버와 클라이언트 사이에 전송할 수 없다.
-OnError : OnError 이벤트는 무엇인가 문제가 생겼을 때 발생한다. OnError 이벤트 다음에는 항상 연결 종료(close 이벤트)가 뒤따른다.
웹 소켓은 사용자 측에서 보면 브라우저에서 사용자의 별도 허가 없이도 다른 도메인으로 연결 요청 가능
요청이 발생했다는 사실을 따로 사용자에게 알려주지 않는다.
-> 공격자는 사용자의 브라우저에 임의의 악성 스크립트를 실행하여 사용자 모르게 브라우저를 통해 다른 도메인에 있는 시스템과 통신 채널을 형성한 후 데이터 송수신이 가능하다.
웹 소켓을 사용하는 서버 측에서 보면 Web Socket API 는 일반적으로 Well-Known 포트들에 대한 접근이 기본적으로 차단되도 록 구성되어 있지만, 각 시스템들의 Up/Down 여부 확인이 가능하며 이는 공격자 입장에서 유용한 정보가 될 수 있다. 웹 소켓을 통해 포트 스캐닝이 가능해진다.
-> 사용하지 않는 포트를 정리하고, 서버에 포트 스캔 차단 프로그램을 설치하는 것으로 예방 가능하다.
웹 소켓 CORS 취약점
CORS의 근본적인 보안문제는 XHR을 다른 도메인으로 발생시킬 때, 사용자에게 허가 요청을 받지 않는다는 것
-> 사용자의 세션을 오용한 접근제어와 관련된 보안 문제 야기 가능
-> 공격자가 사용자의 세션을 오용할 수 있게 된다는 것은 접근 제어를 우회하여 허가되지 않은 리소스에 접근할 수 있다는 의미이다.
-> 그럼 Cross Domain 접근이 가능해진다.
대응 방안
: 접근하려는 웹소켓 URL과 요청자의 Origin 속성을 비교하여 그 값이 다르면 해당 연결을 종료(CLOSE)한다.
websocket.url의 도메인 부분과 location.href의 도메인 부분을 비교해서, 두 값이 동일하지 않다면 websocket.close() 함수를 호출하여 연결을 종료.
기밀성과 무결성 취약점
웹소켓의 데이터는 평문으로 전송되며, 전송된 데이터를 검증하지 않는다. 이는 중간자 공격에 취약성을 드러내며 신뢰할 수 없는 연결을 의 미한다. 웹소켓은 사용자가 암호화 기법을 적용하지 않는 한 평문으로 통신하게 되는데, 이는 기밀성을 위협하는 취약점이 된다.
-> 평문 데이터를 암호화하지 않고 보낼 경우 데이터가 노출되고, 데이터의 변조 여부를 확인할 수 없기 때문에 무결성 취약점이 존재한다
CSWSH (Cross-Site WebSocket Hijacking) 취약점
: CSRF나 XSS에 웹소켓을 이용 하여 쿠키나 HTTP 인증정보를 탈취하는 해킹 방법
웹소켓 프로토콜은 서버가 클라이언트와 Hand-Shake 과정 중에 클라 이언트를 인증할 수 있는 어떤 방법도 제공하지 않음.
따라서 웹소켓 이 취할 수 있는 방법은 오직 HTTP 연결 쿠키나 HTTP 인증정보, TLS(Transport Layer Security) 인증정보 뿐이다.
하지만 HTTP와 웹소켓이 Hand-shake 과정을 거치는 동안 HTTP의 모든 인증정보를 웹소켓에 넘기는 것으로 나타났다. 이 정보는 CSRF(Cross-Site Request Forgery) 공격에 취약점을 드러낸다.
-CSWSH 취약점 실험 방법
- 공격자 ID로 로그인
- 해커가 공격을 위해 게시판에 XSS 코드 작성, 피해자의 브라우저가 CSRF 공격에 노출되도록 한다.
- 해당 주소로 (코드에 있는) 피해자의 브라우저와 웹소켓이 연결되면 공격자는 피해자의 쿠키를 가져올 수 있다
- 공격자의 세션 ID를 피해자의 브라우저에서 탈취한 쿠키에 있는 세션 ID로 변조한다.
- 세션 ID를 변조하고 나면, 접속자의 이름이 관리자로 변경되어 있다.
-> CSWSH 공격이 성공했음을 의미
대응 방안
- Origin 헤더는 Cross-Site Attack을 보호하기 위해 설계되었기 때문에, 웹소켓의 HandShake 과정에서 Origin 헤더를 확인한다
-> 웹소켓에서 제공 하는 CORS의 기본 기능을 제한하는 요소가 된다. 웹소켓이 동일한 도 메인에서만 사용되기 때문에 안전성은 높아지지만 사용 효율성은 떨어짐
2. 서버의 HandShake 요청시 CSRF 토큰처럼 세션별 임의의 토큰을 사용하여 서버를 확인한다.
->CSRF 토큰과 같은 임의의 토큰을 사용한다면 매번 토큰을 새로 생성하기 때문에 불필요한 토큰 생성 프로세스를 증가 시킴
--> 다른 도메인간의 접근을 허용하며 임의의 토큰을 사용하는 법을 구체화하여, Oauth 인증 프레임워크를 통한 Access Token 인증을 한다면 최초에 한번 실행된 토큰으로 사용자를 인증하기 때문에 로그아웃을 하지 않는 이상, 토큰 생성 프로세스는 실행되지 않는다.
- Oauth 인증 : Client와 Server 사이에 사용자 인증을 관리하는 서버가 별도로 존재한다.
Client는 인증 서버로부터 Access Token을 발급 받으면 사용자는 로그인을 한 것으로 간주한다.
-AccessToken의 암호화
: Access Token을 발급받고, 이를 SHA 해시 함수를 이용해 다시 한 번 유효성 검사를 하는 방식으로 세션ID 하이재킹을 방지할 수 있게 대응했다.
Access Token을 세션에 저장하고 SHA256 해시 함수로 암호화 해서 클라이언트에 넘겨주면 현재 접근한 URL에 포함되어 있는 Access Token을 SHA256 해시 함수로 암호화한 값과 비교를 하여 CSRF 여부 를 판단하게 된다.
-> Oauth 2.0 기반의 Access Token을 SHA256 알고리즘으로 암호화한 인증 시스템으로 세션 하이재킹 위협에 대응할 수 있고, 다른 도메인 간의 웹 소켓 연결이 가능하며 키를 한번만 생성해도 되는 효과를 보였다.
[논문]
'INCOGNITO 2023' 카테고리의 다른 글
| [WebSocket] WebSocket 취약점 확인 스크립트 (0) | 2024.02.11 |
|---|---|
| [WebSocket] CORS 취약점 분석 (0) | 2024.02.11 |
| [WebSocket] XSS 취약점과 WebSocket 핸드셰이크 조작 (0) | 2024.02.04 |
| [WebSocket] Cross-site WebSocket hijacking (0) | 2024.02.04 |
| [WebSocket] 기밀성 / 무결성 취약점 분석 (1) | 2024.01.21 |
