HTTP/HTTPS 프로토콜에 관하여

HTTP는 웹 애플리케이션과 상호 동작하고 통신하는 것으로 합의된 프로세스, 완전한 평문 기반의 프로토콜이다.

 

기본적으로 평문이기 때문에 HTTP를 사용할 때 보안이나 privacy에 대한 어떤 것도 가정하지 않는다.

 

HTTP 프로토콜은 상태를 관리하지 않는 (stateless) 프로토콜이므로 이전의 요청 상황을 알지 못하고, 따라서 모든 클라이언트의 요청과 웹 애플리케이션의 응답은 완전히 새롭고 독립적인 사건일 뿐인데.. 웹 애플리케이션이 클라이언트가 요청하는 이력을 추적하는 것이 결정적으로 중요할 때가 있다. 예를들어 온라인 쇼핑에서 장바구니에 물품을 추가하고, 운송 방법을 선택하고, 지불 정보를 입력하는 것처럼 여러 단계로 처리하는 경우이다.

 

HTTP가 쿠키를 사용하지 않는다면 이러한 각 단계에서 매번 로그인해야만 한다.

이것은 비효율적이기 때문에 세션 개념을 만들어 애플리케이션이 로그인 이후의 모든 요청을 추적하도록 하였다. 

세션으로 인해 웹 애플리케이션의 사용자 친화도는 좋아졌지만 이것이 공격의 실마리를 제공하였다.

근본적으로 HTTP는 높은 수준의 보안성이나 privacy를 요구하는  웹 트랜잭션을 다룰 수 있게 설계되지 않았기 때문.

 

HTTPS를 사용해도 공격을 막기에는 역부족이다.

HTTPS는 SSL/TLS 프로토콜의 맨 꼭대기에 HTTP를 둔 것으로 보통의 HTTP 요청과 응답에 SSL/TLS의 TLS를 덧붙인 것에 불과하다.

HTTPS는 중간자 공격(middle attack)이나 다른 도청을 이용한 공격을 방어하는데 가장 적합하여, 브라우저와 웹 애플리케이션 간 "개인적인 통화"를 보장하지만, 그저 비밀대화를 위하여 웹 애플리케이션과 통신 채널을 암호화한 정도이다.

그렇기 때문에 HTTPS로 양방향 암호화하더라도 대기중인 웹 애플리케이션에서 처리하게끔 엮어진 공격을 피해갈 수는 없다.

 

* HTTP 사이클

브라우저는 사용자가 입력한 값을 매개변수(또는 변수)에 담아 요청으로 보내면 웹 서버는 제출된 요청이 지시하는 응답을 회신한다. 

웹 애플리케이션은 매개변수 값에 근거하여 동작하기 때문에 해커가 웹 애플리케이션과 웹 서버를 공격할 때 악의적인 값을 입력하여 공격하는 가장 중요한 목표물이 된다.

 

* 주요 HTTP 헤더

각 HTTP 사이클은 클라이언트가 요청할 때나 서버가 응답하는 자세한 내용을 헤더에 실어 보낸다. 주요 헤더는 다음과 같다.

 

1) 웹 서버가 클라이언트 브라우저에게 보내는 헤더 정보 (웹 서버 → 클라이언트 브라우저)

Set-Cookie : 사용자의 세션이 유지되도록 보장하기 위하여 브라우저에 제공하는 세션 식별자(쿠키).

해커가 사용자의 세션을 훔치게 되면 해커는 피해자로 가장할 수 있다.

 

Content-Length : 응답문의 바이트 단위 길이 헤더. 해커가 응용프로그램의 응답을 해독할 때 바이트 단위의 데이터를 예상할 수 있다. 반복적으로 추측하는 무작위 대입법에 활용이 가능하다.

 

Location : 응용프로그램이 사용자를 다른 페이지로 보낼 때 사용. 이 정보는 해커에게 도움이 되는데 예를들어 애플리케이션에 성공적으로 인증한 후에만 접근이 가능한 페이지를 가리키도록 이용할 수 있기 때문이다.

 

2) 클라이언트 브라우저가 웹 서버에 보내는 헤더 정보 (클라이언트 브라우저 → 웹 서버)

Cookie : 하나 또는 여러 개의 쿠키는 사용자의 세션을 유지하기 위해 헤더에 담겨 서버로 되돌려 보내진다.

