무하프로젝트

기존 Form 방식과 Ajax 통신 방식을 서버에서 구분하는 방법은 존재하지 않습니다.(HTML5 명세를 제외)

하지만 트위터와 같은 몇몇 서비스의 HTTP 요청헤더를 살펴보면 X-Requested-With 필드에 "XMLHttpRequest" 값이 포함된 것을 종종 볼 수 있습니다.

- 여기서 헤더의, 접두사 "X"는 표준이 아님을 의미합니다. (Non-standard)

또한, 이 X-Requested-With 헤더는 커스텀(사용자 정의)헤더이며, 표준이 아닙니다.

하지만 다행히도 JQuery와 Prototype 같은 대중성 있는 라이브러리들이 이 헤더를 Ajax 전송 시 기본으로 추가하여 전송하고 있습니다.

또한, HTML5 명세로 넘어와서는 Origin 헤더의 유/무 로 판별이 가능해 졌지만, 이 방법 또한 IE 브라우저에서는 8+ 이상 부터 지원하고 있기 때문에 아직까지는 사용상 무리가 따르는 것이 사실입니다.

즉, 이를 완벽히 구현하기 위해서는 각 브라우저 환경에 맞도록 클라이언트와 서버 프로그램을 설계해야 하는 추가적인 작업이 들어갑니다.

- 이 방법에 대해서는 다음 포스트인 "CORS" 에서 더 자세히 다루도록 하겠습니다.(클라이언트 및 서버 구현)

아래 코드는 위에서 설명해 드린 "X-Requested-With"와 "Origin" 헤더 유/무를 통해 서버에서 Ajax 전송을 판별하는 과정입니다.

1. 동일 도메인(NOT CORS)일 경우:

서버측 코드:

GET 방식 실행결과:

위에서 언급한 바와같이 커스텀헤더인 "X-Requested-With" 헤더가 클라이언트 전송 시 포함되어있다.

POST 방식 실행결과(OPTIONS 메서드 요청 > GET 메서드 요청):

위에서 언급한 바와같이 커스텀헤더인 "X-Requested-With" 헤더가 클라이언트 전송 시 포함되어있다.

2. 타 도메인(CORS 통신)일 경우:

서버측 코드:

GET 방식 실행결과(GET 메서드 요청):

위에서 언급한 바와같이 HTML5 명세부터 적용된 Origin 헤더가 클라이언트 전송 시 포함되어있다.

POST 방식 실행결과(OPTIONS 메서드 요청 --> GET 메서드 요청):

위에서 언급한 바와같이 HTML5 명세부터 적용된 Origin 헤더가 클라이언트 전송 시 포함되어있다.

- OPTIONS --> POST 메서드 요청

- OPTIONS 메서드 요청

- POST 메서드 요청

- 결과: 

3. (CORS 통신 + Custom Header) 추가 시

3.1. 기본 CORS GET 요청 시: 

기본적인 CORS 통신은 위 설명과 같이 문제없이 구동된다.

3.2. CORS GET/POST 요청 + Custom Header(사용자 정의 헤더) 추가 시:  

총 두 번의 요청(OPTIONS + GET/POST)이 발생하며, 관련 헤더를 추가하기 전까지는 해당 요청 시 에러가 발생한다.

3.3. CORS GET/POST 요청 시 추가적인 OPTIONS 메서드 요청이 발생하는 이유는?  

- 해당 서버에서 요청 URL 허용(Access-Control-Allow-Origin) 유/무를 확인하기 위함.

3.4. 해결 방법(관련 헤더 추가)은?

조건: CORS GET/POST 요청 + Custom Header(사용자 정의 헤더) 추가

- 클라이언트 단 소스(x-sid(사용자 헤더))

- 서버 단(web.config) 소스:

* "HTTP Module" 을 통해 개별적(리소스 별) 적용 방법도 가능할 것이다.

- 실행 결과:

첫 번째 요청인 OPTIONS 메서드 요청 시 메시지 헤더 값:

