[펌] Http와 Https 프로토콜 간에 안전하게 세션 공유하기

---

 * 출처

 : https://reiphiel.tistory.com/entry/http-https-share-session-secure

---

일반적으로 웹 어플리케이션을 서비스할 때 개인정보와 같이 민감한 정보가 포함된 페이지는 https(HTTP over SSL)프로토콜, 이외의 일반적인 페이지는 http프로토콜을 이용하여 구성하는 웹 어플리케이션이 상당수를 차지합니다. 이렇게 http/https프로토콜이 혼재해 있는 경우 페이지 이동간에 프로토콜이 변경되면 세션 공유가 되지 않아 세션이 끊기는 문제가 발생하는 경우가 있습니다. 본 아티클에서는 http와 https 프로토콜을 혼용하여 사용할 경우 안전하게 세션을 공유하는 방법에 대해서 알아보도록 하겠습니다.

세션 공유가 안되는 원인

 위와 같은 환경에서 세션 공유가 되지 않는 원인은 기본적으로 웹 어플리케이션에서 세션 관리를 위해서 주로 사용하는 쿠키의 특성에 기인합니다. 쿠키는 웹 사이트의 호스트명(Hostname),  하위 패스 등의 속성 조합으로 관리되며 매 요청시 평가되어 조건에 해당하는 경우 전송됩니다. 여기서 문제가 되는 속성이 바로 secure 속성입니다. secure 속성이 지정되지 않은 경우에는 http, https 양쪽 모두 쿠키가 전송되지만 secure 속성이 지정된 경우에는 https 프로토콜에서만 전송되기 때문입니다.

 예를 들어 https로 되어있는 페이지로 최초 접속한 사용자에게 발행된 세션 쿠키에 secure 속성이 있는 경우 해당 사용자가 로그인 후에 http 프로토콜의 페이지로 이동하는 경우 세션 쿠키가 전송되지 않기 때문에 서버에서는 신규 접속으로 인식하여 세션 쿠키를 새로 발행하게 됩니다. 따라서 사용자는 로그인 하였음에도 불구하고 비 로그인 상태가 되어 다시 로그인 해야하는 상황이 발생되게 됩니다. 사용자중에는 로그인 페이지를 북마크에 넣어두고 접속하는 경우가 있기 때문에 특정 사용자에게 많은 빈도로 나타날 가능성이 있습니다.

해결책

• 1. 전 영역을 http프로토콜로 통합

개인정보 보호와 같은 문제가 없다면 적절한 해결책입니다. 하지만 민감한 정보를 제공받는 서비스를 http프로토콜로 통합하게 되면 법적인 문제가 생기거나 개인정보 누출로 인한 손해가 발생할 가능성이 있습니다.

• 2. 전 영역을 https프로토콜로 통합

역시 가장 간단하면서도 강력한 방법은 https프로토콜로 통합하는 방법입니다. 하지만 https프로토콜로 통합을 시도할 경우 아래와 같은 이유로 내부/고객의 반발에 직면하거나 제약사항 등에 의하여 선택할 수 없는 경우도 있습니다.

먼저 반발에 부딪히는 경우는 주로 성능적인 측면일 가능성이 높습니다. https프로토콜을 사용한 경우 커넥션 확립, 암호화/복호화 등의 작업에는 상당한 머신파워가 필요하다는 인식이 있기 때문에 하드웨어 비용이 증가할 수 있기 때문입니다.(정확히는 성능문제에 기인한 인프라 비용 증가 혹은 사용자 경험 저하에 의한 문제) 물론 최근에는 하드웨어 가격이 매우 저렴해 졌고 성능도 과거에 비해서 비약적으로 발전하였기 때문에 하드웨어를 문제삼아 https 프로토콜을 이용하지 않는 것에 대해 이견도 많이 있습니다.

위의 문제가 아닐 경우는 https를 지원하지 않는 클라이언트 혹은 크롤러 등이 이용할 가능성이 있을때 입니다. 이 경우는 통제할 수 없는 영역의 문제이기 때문에 어쩔 수 없는 경우이기도 합니다.

이 방법은 어플리케이션의 구현은 거의 손대지 않아도 되고 경우에 따라서는 간단한 서버 설정만으로 가능할 수 있기 때문에 이점이 많은 방법이라고 하겠습니다.

※ 가장 주의할 점은 http를 프로토콜로 직접 접근시 적절한 처리를 하지 않거나 https에서 세션 쿠키를 발행했지만 적절한 어플리케이션 서버 설정 혹은 어플리케이션을 구현을 하지 않아 secure속성이 없는 상태로 세션 쿠키가 발행되지 않도록 해야 한다는 점입니다. secure속성 없는 상태로 세션 쿠키가 발행된 경우 사용자 실수(브라우저의 주소창에 프로토콜 입력 미스) 혹은 인터넷 상의 악의를 가진 링크를 통해 전송구간 암호화가 되지 않은 상태로 네트워크 상에 쿠키 정보가 전송될 가능성이 있습니다. 이럴 경우 세션 하이재킹 등에 취약점에 의해 개인 정보 누출 문제가 발생할 가능성이 있습니다.

• 3. 서브 도메인(sub domain)을 이용하여 http와 https프로토콜의 호스트를 별도로 서비스