쿠키의 헤더값은 서버가 set-cookie로 발행한 헤더 값과 언제나 일치해야 한다. 

이 값은 응용프로그램의 유효한 세션 값을 제공하므로 다른 응용프로그램 사용자를 공격할 때 사용할 수 있다.

 

Refferer : 다른 웹 페이지를 요청할 때 이전에 열었던 페이지를 목록으로 만든다.

"마지막으로 방문한 페이지"를 뜻하며, 쉽게 바꿀 수 있기 때문에 해커에게 도움이 된다.

만일 응용프로그램이 보안에 관한 어떤 것들을 이 페이지에 의존한다면, 값을 변조하여 쉽게 우회시킬 수 있다.

 

 

 

 

* 주요 HTTP 상태 코드 

브라우저가 웹 서버로부터 응답을 받을 때 어떤 유형인지 나타내는 상태 값이 있으며, HTTP 상태 코드라 한다.

HTTP 상태 코드를 통해 입력 값을 응용프로그램이 어떻게 처리했는지 이해할 수 있다.

 

100번대 : 웹 서버가 순수하게 정보를 알려주기 위한 것, 웹 서버가 보충 응답을 보낼 것임을 나타냄. 요즘의 웹 서버는 잘 사용하지 않으며, 아래의 상태코드의 응답과 비슷한 값이 뒤따라 온다.

 

200번대 : 클라이언트의 요청이 성공적으로 접수되고 웹 서버가 처리한 다음 그 응답이 브라우저로 되돌려 보내졌음을 의미. 가장흔한 상태 값으로 '200 OK'가 있다.

 

300번대 : 다른 페이지로 돌리는 경우 즉, "Redirect"를 표시. 사용자가 웹 애플리케이션에 성공적으로 인증한 후 브라우저를 안전한 페이지로 전달할 때 많이 사용. (주로 200 OK 이후 302 Redirect로 보내지는 식이다.

 

400번대 : 클라이언트로부터 온 요청에 오류가 있음를 표시. 사용자가 보낸 요청을 웹 애플리케이션에서 처리할 수 없을 때를 뜻한다.

401 Unauthorized(권한없음)

403 Forbidden(금지됨)

404 Not Found(발견되지 않음)

등이 있다.

 

500번대 : 서버 측의 오류를 표시.

500 Internal Server Error(서버 내부 오류)

503 Service Unavailable(서비스 불가)

가 있다.

 

 

 HTTP Method
  : HTTP 프로토콜이 전달할 수 있는 method 때문에 개발자가 작성하는 웹 페이지에서 form(폼)의 전송방식이 사용된다.
   

    (1) GET  
 - 사용자가 입력하는 데이터를 URL에 볼 수 있도록 '데이터=값&데이터=값' 형태로 전송. 
 - GET 방식은 URL에 보낼 수 있는 글자 수가 255자로 제한되며, 초과되면 데이터가 절단됨.
 - 전송속도가 빨라서, 조회 등에 많이 사용된다.
    : '데이터=값'이 URL에 노출되기 때문에 보안 취약하다.
 - Request GET

    : 파일시스템으로부터 요청 받은 정보를 검색해 html이면 파일의 내용을 화면에 출력
    

ex) 테스트 방법 : cmd 창에서 telnet 명령어를 활용하는 방법도 있다.

대상 웹 서버 및 웹 사이트에 대해 요청을 했을 경우 php,asp 등 서버 어플리케이션이면 명령을 실행하고 그 결과를 출력한다.

 

위와 같은 상태에서 엔터를 치면 화면이 전환되고 아래와 같은 상태가 된다.

 

위와 같은 상태에서 아래의 명령줄을 입력해보자. 창에 글자가 나타나지 않더라도 입력이 될 것이며, 스펠링 등 띄어쓰기에 주의하여 입력을 해본다. (일정시간 입력이 없으면 다시 명령 프롬프트가 띄워진다.)

 

    GET  HTTP/1.1\r\n\r\n (CRLF) (엔터두번)
    GET index.html HTTP/1.1 (엔터)(엔터)
 => 결과에 따라 Response Header를 확인할 수 있으며, Response Content로 구성됨.
 => http 메소드를 이용하여 서버 OS 정보 수집과 허용된 권한 등을 조사, 불필요한 권한이 허용되어 있으면 파일 업로드, 수정, 삭제 가능

  