- 두 번째 요청인 GET 메서드 요청 시 메시지 헤더 값:

참고 사이트:

다니엘님의 CORS(Custom Header) 정리 글.

http://daeheehan.cafe24.com/wp/?p=274

http://parkmo.egloos.com/4155695

html5rocks CORS 정리글(추천)

http://www.html5rocks.com/en/tutorials/cors/

1. HTTP Message 정의

HTTP Message는 크게 요청과 응답 메시지로 구분됩니다.

또한, Version에 따라 지원 가능한 Method가 존재합니다.

즉 HTTP/1.0 이하 Version일 때 GET 요청만 가능하며 응답 또한 text 타입으로 제한됩니다.

- Version별 지원 Method 현황

HTTP/0.9: "GET"

HTTP/1.0: "GET", "POST", "HEAD"

HTTP/1.1: "GET", "POST", "HEAD", "OPTIONS", "PUT", "DELETE", "TRACE", "CONNECT"

HTTP Message 는 크게 라인, 헤더, 바디 영역으로 나뉘며, 또 여기서 헤더와 바디 영역은 공백으로 구분됩니다.

또한, 바디 영역을 제외한 나머지 영역(요청, 헤더)의 각 라인은 연속된 CR/LF(\r\n) 문자로 구분됩니다.

2. Message Herder:

일반(General)헤더: 요청과 응답 모두에 사용할 수 있는 헤더입니다.

요청(Request), 응답(Response)헤더: 각 요청과 응답 시에 사용되는 헤더입니다.

엔티티(Entity)헤더: 파일의 인코딩 방식, 최종 수정 일자와 같은 외형적인 정보를 나타내기 위해 쓰이는 헤더입니다.

- 헤더는 필요에 따라 사용자가 직접 정의해서 사용 가능하며, 이러한 모든 헤더는 엔티티 헤더로 분류되어 정의됩니다.

3. HTTP Request Method:

1. OPTIONS: 서버 자원 및 기능검색

- 보통 Web 서버가 어떤 Method를 지원하는지 알기 위해 사용합니다.

nate.com 에서 요청 가능한 Method는 Allow(OPTIONS, TRACE, GET, HEAD) 이며, 서버에서 지원 가능한 Method는 Public(OPTIONS, TRACE, GET, HEAD, POST) 입니다.

2. GET: URL의 서버 자원을 요청합니다.

서버에 전달되는 해당 데이터(파라메터)가 라인 영역의 Request-URL에 포함됩니다.

3. HEAD: 바디 영역을 제외한 서버 정보를 요청합니다.

- 보통 요청하는 URI의 자원 유/무를 알아내기 위해 사용됩니다.

4. POST

GET 요청과는 달리 해당 데이터(파라메터)가 Request-URL에 포함되지 않으며 요청 바디 영역에 포함됩니다.

5. PUT: 바디 영역의 내용을 실제 서버 URI 위치에 파일로 저장합니다.

하지만 이 때문에 서버 파일 조작이 가능해져 대부분의 웹 서버에서는 지원하지 않는 Method입니다.

6. DELETE: 서버에 저장된 자원을 삭제합니다.

하지만 이 때문에 서버 파일 조작이 가능해져 대부분의 웹 서버에서는 지원하지 않는 Method입니다.

7. TRACE: 요청 자원이 수신되는 경로를 보여줍니다.

8. CONNECT: 프록시와 같은 중간 서버에 터널을 형성하여 요청하기 위해 사용합니다.

HTTP1.0-1.1 Protocol Massage & Header 구성요소: 

http://coffeenix.net/doc/network/http_1_0_vs_1_1.html

HTTP의 소개:

http://www.nicklib.com/bbs/board.php?bo_table=bbs_lecture&wr_id=32&page=3

http://www.nicklib.com/bbs/board.php?bo_table=bbs_lecture&wr_id=34&page=3

HTTP URL:

http://www.nicklib.com/bbs/board.php?bo_table=bbs_lecture&wr_id=35&page=3

