[WebSocket] CORS 취약점 분석

CORS

: Cross-Origin Resource Sharing , 교차 출처 리소스 공유 정책

교차 출처 = 다른 출처

 

Origin

 

어떤 사이트를 접속할 때 URL을 통해 접근하게 된다. 

URL은 하나의 문자열 같지만, 여러개의 구성요소로 이루어져 있다.

 

1.protocol : http , https

2. Host : 사이트 도메인

3. Port : 포트 번호

4. Path: 사이트 내부 경로

5. Query string: 요청의 key와 value 값

6. Fragment : 해시 태그

 

여기서 Origin 은 Protocol + Host + Port 이다.

즉, 출처라는 것은 Protocol + Host + Port 까지 모두 합친 URL을 의미한다.

 

 

동일 출처 정책 ( Same-Origin Policy )

: SOP는 동일한 출처에 대한 정책을 말한다. 이 정책은 '동일한 출처에서만 리소스를 공유할 수 있다'는 법률을 가지고 있다.  즉, 동일 출처 서버에 있는 리소스는 자유로이 가져올 수 있지만, 다른 출처 서버에 있는 이미지나 유튜브 영상같은 리소스는 상호작용이 불가능하다는 의미이다.

 

동일 출처 정책이 필요한 이유?

출처가 다른 두 어플리케이션이 자유로이 소통할 수 있는 환경은 위험할 수 있다. 만약 제약이 없다면 CSRF나 XSS 등의 방법을 사용해서 해커가 심어놓은 코드가 실행되어 개인 정보를 가로챌 수 있다.

 

 

같은 출처와 다른 출처 구분 기준

: 출처 (Origin)의 동일함은 두 URL 구성 요소 중 protocol, Host, Port 이 세가지가 동일하다면 동일 출처로 판단한다.

그 뒤의 다른 요소는 다르더라도 같은 프로토콜, 호스트, 포트를 사용한다면 같은 출처로 인정된다는 의미이다.

그리고 프로토콜,호스트,포트 중 하나라도 자신의 출처와 다른 경우, 브라우저는 정책상 차단하게 된다.

 

하지만, 인터넷은 여러 사람들에게 오픈된 환경이고, 이런 환경에서 웹페이지에서 다른 출처에 있는 리소스를 가져오는 것을 모두 차단해버릴 수는 없다.

-> 그래서 몇가지 예외 조항을 두고 다른 출처의 리소스 요청이라도 이 조항에 해당할 경우에는 허용하기로 했는데, 그 중 하나가 CORS 정책을 지킨 리소스 요청이다.

 

 

CORS

: Cross-Origin Resource Sharing , 교차 출처 리소스 공유 정책

CORS는 SOP 정책을 위반해도 CORS 정책에 따르면 다른 출처의 리소스를 허용한다는 해결방안과 같다.

 

CORS의 동작 과정

 

1.클라이언트에서 HTTP요청의 헤더에 Origin을 담아 전달

기본적으로 웹은 HTTP 프로토콜을 이용하여 서버에 요청을 보내게 되는데,

이때 브라우저는 요청 헤더에 Origin 이라는 필드에 출처를 함께 담아 보내게 된다.

 

2. 서버는 응답헤더에 Access-Control-Allow-Origin을 담아 클라이언트로 전달한다.

이후 서버가 이 요청에 대한 응답을 할 때 응답 헤더에 Access-Control-Allow-Origin 이라는 필드를 추가하고 값으로 '이 리소스를 접근하는 것이 허용된 출처 url'을 내려보낸다.

 

 

 

3. 클라이언트에서 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교한다.

1. 이후 응답을 받은 브라우저는 자신이 보냈던 요청의 Origin과 서버가 보내준 응답의 Access-Control-Allow-Origin을 비교해본 후 차단할지 말지를 결정한다.
2. 만약 유효하지 않다면 그 응답을 사용하지 않고 버린다. (CORS 에러 !!)
3. 위의 경우에는 둘다 http://localhost:3000이기 때문에 유효하니 다른 출처의 리소스를 문제없이 가져오게 된다.

결국 CORS 의 해결책은 서버의 허용이 필요한 것이다. 결론적으로 서버에서 Access-Control-Allow-Origin 헤더에 허용할 출처를 기재하여 클라이언트에 응답하면 되는 것이다.

 

---

 

하지만, 이러한 CORS는 WebSocket 통신에서 WebSocket이  HTTP와는 다르게 동작하기 때문에 취약점이 될 수 있다.

WebSocket은 HTTP와는 달리 양방향 통신을 지원하기 때문에 CORS 정책이 더욱 중요하지만 다음과 같은 상황에서 CORS 취약점이 발생할 수 있다.

 

1. 오픈 CORS 설정

: 서버가 너무 관대하게 CORS를 허용하여, 신뢰할 수 없는 출처로부터의 요청에 대한 제한이 부족한 경우 발생한다.

만약 모든 출처에 대해 접근을 허용하는 'Access-Control-Allow-Origin: *' 헤더를 설정함으로써 발생할 수 있다.

 

2. 인증 정보 포함 설정

:CORS 요청에 대해 인증 정보를 포함하도록 허용할 때, 서버는 출처에 대한 검증이 필요한데 출처 검증이 누락되면 인증 정보가 탈취될 수 있다.

 

3. CSRF 공격

: CORS 요청을 이용하여 CSRF 공격을 실행할 수 있다. 사용자의 권한으로 인증된 요청을 위조하여 다른 도메인에 정송한다.

 

웹소켓은 클라이언트와 서버 간에 지속적인 연결을 유지하기 때문에, 브라우저는 웹 소켓 연결이 수립된 후에도 Origin을 검증해야하고, 서버는 악의적인 웹 페이지가 사용자의 브라우저를 통해 웹 소켓 연결을 수립하여 다른 도메인으로 데이터를 전송하는 것을 방지하기 위해 출처를 검증해야 한다. 따라서 웹 소켓에서는 출처 제한이 더욱 중요하며, CORS 정책을 통해 출처 제한을 강화할 수 있다. 

접근하려는 웹소켓 url과 요청자의 origin 속성을 비교하여, 그 값이 다르면 해당 연결을 종료하는 식으로 CORS 취약점을 보완할수 있다.

 

이러한 CORS 정책을 설정하여 악의적인 출처로부터의 요청을 차단하여 보안을 강화할 수 있고, 웹 소켓을 통해 악의적인 요청을 보내는 CSRF 공격을 방지할 수 있다. 

웹소켓에서는 HTTP와는 다르게 preflight 요청이 전송되지 않기 때문에 Sec-WebSocket-Origin과 Sec-WebSocket-Location 헤더를 통해 웹 소켓의 보안을 강화한다.

 

 

[참고 자료]

🌐 악명 높은 CORS 개념 & 해결법 - 정리 끝판왕 👏 (tistory.com)

🌐 악명 높은 CORS 개념 & 해결법 - 정리 끝판왕 👏

HTML5 기반 웹소켓 보안 취약점과 대응방안에 대한 연구 - - 동국대학교 : 논문 - DBpia

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