[그림으로 배우는 Http&Network Basic] 06-11

Posted Oct 22, 2023 Updated Oct 22, 2023

By Jung Yeonseo 53 min read

그림으로 배우는 Http & Network Basic - 우에노 센

김영한님의 인프런 강의 - 모든 개발자를 위한 HTTP 웹 기본 지식 을 들으면서 천재 개발자 최야호씨가 추천해준 웹, 네트워크 입문서가 생각이 났고, 강의 내용을 복기하는 데도 큰 도움이 될 것 같아 읽어보기 시작했다. + 강의 리뷰 보러가기

책의 목차는 다음과 같다.

웹과 네트워크의 기본에 대해 알아보자 - HTTP란? HTTP의 발전 과정, 계층 구조, URI 등
간단한 프로토콜 HTTP - HTTP 프로토콜의 구조
HTTP 정보는 HTTP 메시지에 있다 - 리퀘스트와 리스폰스의 동작 방식
결과를 전달하는 HTTP 상태 코드 - 상태 코드 설명
HTTP와 연계하는 웹 서버 - 멀티 도메인, 중계 서버
HTTP 헤더
웹을 안전하게 하는 HTTPS - HTTPS 구조
누가 액세스하고 있는지를 확인하는 인증 - 인증의 구조
HTTP에 기능을 추가한 프로토콜
웹 콘텐츠에서 사용하는 기술
웹 공격 기술 - 웹 사이트 공격 유형과 영향

6. HTTP 헤더

(무려 70페이지 이상의 방대한 양을 정리하기는 무리고 비효율적일 것 같아 아주아주 간략히 축약하겠다.)

HTTP 프로토콜의 리퀘스트와 리스폰스에는 반드시 메시지 헤더가 포함되어 있으며 가장 다양한 정보를 가지고 있는 것이 HTTP 헤더 필드이다.

메시지 헤더에는 클라이언트와 서버 처리에 필요한 주요 정보가 들어 있으며, 메시지 바디에는 사용자와 리소스를 필요로 하는 정보가 담겨 있다.

HTTP 헤더 필드

HTTP의 구성 요소 중 하나로 메시지 바디의 크기나 사용 언어, 인증 정보 등을 브라우저나 서버에 제공하기 위해 사용되고 있다.

헤더 필드명: 필드 값 으로 구성되어 있으며 하나의 헤더 필드가 여러 개의 필드 값을 가질 수 있다.

일반적으로 용도에 따라 다음의 4종류로 분류된다.

일반적 헤더 필드(General Header Fields)

리퀘스트 메시지와 리스폰스 메시지 둘 다 사용되는 헤더

헤더 필드 명	설명
Cache-Control	캐싱 동작 지정
Connection	Hop-by-Hop 헤더, 커넥션 관리
Date	메시지 생성 날짜
Pragma	메시지 제어
Trailer	메시지의 끝에 있는 헤더의 일람
Transfer-Encoding	메시지 바디의 전송 코딩 형식 지정
Upgrade	다른 프로토콜에 업그레이드
Via	프록시 서버에 관한 정보
Warning	에러 통지

리퀘스트 헤더 필드(Request Header Fields)

클라이언트 측에서 서버 측으로 송신된 리퀘스트 메시지에 사용되는 헤더로, 리퀘스트의 부가적 정보와 클라이언트 정보, 리스폰스 콘텐츠에 관한 우선 순위 등을 부가한다.

헤더 필드 명	설명
Accept	유저 에이전트가 처리 가능한 미디어 타입
Accept-Charset	문자셋 우선 순위
Accept-Encoding	콘텐츠 인코딩 우선 순위
Accept-Language	언어(자연어) 우선 순위
Authorization	웹 인증을 위한 정보
Expect	서버에 대한 특정 동작의 기대
From	유저의 메일 주소
Host	요구된 리소스의 호스트
If-Match	엔티티 태그의 비교
If-Modified-Since	리소스 갱신 시간 비교
If-None-Match	엔티티 태그의 비교(If-Match의 반대)
If-Range	리소스가 갱신되지 않은 경우, 엔티티의 바이트 범위의 요구를 송신
If-Unmodified-Since	리소스의 갱신 시간 비교(If-Modified-Since의 반대)
Max-Forwards	최대 전송 홉 수
Proxy-Authorization	프록시 서버의 클라이언트 인증을 위한 정보
Range	엔티티 바이트 범위 요구
Referer	리퀘스트중의 URI를 취득하는 곳
TE	전송 인코딩의 우선 순위
User-Agent	HTTP 클라이언트의 정보

리스폰스 헤더 필드(Response Header Fields)

