CSWSH Attack
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을 맺을 수 있는지 테스트하면 됩니다.
GET /connect HTTP/1.1
Upgrade:WebSocket
Origin: attacker.hahwul.com
Connection: keep-alive, Upgrade
Upgrade:WebSocket
Exploitation
임의 WebSocket connection에 성공했다면 이제 영향력을 검증해야합니다. WebSocket connected 상태에서 사용자에게 영향을 줄 수 있는 기능을 파악한 후 사용자의 세션으로 수행하여 사용자가 의도하지 않은 기능을 수행하거나, 정보를 가져오는 등의 액션으로 공격을 수행하면 됩니다.
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
Origin: attacker.hahwul.com
Origin: trust_domain.hahwul.com
Origin: *
Defensive techniques
Origin Verification
Switching Protocol 시 Origin 헤더에 대해 정확하게 검증이 필요합니다. 일반적으로 웹 브라우저에서 connection 시 origin 헤더를 임의로 수정할 순 없지만, 임의 서비스에서의 요청을 허용하거나 특정 패턴의 Origin에서 허용하는 경우 문제가 될 수 있기 떄문에 서비스에서 신뢰하는 도메인만 처리할 수 있도록 정확하게 검증해야합니다.
Origin: trust.hahwul.com (O)
Origin: abcd.com (X)
Origin: trust.hahwul.com.google.com (X)
SameSite Cookie
CSRF와 동일하게 쿠키 기반의 인증을 사용하는 경우 쿠키 설정을 통해 방어할 수도 있습니다. Set-Cookie 시 SameSite=Lax
또는 SameSite=strict
등으로 명시하게 되면 해당 도메인에서 발생하는 요청만 쿠키로 붙기 떄문에 Cross-origin 간 사용자 세션을 이용하는 공격은 대부분 방어할 수 있습니다.
e.g
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/