http와 https의 호스트를 분리할 경우 별도의 세션이 되기 때문에 https 영역은 쿠키의 secure속성을 이용하여 보호할 수 있습니다. 하지만 세션간에 데이터를 공유할 필요가 있는 경우 구현이 복잡해 지게 됩니다. 데이터를 공유한다고 하더라도 http프로토콜을 사용할 경우 전송구간에서의 노출을 피할 수 없으므로 서버영역에서만 사용할 데이터가 아니라면 공유에 제한이 있을 수 있습니다.

예를들어 로그인 이후에 이름(이름의 경우는 민감한 정보인지 판단은 사이트 별로 다를 수 있겠지만)이나 보유하고 있는 포인트 정보등 http영역에서도 출력해 줄 필요성이 있는 경우 해당 데이터를 공유할 수 있는 방법을 강구해야 합니다. 

데이터 공유를 위한 구현 방법에는 여러가지가 있겠지만 몇가지 예를 들어 보겠습니다.

1) 세션 쿠키 이외에 별도의 쿠키를 이용하여 공유

 세션 쿠키와는 별도로 공유할 필요가 있는 데이터를 직접 상위 도메인의 쿠키를 이용하여 공유하는 방법입니다. 쿠키에 공유 데이터에 접근할 토큰을 설정하거나 해당 데이터를 직접 쿠키에 저장하는 방법 있습니다. 물론 쿠키를 이용하기 때문에 아주 민감한 데이터는 공유할 수 없습니다. 데이터의 민감도가 바뀔 경우 이미 설정된 쿠키는 삭제(회수)가 어려울 수 있으므로 가급적 토큰을 이용한 방법을 추천합니다. 쿠키에 직접 저장할 경우에는 암호화 등을 이용하여 간단한 보안수단을 이용하는 것도 바람직 하겠습니다.

2) 임시 토큰을 이용하는 방법

 로그인 시 1회용 토큰을 발행하고 해당 토큰을 이용하여 서버 영역에 별도로 세션을 매핑 시키거나 공유할 공간을 확보하는 방법을 생각해 볼 수 있습니다. 하지만 1번에 비해 구현이 복잡하기 때문에 그다지 추천하고 싶지 않습니다.

※ 데이터 공유는 가급적 서버 영역에서 한정 짓는 편이 바람직 할 것으로 생각되며 

    민감한 정보가 http영역을 통해 전송되지 않도록 세심한 주의가 필요합니다.

• 4. 별도의 Secure 속성의 쿠키를 이용

 마지막은 세션쿠키는 항상 http로 발행되도록 어플리케이션을 구성한 후 https영역 보호하기 위한 별도의 쿠키를 발행하는 방법입니다. 

 구현방법을 간단하게 설명해 보면 아래와 같습니다.

1.         1) WAS의 설정이나 어플리이션에서 세션 쿠키를 직접 발행하는 방법을 통해 세션 쿠키는 secure속성이 없는 상태로 발행되도록 설정
2.         2) https영역에 최초 접속했을 경우 별도의 secure 쿠키를 발행하고 해당 쿠키 값을 세션등 서버영역에 해당 값을 보존
1.         3) 이후 https프로토콜로 접속할 경우에는 클라이언트가 전송한 secure 쿠키의 값과 서버영역에 보존된 값을 비교하여 일치하지 않는 경우
               세션 쿠키 누출의 가능성이 있는 것으로 판단하여 접속을 차단

※ 이 방법은 서브 도메인을 이용한 방법에서 필요했던 세션간(http와 https영역의 세션) 데이터 공유를 위한 구현보다는 간단하기 때문에 간단하게 적용할 수 있지만 프로토콜간에 동일한 세션을 사용하기 때문에 해당 구현에 미스가 있을 경우  별도의 검증 프로세스가 필요하며 검증 프로세스가 제대로 동작하지 않을 경우 전체 영역이 뚫릴 수 있는 가능성이 있으므로 구현간에는 세심한 주의가 필요합니다. 또한 검증용 쿠키는 세션 쿠키와 동일한 라이프 사이클을 가지도록 설정(쿠키의 세션 쿠키 속성을 설정)해야 이전 세션의 검증 쿠키 전송에따른 서버 영역에서의 오검증을 막을 수 있습니다.

위에서 언급한 방법중에서 개인적으로는 역시 전 영역을 https로 통합하는 방법을 추천해 드리고 싶습니다. 프로토콜 전환간에도 세션을 안전하게 보호하기 위해서 어플리케이션의 별도 구현이 필요하므로 구현에 따른 유지보수 비용, 구현 미스에 따른 개인정보 유출 가능성 등에도 대비해야 하기 때문입니다. 게다가 프로토콜을 혼용해서 사용할 경우에는 각 영역별로 사용할 데이터에 대한 민감도에 대한 평가를 사전에 해야하기 때문에 설계단계에서의 비용도 추가로 발생할 가능성이 있습니다.

또한 최근에 구글 크롬의 경우는 http프로토콜을 이용한 접근의 경우 안전하지 않다고 표시하기 때문에 사이트 자체에 이미지에도 부정적인 영향을 미칠 수 있으며 완벽하지는 않지만 페이크 사이트 혹은 피싱 사이트에 대해서도 약간의 대책이 될 수 있기 때문에 적극적으로 검토해보는 것이 좋겠습니다.