서버 측에서 클라이언트 측으로 송신한 리스폰스 메시지에 사용되는 헤더로, 리스폰스 정보와 서버 정보, 클라이언트의 추가 정보 요구 등을 부가한다.

헤더 필드 명	설명
Accept-Ranges	바이트 단위의 요구를 수신할 수 있는지 여부
Age	리소스의 지정 경과 시간
Etag	리소스를 특정하기 위한 정보
Location	클라이언트를 지정한 URI에 리다이렉트
Proxy-Authenticate	프록시 서버의 클라이언트 인증을 위한 정보
Retry-After	리퀘스트 재시행의 타이밍 요구
Server	HTTP 서버 정보
Vary	프록시 서버에 대한 캐시 관리 정보
WWW-Authenticate	서버의 클라이언트 인증을 위한 정보

엔티티 헤더 필드(Entity Header Fields)

리퀘스트 메시지와 리스폰스 메시지에 포함된 엔티티에 사용하는 헤더로 콘텐츠 갱신 시간 등의 엔티티에 관한 정보를 부가한다.

헤더 필드 명	설명
Allow	리소스가 제공하는 HTTP 메소드
Content-Encoding	엔티티 바디에 적용되는 콘텐츠 인코딩
Content-Language	엔티티의 자연어
Content-Length	엔티티 바디의 사이즈(바이트 단위)
Content-Location	리소스에 대응하는 대체 URI
Content-MD5	엔티티 바디의 메시지 다이제스트
Content-Range	엔티티 바디의 범위 위치
Content-Type	엔티티 바디의 미디어 타입
Expires	엔티티 바디의 유효기한 날짜
Last-Modified	리소스의 최종 갱신 날짜

HTTP/1.1 이외의 헤더 필드

RFC4229 Header Field Registrations에 정리되어 있다.

쿠키와 관련된 헤더 필드나

헤더 필드 명	설명
Set-Cookie	상태 관리 개시를 위한 쿠키 정보, 리스폰스
Cookie	서버에서 수신한 쿠키 정보, 리퀘스트

독자적인 헤더 필드가 있다.

헤더 필드 명	설명
X-Frame-Option	다른 웹사이트의 프레임에서 표시 제어. 클릭 재킹 공격을 막는 것을 목적으로 함
X-XSS-Protection	크로스 사이트 스크립팅(XSS)의 대책으로서 브라우저의 XSS 보호 기능 제어
DNT	Do Not Track이라는 뜻으로 개인 정보 수집 거부 의사를 나타냄
P3P	웹 사이트 상의 프라이버시 정책에 P3P(The Platform for Privacy Preferences)를 사용

End-to-end 헤더와 Hop-by-hop 헤더

캐시와 비캐시 프록시의 동작을 정의하기 위해 두가지 카테고리로 분류된다.

End-to-end 헤더는 리퀘스트나 리스폰스의 최종 수신자에게 전송된다. 캐시에서 구축된 리스폰스 중 보존되야 하고, 다시 전송되지 않으면 안 된다. Hop-by-hop 헤더는 한 번 전송에 대해서만 유효하고 캐시와 프록시에 의해 전송되지 않는 것도 있다.

Connection, Keep-Alve, Proxy-Authenticate, Proxy-Authorization, Trailer, TE, Transfer-Encoding, Upgrade가 Hop-by-hop 헤더에 해당하며, 이외에는 모두 End-to-end 헤더로 분류된다.

7. 웹을 안전하게 지켜주는 HTTPS

HTTP는 크게 세 가지의 약점이 있는데 이를 해결하기 위해 HTTPS가 등장했다.

HTTP에 암호화나 인증 등의 구조를 더한 것을 HTTPS(HTTP Secure) 라고 부른다.

웹 페이지의 로그인이나 쇼핑의 결제화면 등에서 사용되며 HTTPS를 사용한 통신은 URI에 http:// 가 아닌 https:// 를 사용한다.

HTTPS는 새로운 애플리케이션 계층의 프로토콜은 아니며, HTTP 통신을 하는 소켓 부분을 SSL이나 TLS라는 프로토콜로 대체한 형태이다. HTTP는 보통 TCP와 직접 통신하지만 SSL을 사용하는 경우에는 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다.

SSL을 사용함으로써 HTTP는 HTTPS로서 암호화, 증명서, 완전성 보호를 이용할 수 있게 되며 SSL은 HTTP와는 독립된 프로토콜이다.

공개키 암호화 방식

SSL에서는 공개키 암호화 방식을 채택하고 있다.

