진단항목 : 안전한 인증 및 세션 관리 - 처리과정 #01

※ 최대한 이해하기 쉽게 서술하고자 하였으나 보안 지식은 기초라 할지라도 일반적인 기초 과정보다 높은 수준을 필요로 합니다.

※ 본 내용은 초안이며, 저작권은 저 Kinesis(Hae Kwang, Kim) 에게 있으므로 무단으로 펌하여 재배포하는 것을 금지합니다. (단, 본 게시물의 일부만을 발췌하여 출처 주소를 남겨 본 게시물에 접근할 수 있는 링크를 남기는 경우는 허용합니다. 이는 제가 여러분들을 믿고 양질의 게시물을 작성하고 여러분들은 접할 기회를 제공받기 위한 서로의 배려입니다.)

※ 본 내용은 보안 기초를 학습하는 사람이나, 개발자들에게 유용할 수 있습니다.

최종본 바로보기

두번째로 살펴봐야 할 과정은 바로 처리과정이다. 이 부분에 대해 이해하고 해결 방안을 내놓기 위해서는 WWW(World Wide Web)와 클라이언트(Client) & 서버(Server)방식 그리고 쿠키(Cookie)와 세션(Session)의 개념에 대해 가늠하거나 이해하고 있어야 한다. 기본적으로 웹은 태생적으로 Connection-less 방식의 통신을 하는 비 연결성 통신 구조를 가지고 있으며 이로인해 기본적으로 로그인을 시도해도 자체적으로는 로그인을 성공했다는 정보를 지속시킬 수가 없는 문제점을 가지고 있다. 이러한 연결 단절의 문제점을 해결하고 인증여부를 처리하기 위해 등장 및 활용하게 되는 것이 쿠키(Cookie)와 세션(Session)이기 때문이다.

처리과정에서의 이슈는 바로 이 처리과정이 어디서 수행되어지고 어떠한 형태로 발급되며 어떻게 인증여부를 처리 할 것인가에 대한 내용과 관련이 깊다. 그리고 이 처리과정은 인증여부를 기억하는 보관과정과도 관련이 깊어 안전한 인증 및 세션 처리를 위해서는 두 가지 요소를 복합적으로 바라 볼 수 있는 시야가 필수적이다.

처리과정에서 고려해야 하는 첫 번째 이슈는 인증우회 및 탈취이다. Web은 Connection-less에 기반한 통신방식으로 요청에 대한 응답을 받으면 연결이 끊어져 인증여부를 보관할 수 없는 구조를 가지고 있기에 초기 인증성공시 응답에 인증여부를 확인할 수 있는 정보를 포함하여 돌려준다. 그리고 다음 요청 때 앞서 발급 받았던 인증여부를 확인 할 수 있는 데이터를 가지고 인증을 검증하는 처리를 거친다.

비 전공자를 위한 추가 서술

예를들어 어떠한 목적을 가지고 해당 서비스를 제공하는 업체에 방문하고자 한다. 그런데 해당 업체는 규모가 커서 출입을 관리하는 사람과 서비스를 처리해주는 사람이 나누어져 있고, 내부에 출입하여 용무를 보기 위해서는 출입테스크에서 방문 목적과 신분정보를 인증하고 출입증을 발급받아야 업무를 볼 수 있다고 한다.

이때, 이러한 시스템을 왜 이용하는가를 고려해보면 인증이라는 개념에 대해 이해하기 쉽다. 일련의 상황을 예로 들자면 우선 출입구에서 통제를 하는 사람은 지금 입장하고자 하는 나를 알아 볼 수 있다. 그러나 출입이 많이 이루어져 나를 기억할 수 없거나 또는 출입을 관리하는 사람이 기억력이 좋지 않아 내가 인증한 사람인지 기억을 할 수 없다면, 우리는 출입을 할때마다 방문목적 및 신분정보를 기입하고 출입을해야 한다. 그런데 문제는 단순히 출입이 끝이 아니라 서비스를 제공하는 사람이나 서비스를 받으러 온 사람이나 내부에 있는 다른 사람들은 내가 직원인지 손님인지 알 수가 없다는 것이다.

이런 문제를 해결하기 위한 일환으로 앞서 방문목적 및 신분정보를 기입과정을 거쳐 출입증을 발급 받게 된다. 그리고 이 출입증으로 인해 비로소 우리는 방문을 허가 받은 사람이라는 것과, 손님이라는 존재로서 구분지어진다. 이 과정이 바로 인증을 위한 과정이고 인증여부를 확인할 수 있는 정보를 내게 부여하는 과정이다.

그런데, 모든 서비스가 한 번에 해결될 수 있으면 좋겠으나 예외의 상황이란게 항상 발생하기 마련이다. 마침 생리현상으로 인해 화장실에 가야 할 일이 발생했는데 화장실이 게이트 밖에 존재한다면 우리는 출입증을 발급 받았던 게이트를 지나 서비스를 받기 위한 공간을 벗어나야만 한다. 이때 출입증 발급 및 확인하는 시스템이 아니거나, 출입증 시스템을 사용은 하지만 반납 했거나, 출입증의 유효가 만료가 되었다면 우리는 서비스를 받기 위해 다시 방문목적과 신분정보를 확인하고 출입을 해야 한다. 그러나 출입증 시스템을 이용하는 환경이면서 아직 유효한 출입증을 가지고 있다면 해당 출입증을 보여주거나 확인함으로서 우리는 다시 서비스를 위한 공간에 방문목적 및 신분정보를 입력하는 과정을 생략하고 출입할 수 있는 것이다. 즉 이러한 과정이 바로 인증여부를 검증하는 하나의 예라 할 수 있다.