HTTP Message:

http://www.nicklib.com/bbs/board.php?bo_table=bbs_lecture&wr_id=36&page=3

HTTP General:

http://www.nicklib.com/bbs/board.php?bo_table=bbs_lecture&wr_id=37&page=3

HTTP Request:

http://www.nicklib.com/bbs/board.php?bo_table=bbs_lecture&wr_id=38&page=3

이번 포스트에서는 HTTPS 프로토콜의 암호화 패킷 교환 방식인 SSL의 정의 및 동작 방식에 대해 설명 드리도록 하겠습니다.

그 첫 번째 예제로 웹 브라우저를 통해 HTTPS 프로토콜을 사용하는 구글 페이지에 접속합니다.

보통 웹 상에서 HTTPS 프로토콜을 사용하는 페이지에 접근 시 SSL 동작이 시작됩니다.

1. SSL 동작 방식에 대한 기본 예

상세 예제 사이트:

http://www.docstoc.com/docs/53837043/SSL(Secure-Socket-Layer)

2. SSL 동작 방식에 대한 WIRE SHARK 패킷 교환 예

아래 그림의 파란 테투리는 "TCP 3 Way Handshake" 부분을 가리키고, 빨간 테두리는 "SSL 패킷 교환 협상" 부분을 가리킵니다. 

아래는 SSL 동작 방식으로 인해 암호화 된 패킷을 보여주는 예입니다.

동작 방식에 대한 상세 설명:

클라이언트 호스트(211.254.99.210(클라이언트))

이번 포스트에서는 SSL 동작 방식에 앞서 패킷 교환 방식의 기본인 TCP 3 Way Handshake에 대해서 알아보도록 하겠습니다.

TCP 3 Way Handshake의 정의:

송신 측과 수신 측이 서로 교환할 패킷을 위해 총 3개의 패킷을 주고받으며, 서로에 대한 전송을 보장하는 세션을 수립하는 

과정입니다.

아래는 TCP 3 Way Handshake 과정을 대략적으로 도식화 한 그림 입니다.

TCP 3 Way Handshake 에 대한 상세 과정은 아래와 같습니다.

송신 측 호스트(211.254.99.210(클라이언트))

수신 측 호스트(203.242.213.203(웹서버))

1. 송신 측은 수신 측과의 통신을 원하고 있음을 알리는 신호로 TCP 헤더의 SYN(Synchoronize) Flag를 활성화(1)하고, 패킷에 일련번호(S/N(seq = 0))를 붙어 상대방에게 알려줍니다.

2. 이때 수신 측은 송신 측 SYN(Synchoronize)Flag 신호에 대한 응답 패킷 생성에 들어가기 위해, ACK(Acknowledgement)Flag를 on 시키고, 송신 측 일련번호(S/N(seq = 0))에 1을 더한 응답(A/N(ack = 1))값과 

자신의 일련번호(S/N(seq = 0))를 발송합니다. 또한, 이 과정은 송/수신 측의 양방향 세션이 수립되었음을 의미합니다.

3. 송신 측은 수신 측에게 두 번째 패킷(ack 및 일련번호(S/N(seq = 1) == (수신 측에게 받은 ack = 1 값))에 대한 응답을 주며, 이때부터 양 방향 패킷 교환이 시작되는 것입니다.

아래는 송/수신 간에 패킷 교환이 이루어지는 과정입니다.

송/수신간에 세션 수립(TCP 3 Way Handshake) 과정이 끝난 후 송신 측이 수신 측에게 GET요청을 보내고 있으며, 그에 따른 응답 메시지가 전송되고 있습니다.

위와 마찬가지로 송신 측의 GET 요청에 대한 응답 메시지가 전송됩니다.

페이지의 구성요소(js, css, img 등)이 요청됩니다.

웹서버가 클라이언트에게 HTML 응답 패킷을 전송합니다.

1. HTTP Header Content-Type Field란?

Content-Type이란 말 그대로 사용자 요청과 응답 메시지 타입을 뜻하며, 크게 Discrete-Type 과 Composite-Type으로 나뉩니다.

또한, 문법으로 아래와 같은 형태를 가집니다.

Content-Type(필드명): text(타입)/plain(서브타입); charset=us-ascii(파라메터)

Discrete-Type: 그 자체로 어떤 의미를 가지고 있는 Content-Type을 나타낸다.

예) "text" / "image" / "audio" / "video" / "application" / extension-token

