Chapter 02. 웹에 대한 이해

웹의 역사 HTTP 웹 애플리케이션 기술

웹의 탄생 배경에 대한 기본 지식을 학습한다. 웹 서비스를 제공하기 위해 사용되는 주요 프로토콜에 대해 학습한다. 웹 애플리케이션 기술에 대해 학습한다.

01. 웹의 역사 웹의 탄생 월드와이드웹(World Wide Web, WWW, W3)은 인터넷에 연결된 컴퓨터들이 하이퍼텍스트 형식으로 표현된 인터넷상의 다양한 정보를 효과적으로 이용할 수 있도록 구성한 전세계적인 시스템 간단히 웹(Web)이라고 부르는 경우가 많음. 1989년 3월 13일, 유럽입자물리연구소(CERN)에 근무하던 소프트웨어 공학자 팀 버너스 리가 과학자들 사이 에 쉽게 정보를 주고받기 위한 목적으로 정보 관리 제안서를 발표 → 최초의 인터넷 기반 하이퍼텍스트 프로젝트 제안 1990년에 하이퍼텍스트 브라우저와 편집기 개발, URL, HTTP, HTML이 차례대로 설계됨. 팀 버너스 리는 1991년 8월, 월드와이드웹에 대한 개념을 포함한 사이트를 일반인에게 최초 공개 [그림 2-1] 팀 버너스 리(Tim Berners Lee)

01. 웹의 역사 초창기 웹 초창기의 웹은 [그림 2-2]와 같이 단순한 텍스트 와 링크 위주로 구성 초기의 웹 브라우저는 지금과 같은 고급 기술이 나 화려한 그래픽 없이 단순히 하이퍼링크를 통 해 여러 페이지들을 묶어 놓은 정도였음 → 글자에 링크를 걸어놓고, 이를 클릭했을 때 다른 화면이 나타나도록 하는 것을 하이퍼텍스 hypertext)라고 함 → 사용자는 하이퍼링크(hyperlink)를 통해 한 페이 지에서 다른 페이지로 쉽게 이동 [그림 2-2] 팀 버너스 리가 만든 초창기 브라우저 화면 [그림 2-3] 마이크로소프트 웹 사이트 비교(초기와 현재)

01. 웹의 역사 실습 2-1: 초창기의 웹 사이트 살펴보기 1. http://archive.org 접속 초창기의 웹 사이트 형태를 살펴봄으로써 웹 사이트가 지금까지 얼마나 많이 변하고 발전하였는지 알 수 있음 과거 웹 사이트의 기록을 저장해 놓은 인터넷 아카이브(http://archive.org)에 접속 [그림 2-4] 홈페이지 아카이브를 저장해 놓은 웹 사이트

01. 웹의 역사 실습 2-1: 초창기의 웹 사이트 살펴보기 2. 네이버 아카이브 기록 검색 중앙의 ‘Web’이라고 표시된 박스 안에 ‘http://’에 이어서 www.naver.com을 입력 www.naver.com 웹 사이트가 1998년부터 아카이빙 되어 있는 것을 볼 수 있음 [그림 2-5] www.naver.com 웹 사이트에 대한 아카이브 기록들

01. 웹의 역사 실습 2-1: 초창기의 웹 사이트 살펴보기 3. 1998년 12월 네이버 웹 사이트 열람 상단의 그래프에서 1998년을 선택하고 하단의 달력을 보면, 12월 12일이 활성화되어 있는 것을 볼 수 있음 그 부분을 클릭하면 1998년 12월의 네이버 웹 사이트 열람 가능 [그림 2-6] 1998년 12월 네이버 메인 페이지 모습

02. HTTP HTTP 인터넷에서는 FTP, Telnet, HTTP, SMTP, POP 등 여러 종류의 프로토콜이 사용됨 웹에서 가장 많이 사용하는 프로토콜인 HTTP(Hypertext Transfer Protocol)는 문서들 간의 상호 연결을 통해 다양한 텍스트, 그래픽, 애니메이션을 화면에 보여주고, 사운드를 재생할 수 있게 해줌 HTTP의 기본 개념 서울에서 부산까지 차로 이동할 때 반드시 서울 톨게이트를 거쳐 고속도로로 나가듯이 웹을 통해 전 세계의 수많은 정보를 탐색하려면 HTTP를 이용해야 함 HTTP에 관한 RFC 문서 HTTP 1.0: RFC ftp://ftp.ietf.org/rfc/rfc1945.txt HTTP 1.1: RFC ftp://ftp.ietf.org/rfc/rfc2616.txt

