일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- D330
- ASP.NET
- 단열
- Lenovo D330-10igm
- 우분투
- network
- 진단항목
- 이보드
- HTML5
- 문자열
- 인테리어
- WEB
- 고전게임기 만들기
- Web Programming
- fiddler
- c#
- ubuntu
- 자바스크립트
- 고전게임
- 안드로이드
- 인증 및 세션관리
- 웹
- 한컴오피스
- retropie
- 피들러
- 윈도우 8
- D330-10igm
- 셀프인테리어
- 네트워크
- 보안
- Today
- Total
Kinesis´s Open Document
진단항목 : 안전한 인증 및 세션 관리 - 통신과정 #01 본문
※ 최대한 이해하기 쉽게 서술하고자 하였으나 보안 지식은 기초라 할지라도 일반적인 기초 과정보다 높은 수준을 필요로 합니다.
※ 본 내용은 초안이며, 저작권은 저 Kinesis(Hae Kwang, Kim) 에게 있으므로 무단으로 펌하여 재배포하는 것을 금지합니다. (단, 본 게시물의 일부만을 발췌하여 출처 주소를 남겨 본 게시물에 접근할 수 있는 링크를 남기는 경우는 허용합니다. 이는 제가 여러분들을 믿고 양질의 게시물을 작성하고 여러분들은 접할 기회를 제공받기 위한 서로의 배려입니다.)
※ 본 내용은 보안 기초를 학습하는 사람이나, 개발자들에게 유용할 수 있습니다.
최종본 바로보기
안전한 인증 및 세션 관리를 위해서는 크게 통신과정과 처리과정 및 보관과정 세 가지 과정과 각 과정에서 발생할 수 있는 세부 이슈를 이해해야 한다. 이를 고려하지 못할 경우 공격자는 미처 예상하지 못한 취약점을 이용해 인증 및 세션을 탈취하여 사용자의 인증 보안을 위협할 가능성이 높다. 이러한 피해를 예방하고 각 과정에서의 발생할 수 있는 이슈사항을 해결하기 위해 여기서 우리는 기초적인 수준의 네트워크 및 암호학과 쿠키와 세션과 더불어 파일 시스템에 대해 이해하고 있을 필요가 있다.
자 그럼 이제 세부적으로 고려해야 할 이슈들에 대해 살펴보자.
첫 번째로 살펴봐야 할 부분은 통신과정이다.이 부분에 대해 이해하고 해결 방안을 내놓기 위해서는 네트워크 와 암호학을 기본으로 어떠한 방식으로 인증을 처리할 것인지 처리과정 및 인증을 식별하는 방법 또는 방식에 대해 가늠하거나 인지하고 있어야 한다. 이 통신과정의 범위는 클라이언트가 인증을 위해 발생되는 Request 에서 처리가 끝나고 결과 값을 돌려 받는 Response 까지의 과정이 포함이 되기 때문이며, Request와 Response 라는 이 2가지 액션은 클라이언트가 서버측과 통신을 완전히 종료하기 전까지 지속적으로 발생하는 반복되는 이벤트이기 때문이다.
우선 통신과정에서 발생하는 제일 첫 번째 이슈는 도청이다. 클라이언트와 서버는 물리적으로 독립적으로 떨어져 있는 상태인데 우리는 이 두 가지를 네트워크를 이용해 연결하고 있다. 쉽게 말해 중간에 요청과 응답을 전달해 주는 전달자가 있는 개념으로 볼 수 있다. 그런데 이 전달자는 1명이 될 수도 있고, 복수의 여러명이 될 수도 있다. 그러나 다이렉트로 연결되지 않는 이상 일반적으로는 2개 이상의 전달자를 거쳐 전달되는 구조의 형상을 갖는다. 그리고 이 과정에서 전달자는 전달되는 데이터를 살펴볼 수 있다는 가능성을 내포하고 있다.
비 전공자를 위한 추가 서술
이해를 좀 더 쉽게 비유를 통해 설명하자면 전달자는 흔히 우리 주변에서 우리의 편의를 위해 고군분투하고 있는 배달원(또는 우편배달부)으로 볼 수 있다. 그리고 이 배달원들은 배송 과정을 표준적이고 원할하게 하기 위해 배달 프로세스를 가지고 있다. 재미있게도 네트워크는 이런 프로세스를 흉내내어 개방형 시스템간 상호 접속 이라는 OSI 모델(Open Systems Interconnection Reference Model)이라는 프로세스를 따라 통신을 하고 있다. 쉽게 말하면 통신(배달)을 위한 절차 이자 약속에 따라 처리되고 있다고 할 수 있다.
다시 이해를 쉽게하기 위해 인간사회를 기준으로 이 절차에 대해 살펴보자. 만약 자신이 친구에게 어떠한 메시지를 우편을 이용해 보낸다고 가정하자. 그러면 우리는 배달을 위한 절차 중 하나로 보내고자 하는 메시지를 포장한다. 그리고 이를 목적지인 친구에게 무사히 보내기 위해 목적지를 포장의 표면에 기재하여 접수를 한다. 그러면 접수된 우편은 배달을 하는 업체(보통 우체국)에서 내부적인 프로세스에 의해 집화 및 분류를 하고 배송 수단을 이용해 배송을 시작하게 되고 다시 목적지 근처에 있는 업체에 배달이 된 후 집화 및 분류를 거쳐 친구가 사는 목적지까지 이동해 당사자에게 전달을 하는 것으로서 전달 이라는 일련의 목적을 이루게 된다. 그리고 그 우편을 받은 친구는 그 우편을 보고 내용을 이해, 해석 및 응답작성 이라는 일련의 프로세스를 거친뒤 다시 배달원을 통해 자신에게 응답이라는 목적을 달성시킨다.
그런데 이 과정에서 배달원이 내용물을 꼭 보지 않는다고 보장할 수 있을까? 앞서의 내용은 바로 이 가능성에 대해 이야기를 하고 있는 것이다.
일반적인 통신과정에서 전달자는 메시지의 전달이라는 주어진 역할에 충실하기 때문에 내용물(메시지)을 확인하게 될 일은 매우 낮거나 드물다. 그러나 문제는 악의적인 목적을 가지고 전달자로 위장한 구간을 통해 통신할 때 문제가 발생한다. 요청자가 이 전달자에게 메시지를 전달 한 순간 이 전달자는 자신을 거친 메시지의 내용을 알 수 있게 되는것이다. 그리고 메시지의 내용중에 중요한 정보나 민감한 정보가 담겨있어 노출이 되었다면 그 순간부터 전달자는 언제 가면을 벗고 공격자라는 새로운 위치에 서게 될 지 알 수 없다.
비 전공자를 위한 추가 서술
다시 이해를 하기 쉽게 비유를 빗대어 표현하자면 이렇다. 일반적으로 배달원(우편배달부)는 우리가 보낸 메시지의 포장을 뜯어보지 않는다. 그러나 감시나 검열을 위해 동작하는 업체(보통 우체국)가 포장물을 뜯어 문제되는 것이 있는지 없는지 확인해 보고 내부적으로 다시 포장을 하여 본래의 목적지에 맞추어 전달을 한다면 어떻게 될까? 배달원은 오가는 내용을 알 게 될 수 있는 것이고, 메시지를 받아보는 사람은 본래의 포장의 모습을 알고 있지 않는 이상 해당 포장이 재 포장이되어진 것인지 알 수 없으므로 메시지가 노출이 되었는지 알 수가 없다.
반면, 배달원은 전달되는 내용을 살펴보는 도중에 어떠한 내용이 오가는지를 알 수 있고, 그 과정에 집안에 출입할 수 있는 방법에 대해 서술이 되어있는 내용을 확인하거나 한다면, 그 배달원은 집에 침입을 하거나 또는 남들은 알지 못하는 요청자 및 수신자 간의 중요한 비밀을 가지고 어떻게 접근해 올 지 알 수 없는 것이다.
더욱 중요한 사실은 무엇보다 우리는 가까운 곳에 우체국과 같은 모습과 같은 역할을 하는 업체가 들어선다면 "아, 새로 우체국이 생겼구나" 라고 생각하지 "저 우체국이 재대로 된 프로세스를 준수하는 우체국일까?"하고 의심하고 검증하지 않는다는 사실이다. 비록 그 업체가 실제로는 배달물을 받아두고 내가 모르는 사이에 내용물을 확인하고 다시 포장하여 다른 우체국에다 접수를 시킨다 하더라도 우리는 쉽게 알아 채지 못할 것이다.
이러한 가능성에 대비하기 위해 우리는 보내고 받는 메시지를 "암호화"하는 대안을 제시해 볼 수 있다. 메시지를 보내기 전에 미리 사전에 전달되는 메시지를 암호화 하여 보호함으로써 중요하거나 민감한 정보가 노출되는 피해를 예방할 수 있다는 기대를 갖을 수 있기 때문이다.
'기획 시리즈 > 보안 : 진단항목 이해하기' 카테고리의 다른 글
진단항목 : 안전한 인증 및 세션 관리 - 보관과정 #02 (0) | 2016.06.29 |
---|---|
진단항목 : 안전한 인증 및 세션 관리 - 보관과정 #01 (0) | 2016.06.29 |
진단항목 : 안전한 인증 및 세션 관리 - 처리과정 #03 (0) | 2016.06.28 |
진단항목 : 안전한 인증 및 세션 관리 - 처리과정 #02 (0) | 2016.06.28 |
진단항목 : 안전한 인증 및 세션 관리 - 처리과정 #01 (0) | 2016.06.28 |
진단항목 : 안전한 인증 및 세션 관리 - 통신과정 #02 (0) | 2016.06.23 |