(2) HEAD : GET 방식과 유사, 차이점은 요청 받은 자료를 되돌려 주지 않고, 메타 정보(서버 응답 코드, 날짜, 서버 헤더)로  응답을 함으로써 서버 OS판단하는데 사용함. 
* HEAD  HTTP/1.0 엔터엔터 

(3) POST : 서버에서 동작하도록 하는 요청.

* POST  HTTP/1.0 엔터엔터
* Content-Length 엔터엔터
* Content-Type 엔터엔터
* Query String 

(4) OPTIONS : 자원에대한 요구/응답 관계에서 관련된 선택 사항에 대한 정보 요청. 즉, 서버측에서 어떤 헤더 method가 허용되어 있는지 알아 볼 때 사용 .
* OPTIONS /HTTP/1.0 엔터엔터

(5) PUT : 메세지를 포함한 데이터를 지정한 URI 장소에 그 이름으로 저장. 도스상태에서 명령어가 올라감.  
* URI(Uniform Resource Identifier) : 변경되지 않는 자원/장소/경로 
* URL(Uniform Resource Location) : 변경되는 자원/장소/경로  ex)웹서버ip

(6) DELETE : URI에 지정되어 있는 자원을 서버에서 삭제 
(7) TRACE : 요구 메세지를 최종 수신처까지 루프백 검사용. 
                    요구 메세지가 최종 수신 서버까지 이르는 경로 파악.   

* HTTP /1.1 method 
    => KeepAlive(HTTP 연결 유지) -2-20분(웹 서버 세션)
    => HTTP 1.0 ConnetionLess(연결을 유지하지 않고 바로 끊어 버리는 프로토콜임) 
    - CONNECT : 대표적으로 추가된 메소드, 동적으로 터널모드를 교환 할 수 있는 능력을 가진 프록시 사용

 

* 프록시 도구 
- Paros : 한눈에 요청/응답 파악 가능
- WebScarab : 다양한 기능, 설정 복잡
- Fiddler : IE, FireFox 플러그인
- Achilles : 설치 없이 포터블
- Odysses : 파라메터만 전용

* Inspection Proxies
- paros, Burp Suite, WebScarab, Achilles, Odysses

* Firefox Browser
- Tamper Data, LiveHttpHeader, SwitchProxy

* IE Browser 
- Fiddler, HttpAnalyze
- 쿠키 변조 툴 (앞으로는 이프로그램을 개발자가 알아야함)

 

* Content-Type 유형 

Content-Type은 Internt Media 타입이다. 그러나 왜 알아야 하는 가는 웹 서버 로그의 Content-Type을 보고 어떤 어플리케이션이 사용되어 있는지를 파악할 때 도움이 된다. 또한 웹 포렌식 작업을 할 때 실제 공격차단의 룰셋인지 아니면 정상적인 서비스인지의 룰인지를 판단해야 할 때 많은 도움이 될 것이다. 최근에는 웹 이외의 어플리케이션 이 HTTP+XML 형태로 사용을 많이 하기 때문에 오탐여부를 판단할 때 많은 도움이 된다. 

1) Multipart Related MIME 타입. 
- Content-Type : Multipart/related(기본형태) 
- Content-Type : Application/X-FixedRecord 
- Content-Type: Text/x-Okie; charset=iso-8859-1; 

2) XML Media의 타입. 
- Content-Type : text/xml 
- Content-Type : Application/xml 
- Content-Type : Application/xml-external-parsed-entity 
- Content-Type : Application/xml-dtd 
- Content-Type : Application/mathtml+xml 
- Content-Type : Application/xslt+xml 

3) Application의 타입.  
- Content-Type : Application/EDI-X12: Defined in RFC 1767  
- Content-Type : Application/EDIFACT: Defined in RFC 1767  
- Content-Type : Application/javascript: Defined in RFC 4329  
- Content-Type : Application/octet-stream: <-- 디폴트 미디어 타입은 운영체제 종종 실행파일, 다운로드를 의미 
- Content-Type : Application/ogg: Defined in RFC 3534  
- Content-Type : Application/x-shockwave-flash: Adobe Flash files 
- Content-Type : Application/json: JavaScript Object Notation JSON; Defined in RFC 4627  
- Content-Type : Application/x-www-form-urlencode <-- HTML Form 형태  