02. HTTP HTTP 버전 HTTP는 버전 0.9부터 사용되었으며, 0.9 버전의 HTTP는 서버에서 단순히 읽기 기능만 지원 [그림 2-8]에서 설명한 기본 연결 기능은 HTTP의 버전에 관계없이 동일하지만, 기능이 많이 부족했던 HTTP 0.9 는 그리 오래 사용되지 못했음. 현재 웹에서 사용하는 HTTP는 1.0과 1.1 버전 HTTP 1.0 : 인터넷이 활성화된 시점인 1996년 5월 완성(메소드는 GET, HEAD, POST 방식 지원) HTTP 1.1 : 2001년 공식 발표(메소드는 OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT 방식 지원) [그림 2-8] HTTP 0.9를 이용하여 서버에 연결하기 먼저 클라이언트가 웹 브라우저를 이용하여 서버에 연결 요청 연결 요청을 받은 서버는 요청한 클라이언트에 대해 서비스 준비 클라이언트는 읽고자 하는 문서를 서버에 요청 서버는 웹 문서 중 클라이언트가 요청한 문서를 전달해 주고 연결 종료 1 2 3

02. HTTP Request 패킷 Request 패킷에는 GET, POST, HEAD 등의 메소드가 있음 첫 번째 줄: GET / HTTP/1.1 HTTP 전송 방법 : 웹 서버로부터 자료를 가져오는 기능을 하는 GET을 많이 사용 GET 메소드는 별도의 메시지 바디를 필요로 하지 않음 요청된 URL : 웹 서버에 있는 자료를 요청할 때 사용되는 경로 HTTP 버전 : 인터넷에서 가장 일반적으로 사용되는 HTTP 버전은 1.0과 1.1임 대부분의 브라우저는 초기값으로 1.1을 사용 → 1.1은 1.0과 달리 요청이 강제적

02. HTTP Request 패킷 다음 요소들은 웹 해킹과 관련하여 눈여겨보아야 함 Cookie : HSID=AaxlkKoV2snlEi6UQ; SSID=AAYVu_evC0Tiu3aVc; APISID= JEWp0eojRTLFtYKJ/ACgEWh_0mL8Li_-fl; SAPISID=kabRBO-uT0ebDcfc/A2byDX--FwN649tHw Host : www.google.com URL 주소에 나타난 호스트 명을 자세하게 나타내기 위해 사용됨. User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) 브라우저나 기타 클라이언트의 소프트웨어 정보를 보여줌.

02. HTTP Request 패킷 – GET 방식 Request 패킷 – POST 방식 다음과 같이 요청 데이터에 대한 인수를 URL(Uniform Resource Locator) 을 통해 웹 브라우저에 전송 http://www.hanb.co.kr/edu/view_detail.html?hi_id=363 GET 방식을 사용하면 링크 주소만 알아도 연결된 페이지의 내용을 확인할 수 있음. Request 패킷 – POST 방식 URL에 요청 데이터를 전달하지 않고, HTTP의 헤더 영역이 아닌 바디 영역에 소켓을 이용하여 데이터 전송 위 예의 ‘?hi_id=363’과 같은 부분이 URL에 나타나지 않고 POST Body에 포함됨 인수 값을URL을 통하여 전송하지 않기 때문에 다른 사람이 링크를 통해 해당 페이지를 볼 수 없음. POST 방식은 보내려는 인자값이 URL을 통해 노출되지 않기 때문에 보안 측면에서 GET 방식보다 안전한 편임

02. HTTP Request 패킷 – POST 방식 일반적인 게시판의 경우 목록이나 글을 보는 화면은 접근 자유도를 부여하기 위해 GET 방식을 사용하고, 글을 저장하거나 수정하거나 삭제하는 작업을 할 때에는 보안을 위해 POST 방식을 사용함 다음은 POST 방식의 예

