초보 웹 개발자를 위한 세션의 이해 - #02

초보 웹 개발자를 위한 세션의 이해 - #02

 

- 앞의 글에서 이어서... (링크 : http://kinesis.kr/entry/초보-웹-개발자를-위한-세션의-이해-01)

 

그렇다면 우선적으로 세션과 쿠키가 없다면 내가 왔다갔다는 정보나 무엇을 요청했다라는 기록이 남지 않는다는 것인 이해 했다고 보고, 그럼 웹 서비스는 세션이라는 녀석과 쿠키라는 녀석을 어떻게 이용하여 서로를 식별하고 인증했음을 구분할 수 있는 것일까?

 

이는 사실상 명찰과 고객명단 과 같은 이미지로서 생각해보면 이해하기가 쉽다.

 

요컨데 방문하기 전부터 『 나 』 라는 존재를 보여주기 위한 일종의 『 명찰 』 같은 것을 준비해 방문하고, 방에 들어서려는 순간 『 내가 언제 어디에서 와서 무엇을 하고 갑니다. 몇일 또는 몇시간 이내에 재 방문할 수 있으니 기억하고 있어주시요. 』라고 기록해두면 되는 것이다.

  

그리고 재 방문하게 되는 순간 자신이 사용했던 명찰을 다시 보여주며 『 앞서 이러한 문제로 인해 와서 신분증명을 했으니, 나는 이번에 어떠한 작업이나 요청을 하고자 합니다. 그러니 방문 시간을 다시 갱신해주세요 』 라고 하면 되는 것이다.

 

이런 과정에 사용되는 것이 바로 세션과 쿠키인 것이다. 세션은 앞서 말한 『 작업의 방 측 』에서 방문자를 인식하기 위해 방문자의 정보를 담아둔 정보기록지가 되는 것이고, 쿠키란 『 방문자 측 에서 제시하는 명찰 』 이자 방문자측이 가지고 있는 메모장으로 서로가 인증할 수 있는 키를 가지고 있나 확인하는 목적으로서 사용이 되는 것이다.

 

이렇게 되면 다시 방문하더라도 클라이언트 측에서는 "앞서 방문했을때 발급받은 인증코드가 내 명찰에 쓰여져 있으니 확인하고 이전과 같은 권한을 주세요" 라고 요구할 수 있게 되는 것이고, 서버측에서는 "당신이 앞서 발급 받았다며 제시한 인증코드가 현재 폐지되지 않은 기록에 남아 있으니 당신이 하고자 하는 작업을 하고 가세요." 라고 확인해 줄 수 있는 것이다.

 

그럼 여기까지 『 세션이 왜 필요한가? 』 와 『 세션이 사용(이용)되는 방식 』 에 대해 가볍게 이해해 보았다.

 

그렇다면 여기서 또 다시 의문점이 하나 발생한다.

 

세션을 발급 받았다면 그 상태 그대로 두고 나중에 방문할때 그냥 바로 사용하면 되지 않는가?

 

라는 물음이 바로 그것이다. 요컨데 왜 구태여 만료시간을 두고 폐지를 해야하는가 라는 물음이 발생하는 것이다. 이러한 만료가 있는 이유는 보만과 한정적 자원이라는 두가지 요소에 기인한다.

 

 

첫번째로 보안적 문제를 예를 들어 살펴보자.

 

당신은 회사 내의 작업실에 들어가기 위해 만들어진 보안카드를 받았다. 그런 당신은 어느날 하루는 잠시 커피를 마시며 휴식을 취할 요량으로 커피숍을 방문했다. 그런데 휴식을 취하며 심리적으로 방심해 있는 사이, 악의를 가진 누군가가 당신이 모르게 보안카드를 훔쳐 사라졌다. 나중에 회사로 들어가려던 당신은 보안카드가 사라져 있는 것을 확인하고 사유를 호소하며 회사에 들여보내 줄 것을 요청 했지만, 보안책임자는 이미 자신의 이름으로 누군가가 체크인 되있으므로 믿을 수 없다며 들여보내줄 수 없다며 당신을 쫒아냈다.

 

나중에 회사에서는 중요 데이터가 손실된 것을 확인하고 그 책임을 당신에게 물어 책임질 것을 요구하게 되어 당혹스러운 상황에 처하게 되었다. 

 

위는 세션이 유니코드하며 중복되지 않게 생성되어야 하는 이유를 일부 포함하고 있다. 예에서는 보안카드를 훔친 것으로 표현했지만 이는 실제 컴퓨터 보안에서 흔히 사용되는 방법이며, 실제로 자신이 위장하고자 하는 사람에게 발급되어 있는 세션 ID를 알고 있다면 서버측에 위장한 세션 ID 값을 던져 속이는 방법을 통해 사용자 인증을 속일 수 있다.

 

따라서 보다 보안이 강화되는 경우에는 단일 사용자에 대해서 발급되는 세션의 수를 1개로 제한을 한다거나, 세션이 발급된 IP 주소를 수집하여 IP 대조까지 하는 보안 처리 작업을 내부적으로 시행하여 차단하기도 한다. 누군가가 인증을 하고나서 당신에게 발급된 세션 ID를 어렵지 않게 얻어낼 수 있고, 그 처리를 쉽게 조작하여 접근할 수 있다면 당신이 사용할 수 있는 권한 역시 상대방에게 그대로 노출되게 된다.

 

이렇다 보니 세션에 대한 ID는 암호화하여 발급, 보유하여 서로 대조하여 사용자를 확인하는 방식을 이용하며, 일정시간이 지나면 다시 새로 로그인을 하게 하여 새로운 세션 ID 발급을 위해 세션에 만료시간을 두도록 하고 있다. 무엇보다 이 세션이 만료가 되지 않는다면 아주 단순하게 당신이 자리를 비운 사이 누군가가 컴퓨터를 접하게 되는 순간 당신이 보고 있던 내용, 당신이 작성해두었던 내용. 당신이 사용할 수 있는 권한을 모조리 사용할 수 있다는 상황이 된다.

 

 

두번째로 한정적 자원에 예를 들어 살펴보자.

 

당신은 회사에 방문하여 인증했던 사람의 기록을 남겨두기로 했다. 방문자가 오면 방문했던 기록에서 찾아 바로 업무를 볼 수 있게 해주고자 하여 기록을 시작했는데, 기록이 너무 많아지다보니 오히려 방문자가 전에 왔었는지 확인하기 위해 소요되는 시간이 너무나도 길어지고, 상대방도 기다리다가 업무에 소요해야할 시간의 일부를 대기 시간으로 소모해 버리는 현상이 발생되기 시작했다. 이윽고는 업무처리들이 밀려 기간 이내에 마무리해야할 업무가 시간에 쫒기는 상황에 도달해 버렸다.

 

위는 방문자 기록을 만료시키지 않고 누적 시켯을 때를 예를 든 것이다. 1번만 인증하고 나중에는 그냥 방문만 하는것이 편할지는 모르겠지만 방문자수가 많아지고 기간이 늘어나면 찾아내야하는 기록의 양이 너무 많아 찾아내는 것에 시간이 너무 많이 들어가게 된다. 또한 기록할 수 있는 공간의 크기가 한정되어 있기 때문에, 그 양이 꽉차게되면 그 이후의 새로운 사용자는 인증을 받아줄 수가 없다. 이는 비효율적인 방법이 될 수 밖에 없다.

 

이러한 요소로 인해 세션에는 만료시간이 필수불가결하게 만료시간을 필요로 하게 된다. 이를 통해 보안에 대한 위협요소를 줄이기 위함과 동시에, 검색해야하는 세션의 개수를 줄임으로서 인증된 사용자의 파악 및 식별의 속도의 향상을 꾀하는 것이다.

 

그렇다면 세션의 연장에 대해서는 어떤가 한번 확인 해 보자.

 

- 다음편에 이어서

- 2012년 10월 11일 Kinesis 작성.

 

본게시물의 저작권은 Kinesis 에게 있습니다. 무단 펌을 불허합니다.

단, 본 게시물로의 링크는 허용합니다.