암호화와 복호화에 하나의 키를 같이 사용하는 방식을 공통키 암호 라고 부른다. 공통키 암호 방식은 상대에게 안전하게 키를 배송하고, 받은 키를 안전하게 보관하는 것이 중요하다. 이러한 문제를 해결하기 위해 공개키 암호 방식이 사용된다.

공개키 암호는 서로 다른 두개의 키 페어(비밀키와 공개키)를 사용한다. 암호를 보내는 측이 상대의 공개키를 이용해 암호화를 하고, 암호화된 정보를 받아들인 상대는 자신의 비밀키를 사용해 복호화를 실시한다.

이 방식은 암호를 푸는 비밀키를 통신으로 보낼 일이 없기 때문에 도청에 의해 키를 빼앗길 걱정이 없으며, 암호문과 공개키에서 평문을 구하는 것은 매우 어려운 수학적 특징이 있어 간단하지 않다.

HTTPS는 공통키 암호와 공개키 암호의 양쪽 성질을 가진 하이브리드 암호 시스템이다. 키를 안전하게 교환할 수만 있다면 공개키 암호만을 사용해 통신을 해도 괜찮다고 생각할 수 있으나 공개키 암호는 공통키 암호에 비해 처리 속도가 늦다. 두 방식의 장점을 살릴 수 있도록 키를 교환하는 곳에는 공개키 암호를 사용하고, 그 후의 통신에서 메시지를 교환하는 곳에서는 공통키 암호를 사용한다.

증명서

공개키 암호가 진짜인지 아닌지를 증명할 수 없다. 이를 해결하기 위해 인증 기관과 인증 기관이 발행하는 공개키 증명서가 이용되고 있다.

인증 기관은 다음과 같이 이용된다.

서버 운영자가 인증 기관에 공개키를 제출한다.
인증 기관은 제출된 공개키에 디지털 서명을 하고 공개키 인증서에 서명이 끝난 공개키를 담는다.
서버는 인증 기관에 의해 작성된 공개키 인증서를 클라이언트에 보내고 공개키 암호로 통신한다.
증명서를 받은 클라이언트는 증명 기관의 공개키를 사용해 서버의 공개키를 신뢰할 수 있다.

인증 기관의 공개키는 안전하게 클라이언트에 전달되어야 한다. 통신 중에는 어려운 문제이므로 많은 브라우저가 주요 인증 기관의 공개키를 사전에 내장한 상태로 제품을 내놓는다.

조직의 실제성을 증명하는 EV SSL 증명서도 있으며, 클라이언트를 확인하는 클라이언트 증명서도 이용이 가능하다. 그러나 클라이언트 증명서는 증명서의 입수와 배포에 비용이 소모되며, 클라이언트의 실재를 증명할 뿐 사용자의 존재 유무를 증명하는 증면서는 아니라는 문제점이 있다.

SSL은 인증 기관을 신용할 수 있다는 전제로 이루어져 있으며, 독자적으로 구축한 인증 기관을 자기 인증 기관이라 부르고 여기서 발행한 쓸모 없는 증명서를 비하해 ‘나야 나 증명서’라고 부르기도 한다. 마이너 인증 기관을 사용하면 ‘나야 나 증명서’ 가 될 수도 있다.

HTTPS 통신 구조

여기에 덧붙여 애플리케이션 계층의 데이터를 송신할 때는 MAC(Message Authentication Code)라는 메시지 다이제스트를 덧붙여 변조를 감지하고 완전성 보호를 실현할 수 있다.

SSL

SSL을 사용하면 처리가 늦어지게 된다는 단점이 있는데 원인은 다음과 같다.

TCP 접속과 HTTP 리퀘스트/리스폰스 이외에 SSL에 필요한 통신이 추가되면서 전체적으로 처리할 통신이 증가하여 통신 속도가 떨어진다.
SSL은 반드시 암호화 처리를 하고 있기 때문에 암호화나 복화화를 위한 계산 때문에 CPU나 메모리 등의 리소스를 다량으로 소비한다.

네트워크 부하는 HTTP에 비해 2-100배 느리나, 이를 근본적으로 해결할 방법은 없기 때문에 SSL 엑셀레이터라는 하드웨어를 사용하여 해결하기도 한다. 이러한 이유로 항상 HTTPS를 사용하지는 않으며 민감한 정보를 포함하지 않는 통신에서는 HTTP를 사용하고, 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용한다. HTTPS를 사용하기 위해서 증명서가 필요하기 떄문에 이러한 비용이 부담되는 서비스나 개인적인 웹 사이트에서는 HTTP만 선택하는 경우도 있다.

8. 누가 액세스하고 있는지를 확인하는 인증