02. HTTP Request 패킷 – 기타 HEAD : 서버 쪽 데이터를 검색하고 요청하는 데 사용 OPTIONS : 자원에 대한 요구/응답 관계에서 관련된 선택 사항에 대한 정보를 요청할 때 사용 이를 통해 클라이언트는 어느 것을 선택할지 결정할 수 있으며, 자원과 관련된 필요 사항을 결정할 수 있음 아울러 서버의 수행 능력에 대해서도 알아볼 수 있음 PUT : 메시지에 포함되어 있는 데이터를 지정한 URI 장소에 지정된 이름으로 저장 DELETE : URI에 지정되어 있는 자원을 서버에서 지울 수 있게 함 TRACE : 요구 메시지의 최종 수신처까지 루프백 검사용으로 사용 즉 클라이언트가 보내는 요구 메시지가 거쳐가는 프록시나 게이트웨이의 중간 경로와 최종 수신 서버에 이르는 경로를 알아내는 데 사용

02. HTTP Response 패킷 클라이언트가 보낸 Request의 응답 패킷으로, 형식이 간단함 Response 패킷에 담겨 있는 주요 내용는 서버에서 쓰이는 프로토콜 버전, HTTP 상태 코드(200 OK) 등이며, 전 달해 줄 데이터의 형식, 데이터 길이 등과 같은 추가 정보가 포함되어 있음 위의 헤더 정보 뒤에 빈 줄이 하나 들어가고, 그 다음에 실제 데이터가 전달됨 실제 데이터는 HTML이나 그림 파일이며, 데이터 전달이 종료되면 서버는 연결을 끊음

02. HTTP HTTP 상태 코드 일반적인 웹 서버 상태 코드 웹 서버 상태 코드 함축적 의미 내용 100번 대 정보 전송 임시 응답을 나타내는 것은 Status-Line과 선택적인 헤더들로 이루어져 있고 빈 줄로 끝을 맺는다. HTTP/1.0까지는 계열에 대한 어떤 정의도 이루어지지 않았기 때문에 시험용 외에는 서버 쪽의 추가 응답은 없다. 200번 대 성공 클라이언트의 요청이 성공적으로 수신되어 처리되었음을 뜻한다. 300번 대 리다이렉션 클라이언트의 요구 사항을 처리하기 위해서는 다른 곳에 있는 자원이 필요하다는 것을 의미한다. 400번 대 클라이언트 측 에러 클라이언트가 서버에 보내는 요구 메시지를 완전히 처리하지 못한 경우 등 클라이언트 측에서 오류가 발생한 것을 의미한다. 500번 대 서버 측 에러 서버 자체에서 생긴 오류 상황이나 클라이언트 요구 사항을 제대로 처리 할 수 없을 때 발생한다.

02. HTTP HTTP 상태 코드 HTTP 상태 코드 중 눈여겨봐야 할 상태 코드 웹 서버 상태 코드 내용 200 OK 클라이언트의 요청이 성공했다는 것을 나타냄 201 Created 클라이언트의 PUT 요청이 성공적이라는 것을 나타냄 301 Moved Permanently 브라우저의 요청을 다른 URL로 항시 전달한다는 것을 의미함. 다른 URL에 대한 정보는 Location 헤더에 나타남 302 Moved Temporarily 브라우저의 요청을 임시 URL로 바꾸고 Location 헤더에 임시로 변경한 URL에 대한 정보를 적음. 클라이언트가 다음에 같은 요청을 하면 기존의 URL로 돌아감 304 Not Modified 브라우저가 서버에게 요청한 자료에 대해 서버는 클라이언트 내에 복사된 캐시를 사용하면 된다는 것을 의미함. 서버는 If-Modified-Since와 If-None-Match 요청 헤더를 사용해 클라이언트가 가장 최근의 자료를 가지고 있는지 여부를 확인함 400 Bad Request 클라이언트가 서버에 잘못된 요청을 했다는 것을 나타냄 401 Unauthorized 서버가 클라이언트의 요청에 대해 HTTP 인증 확인을 요구하는 것을 의미함 403 Forbidden 클라이언트의 요청에 대해 접근을 차단하는 것을 나타냄 404 Not Found 클라이언트가 서버에 요청한 자료가 존재하지 않음을 나타냄 500 Internal Server Error 서버가 클라이언트의 요청을 실행할 수 없을 때 500 상태 코드가 발생함. 일반적으로 SQL 인젝션 취약점이 존재하는지 확인할 때 500 에러가 유용하게 사용됨