Composite-Type: Discrete-Type 혹은 Composite-Type의 개체 여러 개가 복합되어 만들어진 타입을 나타낸다.

예)  "message" / "multipart" / extension-token

MIME Type 참고 사이트

http://www.iana.org/assignments/media-types/index.html

즉, 아래 그림의 Accept 필드는 응답 시 브라우저가 허용할 수 있는 메시지 타입을 가리키며, Content-Type은 그에 따른 응답 메시지 타입을 나타내는 것입니다.

2. HTTP란?

HTTP란 간단히 말해 웹 브라우저와 웹서버 간에 메시지 교환 프로토콜입니다. 즉, 일종의 대화 규칙이며, 교환 방식은 복잡한 바이너리 데이터가 아닌 단순 텍스트를 통해 이루어집니다.

위에서 설명한 Content-Type의 응답 메시지(html, xml, 등..)또한, 단순 텍스트로 교환되며, 

만약 누군가가 주고받는 네트웍 패킷을 가로채 볼 수 있다면, 메시지 내용이 그대로 보이게 되므로 보안상 치명적 결과를 가져올 수 있는 상황입니다.

즉, 컨텐츠 보안이 필요한 경우에는 HTTPS 프로토콜을 사용하여, 주고받는 네트웍 패킷을 알고리즘을 통해 모두 암호화 해야 할 필요가 있습니다.

3. HTTPS란?

HTTPS는 HTTP와 같은 통신 프로토콜이며, 쓰임새(메시지 전송) 또한, HTTP와 거의 흡사합니다.

하지만 HTTPS는 앞서 설명했던 HTTP의 취약점을 보완하기 위해 주고받는 모든 메시지를 암호화하며, 암호화 방식에 쓰이는 Key의 종류로는 크게 대칭과 비대칭 둘로 나뉘게 됩니다.

간단히 동작원리에 대해 설명하자면, 클라이언트(웹 브라우저)와 서버(웹서버)가 서로 교환한 세션키(대칭키)로 주고받는 모든 컨텐츠 내용을 암호화합니다.

즉, 중간에 네트웍 패킷을 가로챈다 해도 암호화된 내용이 노출되므로 보안상 안전하며, 공유된 세션키(대칭키)를 모르는 상황에서 암호화를 푼다는 것은 모든 경우의 키를 대입해야 한다는 말이 됩니다.

만약 1024 비트(보통은 128비트 암호화)의 암호화라면, 평균적으로 2의 512승을 대입해야하며, 이것은 2475880078570760000000000000.00이라는 수를 대입해야 한다는 뜻과 같습니다.

이 숫자는 아무리 빠른 컴퓨터(현재까지 나온..)라 할지라도 약 몇 천 년에 걸려 계산되어야 할 것 입니다.

위에서 설명한 내용 중 세션키 교환 동작과 같은 더 자세한 설명은 다음 포스트 주제인 SSL 동작원리에서 다루도록 하겠습니다.

HTTP or HTTPS 주고받는 메시지 비교

게시판 글등록: 

글 등록시 Post로 주고 받는 패킷

보시는 바와 같이 사용자에 의해 기입되었던 title 및 content 등의 모든 내용이 그대로 노출되는것을 확인 할 수 있습니다.

HTTPS 프로토콜과 SSL 보안 인증서를 활용한 페이지에서 주고 받는 패킷

아래 그림과 같이 주고받는 모든 메시지 내용이 HTTP와는 다르게 해당 알고리즘에 의해 암호화 되어있습니다.