해커에게 필요한 웹 구조 해부하기 4
단순한 구조의 웹페이지
도식1. html 웹페이지를 트리구조로 각 엘리먼트(구성요소)를 그렸다. MS Surface 펜 충전을 안해서 펜감도가 좋지 못한 점 양해 바람. 왼쪽 아래의 박스는 header임프런트 단에서 웹페이지를 만든 것은 중3 때 학교에서 홈페이지 제작 과정을 어느 고등학교에서 방학을 이용해서 한 2박 3일 특강에 보내줘서 맛본 적이 있었다. 당시에는 워드 프레소나 드림 에디터(?)와 같은 홈페이지 제작 소프트웨어가 없었기 때문에 html 1.x 버전의 스크립트 코딩을 직접 하였었다. 그것을 그 고등학교(전자공고)의 어느 오십 대는 되어 보이는 교사로부터 배웠었는데, 스크립팅한 것이 화면에 정확히 안 뿌려지면(Rendering) 실습 보조로 대기하고 있었던 그 고등학교 누나한테 물어보곤 했었다. 그래서 그런지 계속 오타를 내게 되었다. 마지막 날에 스무 개 이상의 웹페이지의 html 확장자 파일과 설정 파일을 하나로 엮어서 나의 첫 개인 홈페이지를 인터넷 상에 배포할 수 있었다.
HTTP나 CSS(당시에 기억하기론 아직 없어서 html 파일에 말 그대로 막일 작업을 할 수밖에 없었다. 지금은 부트 스트랩이라는 CSS도 필요 없는 툴이 있지 않나...) 같은 용어에 대해 전무했지만 자신의 홈페이지를 만들어서 PC통신을 통해 당시의 블로그 카페와 같은 개념인 BSS(Bulletin Board System, 주로 사람들이 모여서 글을 올리고, 읽고, 찾을 수 있는 게시판)에서 정보를 공유하거나 전자 상거래(e-businees의 시초)를 하는 것이 유행했었기 때문에, 학생을 대상으로도 교육해줬던 거 같다. 그리고 고등학생으로 올라갈 때는 점점 떨어져 가던 성적과 관계없이 이 전자공고와 같은 건물을 쓰는 외고로 가게 됐지만, 이 시기에 성적에서 거진 낙오자가 되어서 비실비실거릴 때면 항상 왜 여기 전자공고에 와서 수시전형으로 컴공과를 진학하지 않았을까 하고 후회하곤 했다.
어쨌든 이번 섹션에서는 웹페이지(확장자가 html) 문서의 구조를 트리 다이어그램으로 나타낼 수 있고, 트리로 각 구성요소(element, 현업에서는 태그라고 호칭)를 표현하면, 인터넷 브라우저 상에서 F12 펑션키(function key)를 누르면 아래 화면과 같이 나오는 개발자 도구를 통해 볼 수 있는 DOM(Document Object Model)의 관계(이것이 DOM tree)를 쉽게 파악할 수 있다. 개발자 도구는 코드와 결과 페이지의 구성요소 간의 관계를 보여준다. 개별 구성요소의 속성(attribute)과 스타일(style)을 검사하고 브라우저가 코드를 어떻게 해석하는지 보여준다(아키노, 2017). 개발과 디버깅 단계 모두에서 이 관계를 살펴보는 것이 필수이며, 이것이 웹 구조를 분석하는 과정이다.
개발자 도구(F12)를 통해 보이는 구성요소 패널. 가운데 html 코드가 DOM Tree View이며 한 span(음영)을 선택하면 우측에 해당 Styles Pane의 박스 표시html 규격에서도 자바 언어와 같이 하위의 구성요소가 상위의 구성요소의 속성을 물려받고, 이것을 자바에서와 같이 상속(inheritance)이라고 한다. 그래서 위의 화면의 우측 스타일 영역(Styles Pane)에서와 같이 가장 상위의 구성요소(element)가 html이며, 이 html으로부터 'line-height: 1.15'이라는 선택자(행 높이)를 body가 물려받았다는 것(Inherited from html)을 알 수 있고, 'Inherited from a(nchor)', 'Inherited from li(st)', 'Inherited from ul(->unoerdered list의 약자)'이라는 태그들이 붙은 박스도 볼 수 있다. 가리키는 바와 같이 이 세 영역(a, li, ul)은 브라우저 기본 스타일 시트에서 각 단계별로 상속받은 스타일(이건 기본 스타일시트에서 제공하는 디폴트 값이다)을 보여준다. 'Inherited from body'에서는 styles.css에서 body 구성요소에 설정한 스타일(화면 아래의 font-size: 10px)로부터 상속된 글자 크기 속성을 볼 수 있다(아키노, 2017).
자바에서 클래스 중 가장 선조가 object이듯이, html에서도 가장 위에 있는 조상은 html이다. 그래서 동일한 개념으로 만약 ul과 같은 다른 레벨에서 글자 크기를 다르게 설정한다면 어떨까? 가까운 조상에 의한 스타일이 우선이므로 style.css의 ul에 설정된 글자 크기가 body의 설정보다 우선이고, span 구성요소 자체의 글자 크기 설정이 다른 설정보다 우선이다(아키노, 2017).
이를 보려면 개발자 도구에서 바로 수정하여 확인할 수 있다. DOM 트리 보기(DOM Tree View)의 span 구성요소를 클릭한 후 실행 중에 스타일을 적용해볼 수 있다. 여기서 추가하는 스타일은 웹페이지에서는 바로 적용되지만, 실제 프로젝트 파일에는 추가되지 않는다(아키노, 2017).
span 구성요소의 글자 크기를 30px로 설정하여 body 구성요소로부터 물려받은 스타일을 덮어쓰기(overwrite)할 수 있다위의 구성요소 패널(element panel)의 우측 스타일 팬(Styles Pane) 상단에 element.style이라는 라벨이 붙은 영역이 있는데, 이 중괄호 사이를 클릭하면 개발자 도구에서 바로 폰트 사이즈를 입력할 수 있다. 폰트 사이즈로 30px처럼 큰 값을 입력하고 엔터를 치면 화면의 오른편 아래처럼 웹페이지의 해당 span의 글자 크기가 body의 값을 덮어쓰기 하여 해당 웹페이지의 썸네일 제목(‘도산서원 사액’) 크기가 바뀐 것을 볼 수 있다.
모든 스타일 속성이 상속되는 것은 아니다. 예를 들어 border(경계선)는 상속되지 않는다. 어떤 속성이 상속되는지 알아보려면 속성의 MDN(Mozila Developer Network) 참조 페이지를 참고하면 된다(아키노, 2017)
style.css로 스크립트 코드를 아래와 같이 body의 글자 크기를 무시하고 더 큰 글자를 사용하도록 .thumbnail-title 클래스의 선언 블록을 업데이트할 수도 있다.
브라우저에서 바뀐 것을 확인하면 기본 스타일시트에 의해 .thumbnail-title의 구성요소(span)가 적용되어 썸네일 제목에 밑줄이 추가되어 있을 테다. 이는 .thumbnail-title을 앵커 태그(<a herf="#"> 깜싸진 구성요소 </a>)로 감쌌기 때문에 밑줄 스타일(cursor pointer)을 상속받았기 때문이다. 링크가 연결된 텍스트의 밑줄은 사용자가 썸네일(글자)을 클릭할 수 있다고 여길 수 있는 시각 지표이다. 그래서 표제나 제목, 캡션이 아닌 일반 텍스트의 링크에서는 밑줄을 없애서는 안된다. 여기서는 필요치 않으므로 아래와 같이 style.css의 새 스타일 규칙에 앵커 태그를 위한 텍스트 장식 속성을 변경(none)하여 제거한다.
/* */ 지시자 사이의 텍스트는 주석이다. 브라우저는 코드 주석을 무시하고, 개발자는 나중에 참고할 수 있으므로 코드에 메모를 남길 수 있다!앵커 구성요소를 위와 같이 밑줄을 확실하게 없애고 싶다면 text-decoration이라는 선택자를 이용하여 none(없음)으로 설정하면, 브라우저에서 밑줄은 사라지고 아래의 브라우저 화면과 같이 섬네일(미리 보기 화면) 제목('도산서원 사액'은 앞서 개발자 도구에서 해당 span의 글자크기를 직접 입력해서 변하지 않았다. 하지만 'F5' 키를 누르면 동일하게 바뀔 것이다.)에 해당 스타일이 적용된다.
텍스트 장식을 none까지 설정한 후 출력된 크롬 브라우저 화면
"thumbnail-title"이라는 값의 class(계층) 선택자(하위의 display, margin, padding 등)를 통해 모든 이름의 스타일을 한꺼번에 적용할 수 있다
스크립트 코드 1. index.html 파일의 각 구성요소에 tumbnail-title이라는 클래스명을 추가하여 일반적인 스타일을 적용함여기까지 CSS(Cascade Style Sheet, 폭포수처럼 한꺼번에 적용하는 스타일 시트?) 설정후 html 웹페이지의 DOM(Document Object Model, 문서의 객체 모델) 트리 뷰를 살펴보면서 해당 설정의 상속관계를 알아봤다. 이것이 향후 섹션에서 다룰 웹 취약점을 파악하는데 과연 도움이 될련는 지는 모르겠으나 표면적으로 보이는 웹페이지의 전체적인 레이아웃 정도는 알고 있어야 개발자가 어떤 식으로 코딩하는지 알 수 있기 때문에 중요하다. 해당 사이트의 취약점 분석 시에 개발자의 성향까지 파악하는 것이 분석 목적의 일부이기 때문이다. 하지만 이처럼 네이티브 개발을 하지 않고, 브라우저를 대상으로 코드를 작성하는 것은 드물다. 하물면, 공공기관의 홈페이지 대부분의 사이트들도 자동화 관리가 편한 워드 프레스를 사용하고 있더라.
웹 애플리케이션에서 데이터를 입력한 폼의 유효성을 확인하거나, 네트워크를 통해 메시지를 보내는 등의 복잡한 웹페이지 동작을 관리하는 로직도 있다. 이 스펙트럼(기술의 범위)을 따르는 핵심 기술에 어느 정도 능숙하다면 거꾸로 웹 취약점도 쉽게 판단할 수 있는 건 분명하다. 그래서 정말 뛰어난 보안 전문가는 고급 수준의 개발자만큼 개발 역량이 능숙한 경우가 많고, 한국 개발자 생태계에서 매우 드문 아키텍트가 되려면 당연히 개발에도 제법 능통해야 한다.
참조
크리스 아키노. (2017). FRONT-END WEB DEVELOPMENT: The big NERD ranch guide. 한국 번역판 역자 이지은(2017). 제대로 배우는 프런트엔드 웹 개발. 서울 : BJ(비제이 퍼블릭).