02. HTTP HTTP 1.0과 1.1 동작 원리 HTTP 1.0에서는 [그림 2-11]처럼 문서에 몇 개의 그림이 있든 상관없이 텍스트가 저장된 HTML 문서를 먼저 전 송받은 후 연결을 끊고 나서 다시 연결하여 그림을 전송 받음 HTTP 1.1은 연결 요청이 계속 들어오면 HTML 문서를 받고 난 후 연결을 끊고 나서 다시 연결 요청을 하는 게 아니라 바로 그림 파일을 요청 [그림 2-11] HTTP 1.0을 이용하여 index.html 읽기 [그림 2-12] HTTP 1.1을 이용하여 index.html 읽기

02. HTTP HTTPS (HTTP over Secure Socket Layer) HTTP 프로토콜은 데이터가 네트워크 장비를 통과할 때 암호화되지 않은 단순한 TCP를 사용하기 때문에 네트워 크에 잠입해 있는 공격자가 중간에 정보를 가로챌 수 있음 HTTPS는 애플리케이션 계층 프로토콜로 SSL(Secure Socket Layer)을 이용하여 클라이언트와 서버 사이에 주고 받는 정보를 보호하는 데 사용

02. HTTP 실습 2-2: 웹 프록시(Burp Suite)를 이용한 HTTP 패킷 분석 웹 프록시는 브라우저와 서버 간 통신을 할 때 중간에 위치해서 브라우저(클라이언트)가 요청하고 받는 데이터 를 서버로 재전송해 주는 역할을 함. [그림 2-13] 실습 환경

02. HTTP 실습 2-2: 웹 프록시(Burp Suite)를 이용한 HTTP 패킷 분석 1) JRE 다운로드 및 설치 Burp Suite는 기본적으로 Java를 기반으로 만들어져 있기 때문에 실행을 하려면 Java 실행 환경이 구축되어 있어야 함 2) Burp Suite 다운로드 Burp Suite 사이트(http://portswigger.net)에서 Burp Suite를 다운로드 받음 Burp Suite를 다운로드 받은 폴더에 노트패드로 Suite.bat 파일을 만들고, 다음과 같이 입력한 후 저장 java -jar –Xmx1024m burpsuite_free_v1.5.jar 3) Burp Suite 설정 웹 브라우저와 웹 서버간의 HTTP 패킷을 보기 위해 Burp Suite의 Proxy 탭에 들어가서 ‘intercept is off’ 버튼 을 눌러 ‘intercept is on’으로 바꿈 서버와 클라이언트 간에 전달되는 모든 패킷을 보기 위해 Proxy의 Options 탭에 들어가서 ‘intercept client requests’와 ‘intercept server responses’ 밑에 ‘intercept requests ~ / intercept responses ~’가 모두 체크되 어 있는지 확인

02. HTTP 실습 2-2: 웹 프록시(Burp Suite)를 이용한 HTTP 패킷 분석 [그림 2-15] Proxy 기능 중 Intercept를 활성화한 화면 [그림 2-16] Proxy 설정에서 Server와 Client 양 측면의 패킷을 보기 위한 설정

02. HTTP 실습 2-2: 웹 프록시(Burp Suite)를 이용한 HTTP 패킷 분석 4) 프록시 설정 프록시를 통해 패킷을 전달할 수 있도록 웹 브라우저에서 프록시 설정 웹 브라우저 ‘도구’ 메뉴에서 ‘인터넷 옵션’ 메뉴 선택 인터넷 옵션 창에서 ‘연결’ 탭 선택 후 ‘LAN 설정’ 버튼 클릭 ‘LAN 설정’에서 프록시 서버에 체크 주소 부분에 127.0.0.1, 포트 부분에 8080 입력 후 확인 버튼 클릭 5) 패킷 확인 웹 브라우저를 이용하여 임의의 웹 사이트에 접속 [그림 2-19]는 한빛미디어 웹사이트 (www.hanb.co.kr)에 접속할 때 인터셉트한 패킷 화면 패킷 확인 후 전송하려면 Burp Suite의 Intercept 창에서 Forward 버튼 클릭 [그림 2-19] Burp Suite 프록시를 이용하여 클라이언트의 Request 패킷을 보는 화면

