해커에게 필요한 웹 구조 해부하기 2
안동 도산서원과 HTTP 웹 구조를 유추하기 전 개념 환기
웹 해킹은 웹 사이트의 구조와 동작 원리를 이해하는 것에서부터 시작한다. 실제로 웹의 모의해킹 과정에서 초기의 며칠간은 해당 사이트를 만든 사람의 코딩 스타일, 사이트 구조, 습관, 인수 전달 방식 등을 파악한다. 이때 기본적으로 사용되는 것이 웹 스캔, 웹 프락시를 이용한 패킷 분석, 구글 해킹 등인데, 이는 웹 해킹에 소요되는 대부분의 시간을 차지할 만큼 중요한 과정이다. 이 웹 사이트에 대한 이해만 제대로 수행하면 웹 해킹은 무척 쉬워진다(양대일, 2013).
누가 보면 도움이 될까? : HTTP 1.x 프로토콜 기반의 웹의 동작 방식을 알고 웹 사이트의 취약점을 파악하는 동시에 해당 취약점의 노출을 막고 미연에 해킹 사고를 방지하고자 웹 사이트 구조의 이해를 잡으려는 그레이 햇 해커 대상.
어떻게 활용할 것인가? HTTP / HTTPS를 통해 주고받는 메시지 바디부의 페이로드를 분석해서 악성코드 삽입 여부의 정탐이 목적.
무엇을 다루나? 7 계층 애플리케이션 계층에서 오고 가는 메시지들이 동작하는 웹 사이트의 구조
쉬는 날 안동 주변의 도서관을 찾으러 차를 타고 나가는 도중 안동대학교까지 찾으러 갔다. 중간에 안동대학교 표지판이 보였지만 엄한길로 빠져 국도를 타고 근처 관광지인 도산서원까지 누볐다. 도산서원 입구를 들어서기 전에 주변의 풍경을 감상하고 이황이 제자들을 가르쳤던 이 도산서원에 다다랐다. 역대 최고의 기온을 경신함에도 불구하고 견학을 나온 고등학교 남학생들이 서원을 가득 채웠다. 그리고 내려오는 길목에서는 여학생들이 한 관광 가이드 선생님으로부터 안내를 받으며 올라오고 있었다. 그들의 킬킬대며 수다 떠는 소리를 뒤편으로 하고 HTTP 웹 사이트 구조를 이 도산서원의 전체 조망에 유추하여 단박에 꿰뚫을 수 있는 글을 쓸 수 있을 거라는 영감이 떠올랐다.
같은 제목의 이전 세션에서 웹에 대한 정보를 수집할 때는 여러 가지 방법을 사용할 수 있다고 하였다. 대표적인 웹 스캐너로 Acunectix를 예로 들었는데, 이러한 자동화 툴을 쓰지 않더라도 웹에 대한 정보 수집은 주로 웹의 메뉴를 하나하나 클릭해보며 수작업으로 동작을 파악하기도 한다.
그래서 웹 취약점 스캐너를 통한 정보 수집은 빠른 시간 내에 다양한 접속 시도를 수행할 수 있다는 장점이 있지만, 웹 구조를 파악하고 취약점을 수집하기가 쉽지 않다는 단점이 있다. 각 페이지의 링크 정보를 따라가는 것이므로 웹 페이지에서 링크로 제공하지 않는 페이지는 구조 분석이 어렵기 때문이다(양대일, 2013).
한편 각 페이지에서 링크 정보를 따라가며 웹 사이트의 웹 페이지를 로컬에 저장해주는 Web Zip이라는 프로그램이 있는데, 웹 스캔은 Web Zip이 웹 페이지를 수집하는 원리와 같다. 웹 취약점 스캐너를 통해 확인된 취약점이 실제로 취약점이 존재하는 경우도 있지만 그렇지 않은 경우도 많다.
즉 웹 프로그램은 자유스럽게 만들어지고 변형도 다양해 웹 스캐너는 취약점을 정확히 잡아내기가 거의 불가능하다.
따라서 스캐너가 발견된 취약점은 개별 확인을 거쳐 유효성을 확인하는 과정이 필요하다(양대일, 2013).
서울대 출신의 저자가 실무적으로 이 정도로 연구하여 발견한 내용이라면 역시 서울대 출신답다고 속으로 감탄을 자아내지만, 단지 외서의 번역에 의한 기술에 불과하다면 역시나 하는 탄성만 지르게 만들 수도 있다. 과연 양자 중 어느 것이 사실일까?
웹 해커가 되기 위해서는 많은 시간을 들여 웹 서버와 웹 브라우저 사이의 패킷을 읽어봄으로써 전송되고 전송되는 데이터들이 어떤 의미를 가지는지, 그리고 어떤 역할을 하는지 생각해봐야 한다. 그만큼 웹 해커의 능력은 Burp Suite나 Paros와 같은 웹 프락시를 통해 웹 서버의 서비스 구조를 이해하는 데 있다고 할 수 있다(양대일, 2013).
필자가 웹 사이트의 구조를 절단 내려고 하는 까닭을 이제 정확히 파악했는가? 그리고 서울대 출신의 한 저자가 이것의 필요성을 당위적으로 언급할 정도이니 본인이 내세우는 이유보다 위의 소견 논거들을 통해 웹 사이트 구조를 절단낼 가치가 충분하지 않다고 느끼나?
세 번째 섹션에서 도산서원 출입문(웹 사이트의 입구)으로 진입하기 전에 몇 가지 기본 용어만 다시 짚어보자.
해커들이 서버와 클라이언트 사이에 오가는 패킷을 위변조 하고자 하는 것은 HTML이다. 어떤 언어(ASP, JSP, PHP 등과 같은 CSS클라이언트 사이드 스크립트 언어나 VB나 JavaScript와 같은 SSS서버 사이드 스크립트)로 개발했든지 웹 프락시를 통해서 확인하는 것은 HTML이다.
MARKUP LANGUAGE 마크업 언어란?
HTML과 웹의 관계는 이동식 활자와 인쇄기의 관계와 같다. 인쇄기가 이동식 활자로 조판을 한다면, 웹 개발자는 HTML로 웹페이지를 설계한다. HTML이 없었다면 웹도 없었을 것이다. 마크업 언어는 편집자가 종이 원고에 써놓은 표시에서 진화한 것이다(짐 볼턴, 2017).
1980년대 말 이른바 위지윅(What You See is What You Get, WYSIWYG)이라는 소프트웨어가 출현하자 마크업 언어의 시대가 끝나는 것처럼 보였다. 하지만 전혀 그렇지 않았다. 1991년 팀 버너스 리는 SGML의 파생어를 사용해서 웹페이지를 만들었고, 그것을 하이퍼텍스트 마크업 언어, HTML이라고 불렀다(짐 볼턴, 2017).
HTML이 18가지의 기본 명령에 따르는 단순성에 힘입어 웹 확산의 주요 원인이 됐다면, 1990년대 중반 브라우저 간의 경쟁 속에서 여러 버전의 HTML이 출현하면서 웹페이지가 보이는 방식이 HTML마다 달라졌다. 이 문제를 해결하기 위해 버너스 리는 1996년 월드와이드 웹 컨소시엄 W3C을 결성했고, 그때부터 HTML 기준이 준수되어 오고 있다(짐 볼턴, 2017).
웹에서 널리 사용된 또 다른 마크업 언어는 XML(eXtensible Markup Language)이다. XML도 W3C에 의해 개발되었는데, 그 목적은 개발자가 자신이 필요한 모든 태그를 생성할 수 있는 유연성을 도입하기 위해서였다. HTML과 XML의 주요 차이점은, HTML이 브라우저가 읽을 수 있도록 설계된 반면, XML은 개발자가 선택한 애플리케이션이 읽을 수 있도록 설계되었다는 점이다(짐 볼턴, 2017).
현 직장에서 동갑내기 동료와 위의 내용으로 입씨름을 벌인 적이 있었다. 그 친구는 XML언어는 HTML과 경쟁하기 위해 Microsoft사에서 제작한 언어라는 것이었다. 나의 주장은 이전에 Java DOM Parsing에 대해 다룬 섹션에서와 같이 XML이란 HTML와 대별적으로 사용하기 위해 탄생한 것이 아니라, 웹 사이트의 속도 개선과 효율성을 위해서 만들어진 HTML과 같은 웹페이지의 규약 정도였다. 어쨌든 XML은 개발자가 선택한 애플리케이션(이를테면 Ajax이고 이게 마소에서 개발한 거다)이 읽을 수 있도록 설계되었다는 점이 포인트이다.
XML과 Web 2.0의 의미를 내포하는 Ajax(Asynchronous JavaScript and XML, 자바스크립트와 XML의 비동기)에 대해서는 본선 무대 정도에서 한 번 다뤄보겠다.
참조
1) 양대일. (2013). 정보 보안 개론: 한 권으로 배우는 핵심 보안 이론, 서울: 한빛 아카데미.
2) Boulton, J. (2014). 100 Ideas that changed the web. London : Laurence King. 한국 번역판 역자 홍석윤 (2017). 웹을 뒤바꾼 아이디어 100. 서울 : 시드페이퍼.