인증우회 및 탈취는 바로 이 인증을 검증하는 과정에서 존재할 수 있는 취약점을 이용하여 인증을 우회하거나 인증된 사용자로 가장하여 서비스를 이용할 수 있도록 해준다. 기본적으로 인증여부는 세션(Session) 또는 쿠키(Cookie)를 이용해 보관 및 처리하는데 인증우회 및 탈취의 공격형태는 인증처리에서 세션(Session)을 사용하는가 또는 쿠키(Cookie)를 사용하는가에 따라 다소 차이를 보인다. 세션을 이용하는 경우 세션아이디(SessionId) 또는 세션토큰(SessionToken)를 탈취하는 공격이 발생할 수 있으며, 쿠키를 사용하는 경우에는 쿠키데이터(Cookie Data)를 변조하는 공격이 발생할 수 있다.

비 전공자를 위한 추가 서술

이번에는 임시 출입증을 받은 자신이 잠시 휴식을 위해 커피숍 등에 나왔고 이 때 출입증을 차용하고 있는 것이 불편해 잠시 벗어 테이블에 올려두었다고 가정하자. 그런데 잠시 화장실을 갔다온 사이 출입증이 사라지거나 또는 복제가 너무 쉬워 누군가가 똑같은 출입증을 복제했다면 어떠할까? 자신의 출입증을 가져가거나 또는 복제한 제3자는 내가 용무를 보기 위해 찾은 서비스 업체에 들어가 "용무가 있어 잠시 볼일을 보고 왔는데, 아까전에 출입허가 받았던 사람입니다."하고 출입신청서 작성 과정을 생략한 채 출입 할 수 있을 것이다. 더불이 도난 당했거나 복제되었다는 사실을 알리 없는 서비스 업체 내의 직원들은 제3자를 정상적인 인증을 거친 방문자로 인식을 할 것이다.

다만 인증여부를 무엇을 이용해 처리하는가에 따라 공격방식의 차이가 있는데 세션 방식은 출입증에 회사에서 발급한 일련번호만을 서술하는 것으로 이 경우 해당 일련번호에 의해 인증이 되므로 공격자는 출입증을 탈취 하거나 동일한 일련번호로 복제만 가능할 뿐 해당 출입증이 어떠한 사람의 신분을 나타내고 권한을 가지고 있는지 확인할 수는 없다. 반면, 쿠키 방식은 출입증에 인증된 사람의 정보가 그대로 기재되어 있는 것으로 성함이나 권한 등이 같이 포함되어 있는 경우가 많아 어떠한 정보를 확인하는지 노출되는 것으로 인해 공격자는 이름이나 권한을 변조하여 관리자 등으로 신분을 변조하는 등의 공격이 발생할 수 있다.

간과할 수 없는 문제는 공격의 가능성이 존재함에도 불구하고 인증여부를 검사하기 위해서는 세션(Session) 또는 쿠키(Cookie)를 이용할 수 밖에 없다는 것이고, 심지어 세션을 이용하더라도 세션을 식별할 수 있는 세션아이디(SessionId) 또는 세션토큰(SessionToken)값은 세션쿠키(SessionCookie) 또는 세션헤더(SessionHeader)라는 형태로 클라이언트에 전달되어 변조 공격의 가능성을 내포하고 있다는 것이다.

이러한 문제 및 가능성에 대비하여 우선 Cookie를 이용한 인증보다는 Session에 기반한 인증여부 처리를 실시하도록 하며, 다른 IP에서 동일한 세션아이디(SessionId) 또는 세션토큰(SessionToken)이 중복되어 요청되었는지 검증하는 방법과, 동일한 세션아이디 또는 세션토큰에서 IP가 변경되는 경우 해당 변하기 전의 IP의 지역과 변한 후의 지역 IP 간의 거리상 시간 차이를 계산하여 유효성을 검증하는 방법 등의 도입을 검토해 볼 필요가 있다.

비 전공자를 위한 추가 서술

결론적으로 인증을 위해서는 인증을 요청하는 대상(손님, 클라이언트)에게 인증에 필요한 정보를 받아 인증을 할 수 밖에 없다. 이 과정에서 세션을 이용하던 쿠키를 이용하던 기본적으로는 인증발급여부는 대상이 가지고 있을 수 밖에 없고 이를 완벽하게 대처할 수 있는 방법이 없다고 할때 우리는 다른 해결 방안을 꺼내놓아야 한다. 그리고 그 방법은 우리가 가장 흔히 사용하고 접하게 되는 방법으로 바로 2차 인증이다.

다시 한 번 확인해 볼게요 "성함이 뭐라 하셨죠?" "태어나신 년월이 뭐라구요?" "정보보호를 위해 별도로 지정해 놓은 비밀번호는 무엇이신가요" 와 같은 것이 그것이다. 흔히 우리가 접하게 되는 문자인증, 이메일인증, OTP 인증 등이 바로 이러한 문제를 대체하기 위해 나타난 2차 인증이라 할 수 있겠다. 그리고 우리는 이러한 2차 인증 방법중 어떠한 방법이 대상(손님, 클라이언트)에게 번거로움을 줄이면서 보다 확실하게 당사자임을 증명할 수 있을지 고려해봐야 하는 것이다.