03. 웹 애플리케이션 기술 배경 웹 애플리케이션에는 클라이언트와 서버 사이에 메시지를 전달하기 위해 사용되는 핵심통신 프로토콜뿐만 아니라 웹 애플리케이션의 각 기능을 활용하기 위한 다양한 기술들이 사용되고 있음. 웹 애플리케이션을 공격하거나 보호하려면 웹 애플리케이션에 사용되는 기술에 어떤 것이 있으며, 어떻게 동작하는지, 그리고 취약점은 무엇인지 알아야 함. 서버 측 기능 초기의 웹 서버는 성능과 기술의 문제로 단순한 정적 페이지만 제공하였으나, 지금은 사용자가 입력한 값에 따라 다양한 결과를 화면에 보여주는 동적 기능도 제공하고 있음. 사용자가 동적 자료를 요청하면 서버는 해당 사용자의 요청을 서버 측 기능을 이용하여 처리함. 동적인 콘텐츠는 서버에서 실행되는 스크립트나 다른 코드들을 통해 실행됨. 웹 애플리케이션은 사용자에게 다양한 기능을 제공하기 위해 다음과 같은 서버 측 기능을 이용함. ASP, JSP, PHP, VBScript, Perl과 같은 서버 측 스크립트 언어 Apache, IIS, Netscpae Enterprise와 같은 웹 서버 Microsoft SQL Server, 오라클, 사이베이스, MySQL과 같은 데이터베이스

03. 웹 애플리케이션 기술 서버 측 스크립트 언어 웹 서버 클라이언트가 요청한 데이터를 서버 측에서 처리하여 원하는 결과를 돌려주기 위해 사용되는 언어 웹 서버와 플랫폼에 따라 사용되는 언어가 서로 다름 IIS와 같은 윈도우 계열 기반에서는 주로 ASP가 많이 사용되며, Java와 같은 웹 애플리케이션 플랫폼에서는 주로 JSP가 많이 사용됨 웹 애플리케이션 소스 코드를 분석해서 취약점을 찾으려면 서버 측 스크립트 언어에 대한 이해가 필수! 웹 서버 Netcraft(www.netcraft.com)에 따르면, 2013년 1월 기준 개발사별 웹 서버의 점유율은 다음과 같음. 개발사 웹 서버 수(2013년 1월 기준) 점유율(%) 아파치 348,119,032 55.26 % 마이크로소프트 105,619,177 16.93% nginx 79,640,472 12.64% Google 22,574,858 3.58% 기타 12%

03. 웹 애플리케이션 기술 데이터베이스 데이터의 모음을 말함 데이터베이스를 관리하는 소프트웨어를 DBMS(DataBase Management System)라고 하는데, DBMS에는 오라클, DB2, Microsoft SQL Server, 사이베이스, MySQL 등이 있음 DBMS를 사용하여 데이터베이스를 만들고 데이터를 입력, 변경, 검색할 수 있음 SQL 인젝션은 웹 애플리케이션과 연동되어 있는 데이터베이스에 직접 접근을 할 수 있는 것이 특징 따라서 SQL 인젝션 공격을 심도 있게 이해하려면 데이터베이스에 대한 기본적인 지식이 필요함 [그림 2-19] DBMS의 역할

03. 웹 애플리케이션 기술 클라이언트 측 기능 서버 측 애플리케이션이 사용자가 입력한 내용을 전달받고 그 결과를 사용자에게 전달하려면 클라이언트 측 사용자 인터페이스를 제공할 필요가 있음 클라이언트 측 기능은 공격자가 쉽게 변조할 수 있는 대상이 되기 때문에 좀 더 주의 깊게 살펴보아야 함 일반적으로 사용되는 클라이언트 측 기능 HTML 자바스크립트 1980년 유럽입자물리연구소(CERN)의 팀 버너스 리가 HTML의 원형인 인콰이어 제안 최초의 일반 공개 설명은 1991년 말 팀 버너스 리가 인터넷에서 문서를 ‘HTML 태그(HTML tag)’ 라고 부르면서 시작 2013년 현재 대중적으로 사용하고 있는 것은 HTML 4.01 버전 2008년부터 HTML5 연구가 이루어지고 있음 객체 기반의 스크립트 프로그래밍 언어 성능 문제로 인하여 서버 측에서 처리하지 않는 부분을 클라이언트 측에서 처리할 수 있도록 하 기 위해 주로 사용됨 자바스크립트로 작성된 사용자 입력 값 검증부분 등은 공격자의 주요 공격 대상이 되기 때문에 자 바스크립트에 대해 충분히 이해를 하면 웹 페이 지 소스 코드를 분석하는 데 많은 도움이 됨

감사합니다.