액세스하고 있는 쪽이 본인임을 확인하기 위해 사용할 수 있는 방법으로는 패스워드, 원타임 토큰, 전자 증명서, 바이오 매트릭스, IC 카드 등이 있다. HTTP/1.1에서 사용하는 인증 방식에는 다음이 있다.

BASIC 인증

BASIC 인증의 과정은 다음과 같다.

BASIC 인증이 필요한 리소스에 리퀘스트가 있을 경우 서버는 상태 코드 401 Authorization Required와 함께 인증 방식(BASIC)과 문자열을 WWW-Authenticate 헤더 필드에 포함해 리소스를 반환한다.
상태 코드 401을 받은 클라이언트는 인증을 위해 ID와 패스워드를 Base64로 불리는 형식으로 인코드한 문자열을 서버에 송신한다.
서버는 리퀘스트를 수신해 인증 정보의 정확성을 판단하고, 인증 정보가 정확하다면 Request-URI 리소스를 포함한 리스폰스를 반환한다.

Base64라는 인코딩 형식을 사용하지만 암호화는 아니기 때문에 아무런 정보 없이도 복호화가 가능하므로 도청된 경우에는 복호화된 유저 ID와 패스워드를 빼앗길 가능성이 있다. 뿐만 아니라 한번 BASIC 인증을 하면 일반 브라우저에서는 로그아웃할 수 없어 사용상 문제와 웹 사이트에서 요구되는 보안 등급에 미치지 않는다는 단점이 있다.

DIGEST 인증

BASIC 인증의 단점을 보완하기 위한 방식이다, 리스폰스 코드라는 패스워드와 챌린지 코드를 이용해 계산한 결과를 송신하므로 패스워드 누출 가능성이 줄어든다.

인증이 필요한 리소스에 리퀘스트가 있을 경우 서버는 상태 코드 401 Authorization Required와 함께 챌린지 리스폰스 방식의 인증에 필요한 챌린지 코드(nonce)를 WWW-Authenticate 헤더 필드에 포함해 리소스를 반환한다. “realm”과 “nonce”는 반드시 포함되어야 하며 nonce는 401 리스폰스를 반환할 때마다 생성되는 유일한 문자열이다.
상태 코드 401을 받은 클라이언트는 인증을 위해 “username”, “realm”, “nonce”, “uri”, “response” 를 Authorization 헤더에 반드시 포함해 서버에 송신한다.
서버는 리퀘스트를 수신해 인증 정보의 정확성을 판단하고, 인증 정보가 정확하다면 Request-URI 리소스를 포함한 리스폰스를 반환한다. 서버는 Authentication-Info 헤더 필드에 성공한 인증에 대한 몇 가지 정보를 추가하기도 한다.

BASIC 인증에 비해서 높은 보안 등급을 제공하지만 HTTPS의 클라이언트 인증과 비교하면 낮으며, 도청 방지 보호 기능은 제공하나 위장을 방지하는 기능을 제공하지 않는다. 마찬가지로, 사용상의 문제와 웹 사이트에서 요구되는 보안 등급에 미치지 못해 잘 사용되지는 않는다.

SSL 클라이언트 인증

HTTPS의 클라이언트 인증서를 이용하는 방식으로 과정은 다음과 같다.

인증이 필요한 리소스에 리퀘스트가 있을 경우 서버는 클라이언트에게 증명서를 요구하는 “Certificate Request” 메시지를 송신한다.
유저는 송신하는 클라이언트 증명서를 선택하고, 클라이언트는 증명서를 “Client Certificate” 메시지로 송신한다.
서버는 증명서를 검증하여 결과가 정확하다면 클라이언트의 공개키를 취득한다. 이후로는 HTTPS에 의한 암호를 개시한다.

SSL클라이언트 인증은 대부분 폼 베이스 인증과 합쳐 2-factor 인증으로 사용하고 있다. 클라이언트 증명서를 위해서는 구입 비용이나 인증 기관 운용 비용 등의 비용이 발생한다.

폼 베이스 인증

HTTP프로토콜로서 사양이 정의되어 있지는 않으며 서버 상의 웹 애플리케이션에 자격 정보를 송신하여 검증 결과에 따라 인증하는 방식이다. 사전에 등록해 둔 자격 정보인 유저 ID와 패스워드를 입력해 애플리케이션 측에 송신하고 결과를 토대로 검증 여부를 결정한다.

폼 베이스 인증 과정의 예시는 다음과 같다.