* x-www-form-urlencode와 multipart/form-data은 둘다 폼 형태이지만 x-www-form-urlencode은 대용량 바이너리 테이터를 전송하기에 비능률적이기 때문에 대부분 첨부파일은 multipart/form-data를 사용하게 된다.  

4) 오디오 타입. 
- Content-Type : Type audio: Audio  
- Content-Type : audio/mpeg: MP3 or other MPEG audio 
- Content-Type : audio/x-ms-wma: Windows Media Audio; 
- Content-Type : audio/vnd.rn-realaudio: RealAudio; 등등  

5) Multipart 타입(아카이브 또는 개체). 
- Content-Type : multipart/mixed: MIME E-mail;  
- Content-Type : multipart/alternative: MIME E-mail; 
- Content-Type : multipart/related: MIME E-mail; Defined in RFC 2387 and used by MHTML(HTML mail)  
- Content-Type : multipart/formed-data : <-- 파일 첨부 

6) TEXT 타입.  
- Content-Type : text/css:  
- Content-Type : text/html: 
- Content-Type : text/javascript  
- Content-Type : text/plain:  
- Content-Type : text/xml:  

7) 기타 MIMERPC 예제들. 

 

가) HTTP with x/www-form-urlencoded 일반요청  
POST /some/resource HTTP/1.1 
Content-type: application/x-www-form-urlencoded 
0=example.getStateName&1=10023 

[응답] 
HTTP/1.1 200 OK 
Content-type: text/plain 
New York 

나) HTTP x/www-form-urlencoded namedArgs getTeam 
POST /some/resource HTTP/1.1 
Content-type: application/x-www-form-urlencoded 
0=example.getTeam&state=New York&sport=Baseball 

[응답] 
HTTP/1.1 200 OK 
Content-type: multipart/mixed, boundary=B 
--BYankees 
--BMets 
--B 

다) HTTP x/www-form-urlencoded unicode addUser 
POST /some/resource HTTP/1.1 
Content-type: application/x-www-form-urlencoded 
0=example.addUser&fname=Igna%ACio&lname=Sanchez 

라) HTTP with multipart/form-data 요청 
POST /some/resource HTTP/1.1 
Content-type: multipart/form-data, boundary=AaB03x 
--AaB03x 
content-disposition: form-data; name="field1" 

Joe Blow 

--AaB03x  
content-disposition: form-data; name="pics"; filename="file1.gif" 
Content-type: image/gif 
Content-Transfer-Encoding: binary 
...contents of file1.gif...  

--AaB03x-- 

[응답]  
HTTP/1.0 200 OK 
Content-type: text/plain 
OK 

마) Uploading multiple files with unicode 

POST /foo HTTP/1.0 
Content-type: multipart/form-data, boundary=AaB03x 

--AaB03x 
content-disposition: form-data; name="field1" 
Joe Blow 

--AaB03x <-- 여러개의 파일을 첨부할 때  
content-disposition: form-data; name="pics" 
Content-type: multipart/mixed, boundary=BbC04y 

--BbC04y <-- 첫번째 첨부파일은 텍스트 
Content-disposition: attachment; filename="file1.txt" 
Content-Type: text/plain; charset=UNICODE-1-1 
Content-Transfer-Encoding: binary 
... contents of some unicode file.txt ... 


--BbC04y <-- 두번째 첨부파일은 이미지 
Content-disposition: attachment; filename="file2.gif" 
Content-type: image/gifContent-Transfer-Encoding: binary 
...contents of file2.gif... 

--BbC04y 

----AaB03x-- 

바) XML and EMail 요청 
HTP Request  
POST /x/foo/bar HTTP/1.0 
reply-to-url: callback@domain.com 
message-id: abc123 
aynch: required0=getAuthorization&1="bobjones" 

[응답]  
HTTP/1.0 200 OK 
delivered-to: callback@domain.com 
Content-length: 0 
Mail/SMTP Response  
To: callback@domain.comFrom: mimeRPC@otherplace.com 
in-reply-to: abc123 
content-type: text/xml 

또한 간혹 Content-Type외에 x-vermeer-content-type 형태가 추가로 나오는 경우가 있는데 이것은 RPC 통신을 사용하는 것을 의미하며, 마이크로소프트 제품중에 SharePoint 서버 제품군과 프론트페이지가 이 x-vermeer-Content-Type를 사용하기 때문에 기억해 두기 바란다.