쿠키(Cookie) 탈취 시나리오
이 글에서는 구체적으로 공격자가 사용자의 쿠키를 어떻게 탈취하는지 그 과정을 자세히 알아보도록 하겠다.
쿠키가 무엇인지 정확히 모른다면?
https://velog.io/@airoca/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%BF%A0%ED%82%A4-Cookie-%EC%84%B8%EC%85%98-Session-%ED%86%A0%ED%81%B0-Token-JWT아래와 같이 시나리오를 구분하여 각각의 과정을 이해해보자.
- Sidejacking (Passive)
- Hijacking (Active)
- Surfjacking (Active)
- Cookie Stealing
※ 해당 글은 성균관대학교 소프트웨어학과 최형기 교수님의 강의 내용을 바탕으로 작성되었다.
✅ Sidejacking (Passive)
Sidejacking은 암호화 되지 않은 세션 쿠키를 가로채어 사용자의 세션을 탈취하는 공격 방법이다.
Passive(수동적) 공격인 이유는, 공격자가 특정 작업을 수행하기 보다는 Victim 사용자가 특정 웹사이트에 방문할 때 쿠키를 엿보는 방식이기 때문이다.
Sidejacking은 암호화되지 않고, 평문으로 전송되는 쿠키를 Sniffing 하는 방법이고, 단순한 공격이기에 구체적인 시나리오가 없더라도 쉽게 이해할 수 있다.
대부분의 웹사이트가 HTTPS를 사용하여 서버와 브라우저 간의 통신을 암호화하기에, Sidejacking은 쉽게 예방할 수 있는 공격이다.
📌 Sniffing이란?
스니핑(sniffing)은 네트워크 상에서 전송되는 데이터를 가로채고 분석하는 행위를 말한다.
✅ Hijacking (Active)
Hijacking 부터는 Sidejacking과 달리 Active(능동적)한 방식의 공격으로, 공격자가 사용자의 세션을 탈취하기 위해 개입하거나 조작을 진행한다.
Hijacking 공격을 진행하기 위해서는 공격자와 사용자가 같은 Wi-Fi 환경에 있어야 한다. 아래의 시나리오를 살펴보자.
각 예시에서 secure connection은 빨간색, non-secure connection은 초록색이다.
반대가 낫지 않나..
1) 사용자가 HTTPS 사이트에 로그인
-
사용자가 HTTPS 연결을 통해
https://mail.google.com에 로그인을 진행한다. -
사용자는 로그인에 성공하고, 서버로부터 쿠키를 받는다.
2) 사용자가 HTTP 사이트에 접속
-
이후에 사용자가
http://cnn.com이라는 또다른 웹사이트를 방문한다. -
이 웹사이트는 google과 달리, HTTPS가 아닌 HTTP로 연결되는 불안정한 웹사이트라고 가정하자.
-
이 때, 네트워크 공격자는
http://cnn.com웹사이트의 응답에 악성 코드를 삽입할 수 있다. (cnn은 안전하지 않은 HTTP 연결을 사용하고 있으므로!)<img src=http://mail.google.com/mail>이라는 악성 코드를 삽입했다고 가정하자. (악성 코드를 http라고 적었다는 점에 집중하자!)
3) HTTP 요청으로 쿠키 자동 전송 - 공격 성공
-
삽입한 악성 코드는
http://mail.google.com/mail주소에서 이미지를 로드하려고 시도하는데, 실제로는 이미지가 로드되지 않고, 브라우저가 이 URL에 요청을 보내게 된다. -
결과적으로 사용자가
http://mail.google.com/mail페이지를 방문하게 되면, 브라우저는 자동으로http://mail.google.com의 쿠키를 포함한 요청을 보내게 된다. (이전에 google에 로그인을 진행하여 쿠키를 받았으므로!) -
이 때! 해당 요청은 HTTPS 연결이 아니라 HTTP 연결이기에 쿠키는 암호화되지 않고, 공격자는 이 쿠키를 스니핑하여 가로챌 수 있다.
✅ Surfjacking (Active)
다음으로 Surfjacking에 대한 시나리오를 살펴보자.
1) 사용자가 HTTPS 사이트에 로그인
-
사용자는 HTTPS 연결을 통해 안전하게
https://bank.com에 로그인한다. -
이때, 서버는 non-secure 쿠키를 클라이언트에게 보내지만, HTTPS를 통해 암호화된 상태로 전달된다.
2) 사용자가 HTTP 사이트에 접속
-
이후에 사용자가
http://foo.com이라는 또다른 웹사이트를 방문한다. 이 사이트는 HTTPS가 아닌 HTTP로 연결된다. -
공격자는
http://foo.com의 응답을 조작하여,"301 Moved Permanently"응답을 보낼 수 있다. 이 때, 응답 헤더에"Location: http://bank.com"을 포함했다고 가정하자.
3) 목표 사이트로 HTTP Redirection - 공격 성공
- 브라우저는
http://foo.com이http://bank.com으로 리디렉션되었다고 인식한다. 결과적으로, 브라우저는 새로 HTTP 연결을 설정하여http://bank.com으로 요청을 보내게 되고, 쿠키를 암호화하지 않고 평문으로 전송하게 된다.
Hijacking, Surfjacking 방어
위와 같은 공격은 목표 사이트(예시의 경우 google)에서 HTTP 연결 자체를 허용하지 않는 방식으로 방어할 수 있다.
예를 들어, 사용자가 google에 HTTP 연결을 시도하더라도 HTTPS로 Redirection 된다. 이는 google에 HTTP 연결을 시도할 때, 301 (Moved Permanently) 상태 코드를 통해 HTTPS 주소로 Redirection 시키는 방법이다.
📌 HTTP 상태 코드란?
그런데 Redirection으로 충분할까? 조금만 더 생각해보자.
Redirection 이후로는 쿠키가 암호화되지만, 문제는 google에 HTTP 요청을 보낸 바로 그 시점의 쿠키가 평문으로 전송된다는 점이다. (google 측에서도 애초에 요청을 받아야 해당 요청이 HTTP인지 HTTPS인지 구분하여 Redirection을 수행할 수 있겠지?) 따라서 Redirection을 하더라도 첫 번째 HTTP 요청의 쿠키가 유출되는 것을 막을 수 없다.
이에 대한 해결책은 단순히, 첫 번째 요청부터 HTTPS로 변환하자는 것이다. 어떻게? 브라우저 측에 특정 도메인을 하드코딩하여, 해당 도메인으로 접속할 때는 브라우저 차원에서 HTTP 요청을 HTTPS를 자동으로 바꾼다. (이는 301과는 상관없고, 요청 전에 일어나는 작업이다.)
특정 도메인은 어떻게 결정될까? Preload라는 리스트에 등록된 도메인은 브라우저에 하드코딩되어, 위의 작업이 수행된다. 당연히 리스트에 등록된 도메인은 상대적으로 안전하다고 볼 수 있다.
궁금하면 아래 링크에서 특정 사이트가 Preload에 등록되었는지 검색해 보자.
예시로, 현재 gmail은 Preload에 등록되어 있다는 점을 확인할 수 있다.
✅ Cookie Stealing
-
공격자는 사용자에게
attacker.com이라는 웹 페이지를 방문하도록 유도한다. 이 페이지는 악성 스크립트를 포함하고 있다. -
공격자의 웹 페이지에서 두 개의 프레임을 사용한다. 하나는
gmail.com를 로드하고, 다른 하나는attacker.com(공격자 페이지)으로 설정된다. -
공격자의 웹 페이지에서 악성 JavaScript가 실행되면, 이 스크립트는 gmail 페이지의 프레임에 접근하여, 사용자의 gmail 쿠키를 읽을 수 있다.
위와 같은 공격을 방지하기 위해, google은 애초에 frame을 허용하지 않고 있다. 즉, frame에 google.com을 넣을 수 없다.
마치며
위의 항목은 각 케이스를 명확히 구분했다기 보다는, 쿠키가 실제로 어떤 방식으로 탈취될 수 있는지 시나리오를 정리한 것이다.
중요한 점은, 쿠키를 보호하려면 공격자가 쿠키를 읽을 수 없도록 해야 하고, 이를 위해 쿠키는 오직 허가된 서버만이 설정하고 읽을 수 있어야 한다. 즉, 쿠키는 해당 쿠키를 발급한 서버에서만 읽을 수 있도록 제한되어야 한다. 이것이 바로 CORS(Cross-Origin Resource Sharing)의 배경이다.
다음 글에서는 CORS와, CORS 에러를 핸들링하는 방법에 대해 다루도록 하겠다.