클라이언트와 서버에 유저 ID나 패스워드 등의 자격 정보를 포함한 리퀘스트를 송신한다. 주로 POST 메소드가 사용되어 엔티티 바디에 자격 정보를 저장하고, HTML 폼 화면 표시와 입력 데이터의 송신에는 HTTPS 통신을 이용한다.
서버는 유저 식별을 위해 세션 ID를 발행한다. 클라이언트에서 수신한 자격 정보를 검증해 인증하고 인증 상태를 세션 ID와 연관지어 서버에 기록한다. 클라이언트측에 Set-Cookie 헤더 필드에 세션 ID를 저장해 리스폰스를 반환한다. 세션 ID는 유저를 구별하기 위한 것으로 도난 당하거나 유추되지 않도록 추측하기 어려운 문자열을 사용하고 서버 측에서는 유효 기간을 관리하는 등 보안 유지의 필요가 있다. 크로스 사이트 스크립팅 등의 취약성이 존재하는 경우라도 피해를 줄이기 위해 쿠키에 httpsonly 속성을 부여해 두는 것이 좋다.
서버 측에서 세션 ID를 받은 클라이언트는 쿠키로 저장해돈다, 다음번에 서버에 리퀘스트를 송신할 때는 브라우저가 자동으로 쿠키를 송출해 세션 ID가 서버에 송신된다.

인증의 대부분이 폼 페이스이며, 공통 사양이 결정되어 있지 않다. 일반적으로 세션 관리를 위해 쿠키를 사용한다. 자격 정보를 교환하는 방법, 패스워드 등의 자격 정보를 보존하는 방법 등 표준화되어 있지 않다. 일반적으로 패스워드를 salt라는 부가 정보를 사용해 해시 알고리즘으로 계산한 값을 저장한다.

이외의 인증 방법

통합 Windows 인증(Kerberos 인증, NTLM 인증)

9. HTTP에 기능을 추가한 프로토콜

HTTP는 HTML로 작성된 문서를 전송하기 위한 프로토콜로 여겨졌으나, 시대가 변화함에 따라 다방면에서 사용하게 되었고 웹 브라우저 환경이 널리 퍼진 현재, HTTP의 부족한 기능을 보완하기 위해 HTTP를 기반으로 하되 기능을 추가하는 형태로 프로토콜이 구현되었다.

SPDY

HTTP의 병목 현상을 해소하고 웹 페이지 로딩 시간을 50% 단축한다는 목표로 개발된 프로토콜이다.

HTTP는 다음의 병목 사항이 존재한다.

- 1개의 커넥션으로 1개의 리퀘스트만 보낼 수 있다.
- 리퀘스트는 클라이언트에서만 시작할 수 있고 리스폰스만 받는 것은 불가하다.
- 리퀘스트/리스폰스 헤더를 압축하지 않은 채 보내, 헤더의 정보가 많을 수록 지연이 심하다.
- 매번 같은 헤더를 보내는 것은 낭비이다.
- 데이터 압축이 강제적이지 않다. 

Ajax(Asynchronous JavaScript+XML) 은 JavaScript나 DOM(Document Object Model) 조작 등을 활용하는 방식으로 웹 페이즈의 일부만 고쳐쓸 수 있는 비동기 통신 방법이다. XMLHttpRequest라는 핵심 기술로 이미 읽어들인 웹 페이지로부터 리퀘스트를 발행할 수 있어 페이지의 일부 데이터를 받는 것이 가능하나 실시간으로 서버에서 정보를 취득 시에는 대량의 리퀘스트가 발생한다는 문제가 있다.

Comet 은 리스폰스를 보류 상태로 해두고 서버의 콘텐츠가 갱신되었을 때 리스폰스를 반환한다. 응답을 연장시킴으로써 서버에서 통신을 개시하는 서버 푸시 기능을 유사하게 따른다. 콘텐츠를 실시간으로 갱신하는 것이 가능하나 리스폰스를 보류하기 위해 커넥션을 유지하는 시간이 길어지고 이 동안은 리소스를 소비하게 된다는 문제가 있다.

근본적인 개선을 위해 프로토콜 레벨에서의 개선이 필요한데, SPDY는 TCP/IP의 애플리케이션 계층과 트랜스포트 계층 사이에 새로운 세션 계층을 추가하는 형태로 동작하고, 보안을 위해 표준 SSL을 사용한다. HTTP의 커넥션이 확립되어 있어 HTTP의 메소드나 쿠키, 메시지를 그대로 사용할 수 있으며 세션 계층에서 데이터의 흐름을 제어한다.

단일 TCP 접속을 통해 복수의 HTTP 리퀘스트를 무제한으로 처리할 수 있는 다중화 스트림이나 각 리퀘스트에 우선 순위 부여, HTTP 헤더 압축, 서버 푸시 기능, 리퀘스트 해야 할 리소스를 클라이언트에 제안하는 서버 힌트 기능 을 HTTP에 추가할 수 있다.

