Chapter 04 웹 보안
Section 01 웹에 대한 이해
- 웹은 처음에는 단순히 대학 내 각 연구실 사이의 데이터 전송을 위해, 하나의 시스템과 다른 하나의 시스템 간의 통신을 위한 프로토콜을 만들어 사용했다.
- 그러다 점차 프로토콜이 하나둘씩 늘어 결국 시스템을 만드는 회사마다 서로 다른 통신 프로토콜을 사용하게 된 것이다.
- 개별 시스템 산의 통신에는 큰 문제가 없었으나 다른 회사의 제품들과 서로 통실할 수 없다는 문제점이 발생
- 이를 해결하기 위해 하나의 프로토콜을 해석한 후 다른 프로토콜로 바꾸어 다른 시스템으로 전송해주는 장치인 게이트웨이(Gateway)를 개발했다.
- 게이트웨이가 나온 후에야 원격의 두 지점 간의 통신이 가능해졌고, 비로소 네트워크라고 부를 만한 것이 생겼다.
- 1969년 미 국방부 산하 고등연구 계획국 ARPA(Advanced Research Projects Agency)에 의해 전 세계 주요 거점을 연결하는 네트워크가 처음 만들어졌다.
- 이 네트워크를 알파넷이라 부르며, 흔히 알파넷을 인터넷의 시작이라고 한다.
- 1970년대의 네트워크는 TCP/IP 프토로콜로 연결되고 일반에 공개됨에 따라 크게 발전하기 시작
- 우리나라의 경우 1994년 한국통신이 카이스트와 연구기관 등에 학술 교융/정보 교류용으로 제공한 '하나망'을 일반에 공개하고 코넷(KORNET)을 시작함으로써 인터넷에 첫 발은 내딛게 되었다.
- '웹'의 정식 명칭은 월드 와이드 웹(WWW : World Wide Web)이다.
- 세계 규모의 거미집 또는 거미집 모양의 망이라는 뜻으로, 1989년 스위스 제네바에 있는 유럽 원자핵 공동 연구도(CERN)에서 근무하던 팀 버너스 리(Tim Berners Lee)에 의해 연구 목적의 프로젝트로 시작
- 프로젝트의 목적은 전 세계에 흩어져 있는 종업원 및 연구자와 연구 결과나 아이디어를 공유할 수 있는 방법을 모색하는 것이었다.
- 처음 프로젝트를 계획할 당시에는 웹을 'Hyper Text Project'라고 불렀는데, 이는 1960년대에 테드 넬슨이 만든 신조어로 다른 문서와 연관 관계를 가지는 텍스트를 의미하는 것이다.
- 현재 웹 문서로 가장 흔히 쓰이는 HTML(Hyper Text Markup Language)은 이 Hyper Text를 효과적으로 전달하기 위한 스크립트 언어이다.
- 웹에 접근하기 위해서는 웹 브라우저가 필요하다. 최근에는 대부분 마이크로소프트의 인터넷 익스플로어를 사용하지만, NCSA에서 개발한 모자이크(Mosaic)나 넷스케이프에서 개발한 넷스케이프 네비게이터(Netscape Navigator) 등도 있다.
Section 02 HTTP에 대한 이해
- 웹에서는 FTP, Telnet, HTTP, SMTP, POP 등 여러 프로토콜이 쓰인다. 그중 가장 흔히 사용되는 프로토콜이 HTTP이다.
- HTTP를 이용하면 사용자는 다양한 응용 프로그램에 접근하여 텍스트/그래픽/애니메이션을 보거나 사운드를 재생할 수 있다.
- HTTP는 웹 처리 전반에 걸쳐 토대가 되기 때문에 웹 서버를 HTTP서버라고 부르기도 한다.
- 웹 서버에는 웹 서비스를 구현하기 위한 웹 언어가 존재하며, 그 종류는 HTML, ASP, JSP, Java Script 등이 있다.
1. HTTP 프로토콜
- HTTP는 0.9 버전부터 사용되었다.
- 0.9 버전은 서버로부터의 단순 읽기 기능만 지원한다.
- HTTP 0.9는 하나의 웹 페이지 안에서도 텍스트와 그림마다 Connect 과정을 반복해서 거쳐야 했기 때문에 무척 비효율적이었고 오래 사용되지 못했다.
- 하지만 1.0 버전부터는 한 번의 Connect 후에 Request와 Response를 반복할 수 있게 되었다.
2. HTTP Request
- HTTP Reauest는 웹 서버에 데이터를 요청하거나 전송할 때 보내는 패킷으로, 주로 GET, POST와 같은 메소드를 사용한다.
가. GET 방식
- 가장 일반적인 HTTP Reauest 형태로 웹 브라우저에 다음과 같은 요청 데이터에 대한 인수를 URL(Uniform Resource Locator)을 통해 전송한다.
www.wishfree.or.kr/list.php?page=1&search=test
- GET 방식에서는 각 이름과 값을 &로 결합하며 글자 수를 255자로 제한한다.
- 데이터가 주소 입력란에 표시되기 때문에, 최소한의 보안도 유지되지 않는, 보안에 매우 취약한 방식이다.
- 간혹 아이디나 패스워드가 인수로 저장되러 전달되는 경우도 발생한다.
나. POST 방식
- URL에 요청 데이터를 기록하지 않고 HTTP 헤더에 데이터를 전송하기 때문에 GET 방식에서의 '?page=1&search=test' 와 같은 부분이 존재하지 않는다.
- 내부의 구분자가 각 파라미터(이름과 값)를 구분하며, 서버가 각 구분자에 대한 내용을 해석하여 데이터를 처리하기 때문에 GET 방식에 비해 상대적으로 처리 속도가 늦다.
- 인수 값을 URL을 통해 전송하지 않기 때문에 다른 이가 링크를 통해 해당 페이지를 볼 수 없다.
- 게시판 등에서 파일 업로드는 POST 방식으로만 할 수 있는데, GET 방식과는 달리 보내려는 데이터가 URL을 통해서 노출되지 않기 때문에 최소한의 보안성은 갖추고 있다.
다. 기타 방식
① HEAD 방식 : 서버 측의 데이터를 검색하고 요청하는데 사용한다.
② OPTIONS 방식 : 자원에 따라 요구/응답 관계에서 관련된 선택 사항의 정보를 요청할 때 사용된다. 이를 통해 클라이언트는 어느 것을 선택할지 결정할 수 있고, 자원과 관련 필요 사항도 결정할 수 있다. 서버의 수행 능력도 알아볼 수 있다.
③ PUT 방식 : 메시지에 포함되어 있는 데이터를 지정한 URI(Uniform Resource Identifier) 장소에 그 이름으로 저정한다.
④ DELETE 방식 : URI에 지정되어 있는 자원을 서버에서 지울 수 있게 한다.
⑤ TRACE 방식 : 요구 메시지의 최종 수신처까지의 루프백 검사용으로 쓰인다. 클라이언트가 보내는 요구 메시지가 거쳐가는 프록시나 게이트웨이의 중간 경로 및 최종 수신 서버까지 이르는 경로를 알아내는데 사용된다.
3. HTTP Response
- 클라이언트의 HTTP Request에 대한 응답 패킷이다.
- 서버에서 쓰이고 있는 프로토콜 버전, Request에 대한 실행 결과 코드 및 간략한 실행 결과 설명문(OK 등)의 내용이 담겨있다.
- 전달할 데이터의 형식과 데이터 길이 등과 같은 추가 정보가 MIME 형식으로 표현되어 있는데, 헤더 정보 귀에는 실제 데이터(HTML이나 그림)가 전달되며 데이터 전달이 끝나면 서버는 연결을 끊는다.
- HTTP Response의 주요 실행 결과 코드
실행 결과 코드 |
내용 |
설명 |
100번대 |
정보 전송 |
HTTP/1.0까지는 계열에 대한 어떤 정의도 이루어지지 않았기 때문에 실험적인 용도 이외에는 100대 서버 응답은 없다. |
200번대 |
성공 |
클라이언트의 요구가 성공적으로 수신되어 처리되었음을 의미 |
300번대 |
리다이렉션 |
해당 요구 사항을 처리하기 위해 사용자 에이전트에 의해 수행되어야 할 추가적인 동작이 있음을 의미 |
400번대 |
클라이언트 측 에러 |
클라이언트에 오류가 발생한 경우 사용된다. |
500번대 |
서버 측 에러 |
서버 자체에서 발생된 오류 상황이나 요구 사함을 제대로 처리할 수 없을때 사용된다. |
Section 03 웹 서비스에 대한 이해
- 웹 서비스는 웹 언어를 통해 제공된다.
- 정적인 서비스 제공 언어 : HTML, 자바 스크립트, 비주얼 베이직 스크립트 등
- 동적인 서비스 제공 언어 : ASP, JSP, PHP 등
1. HTML
- HTML(Hyper Text Markup Language)은 가장 단순한 형태의 웹 언어이다.
- 웹 서버에 HTML 문서를 저장하고 있다가 클라이언트가 특정 HTML페이지를 요청하면 해당 HTML 문서를 클라이언트로 전송한다.
- 그러면 클라이언트는 이 웹 페이지를 해석하여 웹 브라우저에 표현해 주는데 이런 웹 페이지를 정적인(Static) 웹 페이지라고 한다.
- 정적인 웹 페이지는 고객의 취향이나 변화에 적응할 수 없고 새로운 것을 추가하는데 많은 시간이 걸린다는 단점이 있지만 보안에는 장점이 많다.
- 웹 해킹은 웹 브라우저와 웹 서버 사이에 전달되는 값들의 변조를 통해 웹 서버의 설정이나 로직을 바꾸는데, 정적인 웹 페이지는 '바쑬수 있는 가능성'이 매우 낮다.
2. SSS
- 사용자들은 점차적으로 웹 페이지가 각기 다른 요구에 따라 능동적으로 변하기를 기대했다.
- 동적인(Dynamic) 웹 페이지를 제공할 수 있는 PHP(Personal Home Page), ASP(Active Server Page), JSP)Java Script Pages)와 같은 언어를 개발했다.
- 동적인 페이지를 제공하는 스크립트를 SSS(Server Side Script)라 한다.
- 동적인 웹 페이지에서는 스크립트에 HTML 확장자 대신 ASP 또는 JSP 의 확장자를 가진 웹 문서를 요청한다.
- ASP의 경우 DLL이나 OCX 같은 파일을 이용하고 JSP의 경우 서블릿을 이용해 요청을 처리한다.
- 그리고 결과를 HTML 파일로 만들어 클라이언트에 전송해준다.
- ASP를 이용하기 위해서는 윈도우 기반의 IIS 웹 서버를 설치해야 하지만 JSP는 어떤 운영체제에서도 동작한다.
3. CSS
- 서버가 아닌 클라이언트 측의 웹 브라우저에 의해 해석되고 적용되는 스크립트이다.
- 자바 스크립트, 비주얼 베이직 스크립트 등
- 이를 CSS(Client Side Script)라 한다.
- CSS는 서버가 아닌 브라우저에서 해석되어 화면에 적용되기 때문에 웹 서버의 부담을 줄여주면서도 다양한 기능을 수행할 수 있다.
Section 04 웹 해킹에 대한 이해
- 웹 해킹은 웹 사이트의 구조와 동작 원리를 이해하는 것에서부터 시작한다.
1. 웹 취약점 스캐너를 통한 정보 수집
- 웹에 대한 정보를 수집할 때는 웹의 메뉴를 하나하나 클릭해보며 수작업으로 동작을 파악하기도 하지만 웹 취약점 스캐너를 사용할 수도 있다.
- 스캐너를 통하면 웹 구조를 파악하고 취약점을 수집하기가 쉽지 않다는 단점이 있다. 각 페이지의 링크 정보를 따라가는 것이므로 웹 페이지에서 링크로 제공하지 않는 페이지는 구조 분석이 어렵다.
- 한편 각 페이지에서 링크 정보를 따라가며 웹 사이트의 웹 페이지를 로컬에 저장해주는 Web Zip이 있는데, 웹 스캔은 Web Zip이 웹 페이지를 수집하는 원리와 같다.
- 웹 프로그램은 자유스럽게 만들어지고 변형도 다양해 웹 스캐너가 취약점을 정확히 잡아내기랑 거의 불가능하다.
- 따라서 스캐너를 통해 발견된 취약점은 개별 확인 과정을 통해 유효성을 확인하는 과정이 필요하다.
2. 웹 프록시를 통한 취약점 분석
- 웹 프록시의 기본적인 동작 구조는 클라이언트에 설치되며 클라이언트의 통제를 받는다. 즉 클라이언트가 웹 서버와 웹 브라우저 간에 전달되는 모든 HTTP 패킷을 웹 프록시를 통해서 확인하면서 수정하는 것이 가능하다.
가. 서버에서 클라이언트로 전송되는 패킷 변조
- 웹 프록시의 유용한 점은 서버와 클라이언트 사이의 패킷을 볼 수 있는 것 이외에 서버와 클라이언트 사이에 전달되는 과정에서 패킷을 위변조할 수 있다는 점이다.
- 변조하고자 하는 패킷은 ASP 혹은 JSP가 아닌 HTML이다. 어떤 언어로 개발됐는지 웹 프록시를 통해서 확인하는 것은 HTML이다.
- 서버에서 클라이언트로 전송되는 내용이 바꾸었으니 자신을 해킹한 것이된다. 하지만 이런 공격이 다음 두가지 위력을 가질 수 있다.
- 첫 번째. 클라이언트에 해킹하고자 하는 대상이 있는 경우
웹 브라우저 내용만 바꾸었지만 실제로는 Active X 등의 형태로 여러 프로그램이 클라이언트에 설치되어 웹 서비스를 제공하는 경우가 많은데, 이때 클라이언트에 설치된 서비스 프로그램을 속이는 것이 가능하다.
- 두 번째. 서버에서 클라이언트에 정보를 전송했다가 이를 다시 전송받아 처리하는 경우
예를 들면 경품을 나눠주기 위한 당첨권은 동전으로 긁으면 '당첨'이란 글자가 나타나므로 가게 주인은 '당첨'이란 글씨를 보고 당첨 여부를 판단할 것이다. 그런데 어떤 사람이 '당첨'이란 글씨를 자신이 받은 당첨권에 위조해서 적으면(이 과정은 마치 서버가 클라이언트에게 전달해준 패킷 값을 위변조하는 것과 같다.) 제대로 위조를 했다면 가게 주인(서버)은 경품을 꺼내줄 것이다.
이처럼 서버가 클라이언트로 보낸 데이터의 변조로 인해 발생하는 위험을 없애려면 서버에서 클라이언트로 전송한 값은 어떤 것도 다시 참조하지 않아야 한다.
나. 클라이언트에서 서버로 전송되는 패킷 변조
- 서버에서 클라이언트로 전송되는 패킷을 변조한 것과 클라이언트에서 서버로 전송되는 패킷을 변조하는 것은 같다.
- 클라이언트에서 서버로 전송되는 패킷을 변조하는 것은, 일반적인 웹 서비스의 메뉴상 접속할 수 없는 것에 접근하거나 특정한 값을 넣어 시스템의 오작동을 유도하기 위한 목적으로 사용된다.
3. 구글 해킹을 통한 정보 수집
- 구글에서 제공하는 고급 검색 기능
검색 인자 |
설명 |
검색 추가 인자 |
site |
특정 도메인으로 지정한 사이트에서 검색하려는 문자열이 포함된 사이트를 찾음 |
YES |
filetype |
특정한 파일 유형에 한해서 검색하는 문자가 들어 있는 사이트를 찾음 |
YES |
link |
링크로 검색하는 문자가 들어 있는 사이트를 찾음 |
NO |
cache |
특정 검색어에 해당하는 캐시된 페이지를 보여줌 |
NO |
intitle |
페이지의 제목에 검색하는 문자가 들어있는 사이트를 찾음 |
NO |
inurl |
페이지의 url에 검색하는 문자가 들어있는 사이트를 찾음 |
NO |
- 검색 엔진의 검색을 피하는 방법으로 가장 일반적인 대응법은 웹 서버의 홈 디렉토리에 robot.txt. 파일을 만들어 검색할 수 없게 만드는 방법
Section 05 웹의 주요 취약점 10가지
1. 명령 삽입 취약점
2. XSS 취약점
3. 취약한 인증 및 세션 관리
4. 직접 객체 참조
5. CSRF 취약점
6. 보안 설정 취약점
7. 취약한 정보 저장 방식
8. URL 접근 제한 실패
9. 인증 시 비암호화 채널 사용
10. 부적절한 오류 처리
Section 06 웹 취약점 보완
1. 특수문자 필터링
- 웹 해킹의 가장 기본적인 형태 중 하나가 인수 조작인데 인수 조작은 예외적인 실행을 유발시키기 위해 일반적으로 특수 문자를 포함하게 되어 있다.
- SQL 삽입 공격에서 아이디와 패스워드 넣는 부분에 ' 문자열을 입력받지 못하도록 코드를 수정하여 보완할 수 있다.
- XSS 공격에서 본문에 포함되는 주요 특수문자를 제거하는 함수 등을 사용하여 보완할 수 있다.
2. 서버 측 통제 작용
- 파일 업로드 취약점이나 특수문자 필터링을 수행할 때 주의할 점은 자바 스크립트와 같은 CSS(Client Side Script) 기반의 언어로 필터링을 하면 안된다.
- CSS 기반의 언어는 웹 프록시를 통해 브라우저에 전달되기 때문에 전달되는 과정에서 변조될 가능성이 있다.
- 즉 필터링 로직은 ASP, JSP 등과 같은 SSS(Server Side Sctipt)로 필터링을 수행해야 한다.
3. 지속적인 세션 관리
- URL 접근 제한 실패를 막기 위해서는 기본적으로 모든 웹 페이지에 세션에 대한 인증을 수행해야 한다.
- 모든 웹 페이지에 대해 일관성 있는 인증 로직을 적용하려면 기업 단위에서 또는 웹 사이트 단위에서 세션 인증 로직을 표준화하고, 모든 웹 페이지를 개발할 때 해당 표준을 준수시켜야 한다.
출처 : 정보 보안 개론(한 권으로 배우는 보안 이론의 모든 것) / 양대일 저 / 한빛아카데미 출판
':: 웹 보안' 카테고리의 다른 글
Oracle 테스트 환경 구축 + Union Select 쿼리 정리 (0) | 2017.01.21 |
---|---|
해시뱅(HashBang, #!) 탐구 | Message (0) | 2016.11.27 |
Cooxie Toolbar Proxy Server 기능 활용하기 | Message (0) | 2016.08.05 |
Red_Seek :: 웹 해킹 및 보안 - SQLMap, OWASP (0) | 2016.01.27 |
Red_Seek :: 웹 해킹 및 보안 - SQL Injection, XSS, CSRF (0) | 2016.01.26 |