Http와 Https 프로토콜 간에 안전하게 세션 공유하기
일반적으로 웹 어플리케이션을 서비스할 때 개인정보와 같이 민감한 정보가 포함된 페이지는 https(HTTP over SSL)프로토콜, 이외의 일반적인 페이지는 http프로토콜을 이용하여 구성하는 웹 어플리케이션이 상당수를 차지합니다. 이렇게 http/https프로토콜이 혼재해 있는 경우 페이지 이동간에 프로토콜이 변경되면 세션 공유가 되지 않아 세션이 끊기는 문제가 발생하는 경우가 있습니다. 본 아티클에서는 http와 https 프로토콜을 혼용하여 사용할 경우 안전하게 세션을 공유하는 방법에 대해서 알아보도록 하겠습니다.
세션 공유가 안되는 원인
위와 같은 환경에서 세션 공유가 되지 않는 원인은 기본적으로 웹 어플리케이션에서 세션 관리를 위해서 주로 사용하는 쿠키의 특성에 기인합니다. 쿠키는 웹 사이트의 호스트명(Hostname), 하위 패스 등의 속성 조합으로 관리되며 매 요청시 평가되어 조건에 해당하는 경우 전송됩니다. 여기서 문제가 되는 속성이 바로 secure 속성입니다. secure 속성이 지정되지 않은 경우에는 http, https 양쪽 모두 쿠키가 전송되지만 secure 속성이 지정된 경우에는 https 프로토콜에서만 전송되기 때문입니다.
예를 들어 https로 되어있는 페이지로 최초 접속한 사용자에게 발행된 세션 쿠키에 secure 속성이 있는 경우 해당 사용자가 로그인 후에 http 프로토콜의 페이지로 이동하는 경우 세션 쿠키가 전송되지 않기 때문에 서버에서는 신규 접속으로 인식하여 세션 쿠키를 새로 발행하게 됩니다. 따라서 사용자는 로그인 하였음에도 불구하고 비 로그인 상태가 되어 다시 로그인 해야하는 상황이 발생되게 됩니다. 사용자중에는 로그인 페이지를 북마크에 넣어두고 접속하는 경우가 있기 때문에 특정 사용자에게 많은 빈도로 나타날 가능성이 있습니다.
해결책
- 전 영역을 http프로토콜로 통합
- 전 영역을 https프로토콜로 통합
역시 가장 간단하면서도 강력한 방법은 https프로토콜로 통합하는 방법입니다. 하지만 https프로토콜로 통합을 시도할 경우 아래와 같은 이유로 내부/고객의 반발에 직면하거나 제약사항 등에 의하여 선택할 수 없는 경우도 있습니다.
먼저 반발에 부딪히는 경우는 주로 성능적인 측면일 가능성이 높습니다. https프로토콜을 사용한 경우 커넥션 확립, 암호화/복호화 등의 작업에는 상당한 머신파워가 필요하다는 인식이 있기 때문에 하드웨어 비용이 증가할 수 있기 때문입니다.(정확히는 성능문제에 기인한 인프라 비용 증가 혹은 사용자 경험 저하에 의한 문제) 물론 최근에는 하드웨어 가격이 매우 저렴해 졌고 성능도 과거에 비해서 비약적으로 발전하였기 때문에 하드웨어를 문제삼아 https 프로토콜을 이용하지 않는 것에 대해 이견도 많이 있습니다.
위의 문제가 아닐 경우는 https를 지원하지 않는 클라이언트 혹은 크롤러 등이 이용할 가능성이 있을때 입니다. 이 경우는 통제할 수 없는 영역의 문제이기 때문에 어쩔 수 없는 경우이기도 합니다.
이 방법은 어플리케이션의 구현은 거의 손대지 않아도 되고 경우에 따라서는 간단한 서버 설정만으로 가능할 수 있기 때문에 이점이 많은 방법이라고 하겠습니다.
※가장 주의할 점은 http를 프로토콜로 직접 접근시 적절한 처리를 하지 않거나 https에서 세션 쿠키를 발행했지만 적절한 어플리케이션 서버 설정 혹은 어플리케이션을 구현을 하지 않아 secure속성이 없는 상태로 세션 쿠키가 발행되지 않도록 해야 한다는 점입니다. secure속성 없는 상태로 세션 쿠키가 발행된 경우 사용자 실수(브라우저의 주소창에 프로토콜 입력 미스) 혹은 인터넷 상의 악의를 가진 링크를 통해 전송구간 암호화가 되지 않은 상태로 네트워크 상에 쿠키 정보가 전송될 가능성이 있습니다. 이럴 경우 세션 하이재킹 등에 취약점에 의해 개인 정보 누출 문제가 발생할 가능성이 있습니다.
- 서브 도메인(sub domain)을 이용하여 http와 https프로토콜의 호스트를 별도로 서비스
- 별도의 Secure 속성의 쿠키를 이용
- WAS의 설정이나 어플리이션에서 세션 쿠키를 직접 발행하는 방법을 통해 세션 쿠키는 secure속성이 없는 상태로 발행되도록 설정
- https영역에 최초 접속했을 경우 별도의 secure 쿠키를 발행하고 해당 쿠키 값을 세션등 서버영역에 해당 값을 보존
- 이후 https프로토콜로 접속할 경우에는 클라이언트가 전송한 secure 쿠키의 값과 서버영역에 보존된 값을 비교하여 일치하지 않는 경우 세션 쿠키 누출의 가능성이 있는 것으로 판단하여 접속을 차단
위에서 언급한 방법중에서 개인적으로는 역시 전 영역을 https로 통합하는 방법을 추천해 드리고 싶습니다. 프로토콜 전환간에도 세션을 안전하게 보호하기 위해서 어플리케이션의 별도 구현이 필요하므로 구현에 따른 유지보수 비용, 구현 미스에 따른 개인정보 유출 가능성 등에도 대비해야 하기 때문입니다. 게다가 프로토콜을 혼용해서 사용할 경우에는 각 영역별로 사용할 데이터에 대한 민감도에 대한 평가를 사전에 해야하기 때문에 설계단계에서의 비용도 추가로 발생할 가능성이 있습니다.
또한 최근에 구글 크롬의 경우는 http프로토콜을 이용한 접근의 경우 안전하지 않다고 표시하기 때문에 사이트 자체에 이미지에도 부정적인 영향을 미칠 수 있으며 완벽하지는 않지만 페이크 사이트 혹은 피싱 사이트에 대해서도 약간의 대책이 될 수 있기 때문에 적극적으로 검토해보는 것이 좋겠습니다.