SPDY는 HTTP의 병목 현상을 해결하는 좋은 기술이나 대부분의 웹 사이트 문제는 HTTP의 병목 현상 때문 만은 아니며, 하나의 웹 사이트에서 복수의 도메인으로 리소스를 사용하는 경우 효과는 한정적이다. 웹 자신을 고속화하기 위해 웹 콘텐츠 제작을 개선하는 등 부수적으로 할 일이 많다.

WebSocket

Ajax, Comet은 웹 브라우징을 고속화하지만 HTTP를 사용하는 이상 병목 현상을 해결할 수 없다. 새로운 프로토콜과 API에 의해 이러한 문제를 해결하고자 개발한 것이 WebSocket이다.

WebSocket은 웹 브라우저와 웹 서버를 위한 양방향 통신 규격으로, 웹 서버와 클라이언트가 한번 접속을 확립하면 그 뒤의 통신을 모두 전용 프로토콜로 하는 방식으로 JSON, XML, HTML, 이미지 등의 임의 형식의 데이터를 보낸다. 접속을 확립하면 서버와 클라이언트 어느 쪽에서도 송신을 할 수 있게 되어 서버 푸시 기능, 통신량의 삭감 (한번 접속을 확립하면 핸드쉐이크 절차를 밟을 필요가 없음)이라는 특징이 있다.

핸드 쉐이크 과정은 다음과 같다.

WebSocket으로 통신을 하려면 HTTP의 Upgrade 헤더 필드를 사용해 프로토콜을 변경하는 것으로 핸드 쉐이크를 실시한다.
Sec-WebSocket-Key에는 핸드 쉐이크에 필요한 키가, Set-webSocket-Protocol에는 사용하는 서브 프로토콜이 저장되어 있으며, 서브 프로토콜은 WebSocket 프로토콜에 의한 커넥션을 여러 개로 구분하고 싶은 경우에 이름을 붙여 정의한다. 리퀘스트에 대한 리스폰스는 상태 코드 101 Switching Protocols 로 반환되며, Sec-WebSocket-Accpet는 Sec-WebSocket-Key의 값에서 생성된 값이 저장된다. 핸드 쉐이크에 의해 WebSocket 커넥션이 확립되면 HTTP가 아닌 WebSocket 독자적인 데이터 프레임으로 통신한다.

HTTP/2.0

차세대 HTTP로 SPDY, HTTP Speed+Mobility, Network-Friendly HTTP Upgrade 프로토콜이 베이스가 되어 사양이 검토되고 있다. 책의 경우 2012년 기준이며, 현재 기준은 다시 찾아보는 게 좋을 것 같다.

WebDAV(Web-based Distributed Authoring and Versioning)

웹 서버의 콘텐츠에 대해 직접 파일 복사나 편집 작업 등을 할 수 있는 분산 파일 시스템으로, 기본적인 기능 이외에도 파일 작성자 등의 관리나 편집 중 다른 유저가 고쳐 쓰지 못하도록 잠금 기능, 갱신 정보 관리의 리비전 기능 등이 있다.

여러 개의 리소스를 관리하는 컬렉션, 동시 작성을 예방하는 잠금 기능 등이 있으며 리모트 파일 관리를 위해 HTTP/1.1에 다음의 메소드가 추가되어 있다.

메소드	기능
PROFIND	프로퍼티 취득
PROPPATCH	프로퍼티 변경
MKCOL	컬렉션 작성
COPY	리소스 및 프로퍼티 복제
MOVE	리소스 이동
LOCK	리소스 잠금
UNLOCK	리소스 잠금 해제

메소드 확장에 맞춰 상태 코드도 확장되어 있다.

상태 코드	설명
102 Processing	리퀘스트는 정상적으로 수신되었지만 아직 처리 중이다.
207 Multi-Status	복수의 스테이터스를 가지고 있다.
422 Unprocessable Entity	서식은 올바르지만 내용이 틀리다.
423 Locked	리소스가 잠겨 있다.
424 Failed Dependency	어떤 리퀘스트와 관련된 리퀘스트가 실패했기 때문에 의존 관계를 유지할 수 없다.
507 Insufficient Storage	기억 영역이 부족하다.

10. 웹 컨텐츠에서 사용하는 기술

HTML(HyperText Markup Language)

HTML은 웹 상에서 하이퍼텍스트를 보내기 위해 개발된 언어로, 하이퍼텍스트는 문서 중에 임의의 장소의 정보가 다른 정보에 링크되어 있는 문서를, 마크 업 언어 는 문서의 일부에 특별한 문자열(HTML에서는 이를 HTML 태그라고 부름)을 붙임으로써 문서를 수식하는 언어를 의미한다.

웹 페이지의 대부분은 HTML이 사용되며 HTML로 쓰여진 문서를 브라우저가 해석해 렌더링 처리를 한 결과가 웹 페이지에 표시된다.

HTML의 각 요소를 어떻게 표시할 지 지시하는 것을 CSS(Cascading Style Sheets)라고 하며 CSS는 문서의 구조와 디자인을 분리한다는 이념에서 만들어졌다.

Dynamic HTML

다이나믹 HTML은 정적인 HTML을 JavaScript 등의 클라이언트 사이드 스크립트를 이용해 동적으로 변경하는 기술을 의미한다. 동적으로 바꾸고 싶은 HTML 요소를 지정하기 위해 이를 오브젝트로 다루는 DOM(Document Object Model) 구조를 사용하며, 이를 통해 요소 내의 문자열을 추출하는 등 HTML을 쉽게 조작할 수 있게 된다.

웹 애플리케이션

사전에 준비된 콘텐츠를 정적 콘텐츠, 프로그램에 의해 생성된 콘텐츠를 동적 콘텐츠라 부르는데, 웹 애플리케이션은 동적 콘텐츠에 해당한다.

CGI(Common Gateway Interface) 는 웹 서버가 클라이언트에서 받은 리퀘스트를 프로그램에 전달하기 위한 구조이다. CGI에 의해 프로그램은 리퀘스트 내용에 맞게 HTML을 생성하는 등 동적으로 콘텐츠를 생성하며, Perl, PHP, Ruby, C언어 등 CGI를 사용하는 프로그램을 CGI 프로그램이라고 한다. FRC3875 the Common Gateway Interface

서블릿(Servlet) 은 서버 상에 HTML 등의 동적 컨텐츠를 생성하기 위한 프로그램을 가리키며, Java 프로그래밍 언어 사양 중 엔터프라이즈 환경을 위한 JavaEE(Java Enterprise Edition)의 일부로 제공되고 있다.

CGI는 리퀘스트마다 프로그램을 기동하기 때문에 대량 엑세스에서는 웹 서버에 부하가 걸리게 되지만 서블릿은 웹 서버와 같은 프로세스 속에서 동작하므로 비교적 부하를 적게 하여 동작시킬 수 있다.

데이터 송신에 이용되는 포맷이나 언어

XML(eXtensible Markup Language)

XML은 목적에 맞게 확장 가능한, 범용적인 마크업 언어로, 인터넷을 통해 데이터 공유를 용이하게 할 수 있다. HTML과 같은 문서 기술 언어(SGML, Standard Generalized Markup Language)에서 파생되었으나 HTML에 비해 데이터 기술에 특화되어 있다. 태그를 사용한 트리구조이며 독자적으로 확장된 태그가 정의되어 있다. 파서 기능에 의해 데이터 추출이 쉽고 데이터 재사용성이 좋다.

RSS/Atom

갱신 정보를 송신하기 위한 문서 포맷의 총칭으로 XML을 이용한다.

JSON(JavaScript Object Notation)

경량 데이터 기술 언어로서 JavaScript에 있어서 오브젝트 표기법을 바탕으로 하고 있다. false/null/true/오브젝트/배열/수치/문자열 일곱 가지의 데이터형을 다룰 수 있으며, 데이터를 단순하고 가볍게 읽어올 수 있다는 장점이 있다. RFC4627 [The application/json Media Type for JavaScript Object Notation(JSON)]

11. 웹 공격 기술

HTTP 자체는 구조가 단순한 프로토콜이라 공격 대상이 되는 경우는 거의 없으나 HTTP를 사용하는 서버와 클라이언트, 서버 상에서 동작하는 웹 애플리케이션 등의 리소스는 공격 대상이 된다.

현재의 HTTP에는 보안 기능이 없으며 웹 애플리케이션에서 인증이나 세션 관리 기능을 개발자가 설계하고 구현할 필요가 있다. 제각각 설계하기 때문에 각기 다르게 구현되며 보안 등급이 충분하지 못하고 취약성 같은 버그가 있는 상태로 웹 애플리케이션이 가동되고 있기도 하다.

웹 애플리케이션이 브라우저로부터 수신한 HTTP 리퀘스트의 내용은 모든 클라이언트에서 자유롭게 변경하고 변조할 수 있기 때문에 웹 애플리케이션이 기대하는 값과는 다른 값이 보내질 가능성이 있다. 웹 애플리케이션에 대한 공격 패턴은 공격자가 직접 웹 애플리케이션에 액세스해 공격 코드를 보내는 능동적 공격(actice attack) 과 함정을 이용해 유저에게 공격 코드를 실행시키는 수동적 공격(passive attack) 이 있다. 수동적 공격은 주로 유저의 리소스나 권한을 공격하거나 유저가 처한 환경을 이용해 인트라넷을 공격한다.

취약성에 따른 공격 사례를 정리해보면 다음과 같다.

출력 값의 이스케이프 미비로 인한 취약성

웹 애플리케이션의 보안 대책을 실시하는 장소는 클라이언트/서버(입력값, 출력값 체크) 두 곳이다.

클라이언트 측에서는 대부분 JavaScript를 사용하나, 변조나 무효화될 가능성이 있어 근본적인 보안 대책으로는 적합하지 않고 입력 실수를 지적하는 UI 향상 정도로 사용하는 것이 좋다.

웹 애플리케이션 측의 입력값 체크 역시 웹 애플리케이션 내에서 처리 시 공격 코드로서 의미를 가질 수 있기 떄문에 근본적인 보안 대책으로는 적합하지 않으며 시스템 요건대로 된 값인지에 대한 체크나 문자 코드 체크 등을 실시하는 정도가 좋다.

결론적으로 웹 애플리케이션에서 처리한 데이터를 출력할 때, 출력 값의 이스케이프가 보안 대책으로 중요하다.

웹 서버의 설정이나 설계 미비

세션 관리 미비로 인한 취약성

세션 관리 기능이 취약한 경우 유저 인증 상태를 빼앗겨 버리는 피해가 발생된다.

기타

패스워드 크래킹(Password Cracking)

패스워드를 논리적으로 이끌어내 인증을 돌파한다. 네트워크 경유로 패스워드를 시행하거나 암호화된 프스워드를 해독하는 방법 등이 있다.

네트워크 경유의 경우 모든 후보를 시험해 인증을 돌파하는 무차별 대입 공격(Brute-force-Attack) 과 사전에 후보를 준비해둔 뒤 시험해보는 사전 공격(Dictionary Attack) 이 있다.

암호화된 패스워드를 해독하는 경우 무차별 대입공격/사전 공격에 의한 유추나, 평문과 해시 값으로 구성된 데이터베이스인 레인보우 테이블을 이용하거나, 열쇠 입수, 암호 알고리즘의 취약성 으로 데이터로부터 평문을 도출해낸다.

클릭 재킹(Click Jacking)

사용할 웹 페이지에 투명한 버튼이나 링크를 함정으로 심어두고 유저에게 클릭하게 해 의도하지 않은 콘텐츠에 액세스 시키는 공격이다.

DoS 공격 (Denial of Service attack)

서비스 제공을 정지 상태로 만드는 공격으로 다음과 같은 방식이 있다.

액세스를 집중시킴으로써 부하를 걸어 리소스를 다 소비하게 해 서비스를 정지 상태로 만든다.
취약성을 공격해 서비스를 정지시킨다.

특히 액세스를 집중시키는 공격은 정상적인 액세스와 구별이 어려워 방지하기 쉽지 않다. 여러 대의 컴퓨터에서 실행하는 DoS 공격은 DDoS(Distributed Denial of Servcie Attatck)이라고 부른다.

백도어(Backdoor)

제한된 기능을 정규 절차를 밟지 않고 이용하기 위해 설치한 뒷문을 의미한다. 본래 정해진 제한을 초과한 기능을 이용하는 것이 가능한데, 다음과 같은 종류가 있다.

개발 단계에 디버그용으로 추가한 백도어
개발자가 자신의 이익을 위해 추가한 백도어
공격자가 어떠한 방법을 써서 설치한 백도어

백도어용 프로그램이 설치된 경우, 프로세스나 통신을 감시해 발견이 가능하나 웹 애플리케이션을 수정해 설치한 백도어는 정상 이용과 구별이 어려워 발견하기 쉽지 않다.

드디어 모든 내용 정리 끗…

객사오는 한 챕터씩 올렸어서 그런가 이렇게 힘들지 않았던 것 같은데 한번에 방대한 양을 정리하려다 보니 책 읽은 시간에 비해 훨씬 더 많은 시간이 소요됐다.

정리하기 전에는 쿠키와 캐시도 헷갈렸고 암호화 방식이나 웹 공격 기술, 상태 관리 부분에 대해 이해도가 부족하다고 적어두었는데 정리하며 두세번 정독하다 보니 해결 완.

강의 리뷰해둔 것도 다시 한번 읽어 봐야겠다.

책에 담긴 내용을 간략히(?) 모아보면 이렇습니다!

Book, 그림으로 배우는 Http&Network Basic

Book 그림으로 배우는 Http&Network Basic

This post is licensed under CC BY 4.0 by the author.