[애플리케이션 기본학습] HTTP 프로토콜

HTTP
(Hyper Text Transfer Protocol)

 

① 개념

• HTTP 프로토콜 : *웹상에서 클라이언트와 서버 간에 통신을 위해 개발된 프로토콜
  • 웹(Web) : 월드 와이드 웹(WWW:World Wide Web)으로 전세계에 거미줄처럼 연결된 망이라는 의미
  • 다양한 하이퍼텍스트 문서들이 웹상에서 서로 연결되어 있다. 하이퍼텍스트 문서란 참조 혹은 링크를 통해 한 문서에서 다른 문서로 접근할 수 있는 문서를 말한다. 대표적인 하이퍼텍스트 문서로 HTML(Hyper Text Markup Language)이 있다.
  • 주로 80/tcp 포트를 사용하며 HTTP 통신은 클라이언트 요청과 서버의 응답으로 이루어져 있다.

• 비연결형 프로토콜 
  • HTTP/1.0 버전까지는 클라이언트의 HTTP 요청에 대한 서버의 HTTP 응답 이후에 TCP 연결을 바로 종료하는 구조로 동작한다. 연결을 바로 종료하는 이유는 제한된 서버 연결 자원을 이요하여 최대한 많은 클라이언트의 요청을 처리하기 위함이며, 서버입장에서는 통신을 위한 다수의 TCP 연결 설정 및 종료에 대한 부하가 있다.
  • HTTP/1.1 버전부터 Connection 헤더에 Keep-Alive 옵션이 추가되었다. 이는 TCP 연결 상태를 웹서버 설정에 따라 일정 시간 지속시키는 옵션으로 한번의 연결 이후에 요청/응답을 반복할 수 있다.
    • HTTP 응답 메시지를 분석해보면 일반적으로 이밎, 스크립트 등 다수의 추가 자원 요칭이 발생한다. 따라서 TCP 연결 설정 및 종료에 대한 부하를 줄이면서 효율적으로 클라이언트 요청을 처리하기 위해 연결 상태를 일정 시간 유지하는 옵션이 추가되었다.
    • 최초 클라이언트 요청 시 웹서버는 Connection 응답헤더에 Keep-Alive 옵션을 설정하고 Keep-Alive 응답 헤더에 추가 옵션을 설정한다. (ex. Keep-Alive: timeout=15, max=100 -> 연결 지속시간 :15초, 지속시간동아 허용된 최대요청건수:100건)
    • 아파치 웹서버 설정 파일(httpd.conf)의 Keep-Alive 관련 설정을 살펴보면 다음과 같다.
    • # Keep-Alive 설정
      KeepAlive On                # Keep-Alive를 활성화하려면 On, 비활성화하려면 Off로 설정
      
      # Keep-Alive를 활성화한 경우 추가 설정:
      MaxKeepAliveRequests 100    # 하나의 연결에서 허용할 최대 요청 수 (기본값 100)
      KeepAliveTimeout 15          # Keep-Alive 연결이 유지될 최대 시간 (초 단위, 기본값 5초)
• 상태정보를 유지하지 않는(Stateless) 프로토콜
  • 상태정보를 유지하지 않는다는 것은 동일 클라이언트의 현재 요청과 이전 요청을 식별하지 못한다는 의미이다. (현재 연결에 대한 클라이언트의 어떤 상태정보도 유지하지 않음)
  • 서비스 특성상 클라이언트의 상태정보 유지가 필요할 수 있는데 대표적으로 쇼핑몰의 장바구니 기능,로그인 상태 유지 등이 있다.
  • 이 유지를 위한 클라이언트 기술로 '쿠키'와 서버기술로 '세션'이 있다.

 

② 클라이언트 상태정보 유지 기술

1. 쿠키(Cookie) 방식 : 개별 클라이언트 상태정보를 HTTP 요청/응답헤더에 담아서 전달하는 작은 정보/데이터를 통해 정보 유지
   • 서버에서 "Set-Cookie 응답헤더"를 통해 쿠키를 설정하여 클라이언트로 전달하면 클라이언트는 "Cookie 요청헤더"를 이용해 지속해서 쿠키를 전달하는 형태로 동작한다.
   • 지속시간에 따른 구분
     • 영속쿠키 : 클라이언트에 파일형태로 지속해서(또는 일정 기간동안) 존재하는 쿠키. 쿠키에 설정된 사이트 요청 시마다 Cookie 요청헤더에 쿠키 정보를 담아 전달.
     • 세션 쿠키 : 클라이언트 메모리상 세션이 유지되는 동안 존재하는 쿠키. 세션이 종료되면 소멸.
   • 보안 취약점
     • 쿠키 방식은 클라이언트 상태정보를 클라이언트에 저장하고 HTTP 요청/응답 헤더에 담아서 전달하기 때문에 해킹,스니핑 공격에 의한 변조와 외부 노출에 매우 취약하다. 따라서, 중요정보를 저장할 경우에는 쿠키 방식이 아니라 세션 방식이 안전하며, 쿠키를 사용해야 할 경우에는 암호화를 적용해야한다.
2. 세션(Session) 방식 :: 개별 클라이언트 상태정보를 서버에 저장해 정보 유지
   • 서버는 개별 클라이언트 세션을 식별하기 위해 "세션ID(Session ID)"를 클라이언트에 부여하고, 세션 ID는 세션 쿠키를 이용해 클라이언트와 서버 간 주고받는다.
   • 클라이언트 상태정보를 서버에 저장하기 때문에 쿠키 방식에 비해 보안상 안전하다.
   • (HTTP 세션 하이재킹) 만약 공격자가 정상적인 사용자의 세션 ID 정보를 탈취한다면 정상 사용자로 위장한 접근이 가능하다. 

 

③ HTTP 쿠키 관련 보안 속성

1. httponly 속성 : 클라이언트에서 스크립트를 통해 해당 쿠키게 접근하는 것을 차단해주는 속성
   • "Set-Cookie 응답헤더" 에 설정하는 속성
   • HTTP 헤더에 값을 추가할 경우, 세미콜론(;)을 구분자로 추가한다.
   • 일반적으로 세션ID를 저장하고 있는 세션 쿠키를 탈취하기 위한 XSS(Cross SIte Script) 공격에 대응하기 위해 사용
2. secure 속성 : 클라이언트에서 HTTPS(SSL/TLS) 통신일 경우에만 해당 쿠키를 전송하고 HTTP 통신일 경우에는 전송하지 않는 속성
   • "Set-Cookie 응답헤더" 에 설정하는 속성
   • (기밀성) 전송 중에 평문 쿠키가 노출되는 것을 방지하기 위한 목적

 

④ HTTP 요청 메시지

HTTP 요청 메시지 구조

1. 구문 형식
   • 요청 라인 : 한 행으로 구성되며 요청 메소드, 요청 URL, HTTP 버전 정보를 갖고 있다
     
     • <공백> : (띄어쓰기) 아스키코드 핵사값 '0x20'
     • <개행> : (줄바꿈) 아스키코드 핵사값 '0x0d0a' 제어문자로 'CLRF'
   • 요청 헤더 :  여러 헤더로 구성되며 각각의 헤더 정보는 개행으로 구분한다.
     • [주요 헤더 정보]
     • Host : 요청 대상이 되는 서버의 도메인명/호스트 명, 포트정보
     • User-Agent : 요청 클라이언트 애플리케이션/OS 정보
     • Referer : 현재 요청 URL 정보를 담고 있는 이전 문서의 URL 정보
   • 빈 라인 : 헤더의 끝을 의미한다. 헤더 크기는 가변이기 때문에 이 표시로 헤더의 끝을 식별
   • 요청 메시지 바디 : 클라이언트 -> 서버로 보내는 데이터를 담는 부분
     • GET 방식의 경우 요청데이터가 없으므로 메시지 헤더가 없음
2. 주요 요청 메소드
   
   • GET : 요청 URL로 지정한 자원을 서버에 요청하는 메소드
     • 요청 메시지 바디가 없으며 필요시 쿼리스트링을 이용해 제한된 데이터 전송이 가능
     • 쿼리스트링 : 요청 URL 끝에 추가해 데이터를 전달하는 방식 (ex. www.example.com?id=holly&pwd=horse)
       •  ? : 쿼리스트링 식별자, param=value: 파라미터명 = 파라미터값, & : 각 파라미터 구분자
       • 중요정보(ID/PWD 등)를 GET 방식의 쿼리스트링으로 전달하는 것은 주소창에 정보가 쉽게 노출되고 서버 엑세스 로그 상에 그대로 남아 매우 매우 보안상 취약하다.
   • POST : 요청 URL로 지정한 자원에 데이터를 전달하며, 처리 결과를 서버에 요청하는 메소드
     • 요청 메시지 바디가 있다.
   • (취약)PUT : 요청 메시지 바디에 포함되어 있는 데이터를 요청 URL로 지정한 자원으로 저장하도록 하는 메소드
   • (취약)DELETE : 요청 URL로 지정한 자원을 서버에서 삭제하도록 하는 메소드
   • (취약)HEAD : GET 메소드와 유사하게 요청하지만 서버 응답시에 응답 메시지 바디를 제외하고 헤더부분만 답해주는 메소드
     • 요청자원에 대한 처리는 서버에서 이루어지지만 결과로 헤더값만 전송
     • 검색엔진에서 URL/링크의 유효성을 검증하기 위한 목적으로 사용
   • (취약)OPTIONS : 서버가 지원하는 메소드를 확인하는 목적으로 사용하는 메소드
     • Allow 응답 헤더를 통해 웹서버에서 지원하는 메소드 정보를 전달 (ex. Allow : GET, HEAD)
   • (취약)CONNECT : 클라이언트와 서버간에 터널링 목적으로 사용하는 메소드
     • 웹 서버가 프록시 역할을 수행 

 

⑤ HTTP 응답 메시지

HTTP 응답 메시지 구조

1. 구문 형식
   • 상태 라인 : 한 행으로 구성되며 HTTP 버전 정보, 상태 코드, 응답구문을 갖고 있다
   • 응답 헤더 :  여러 헤더로 구성되며 각각의 헤더 정보는 개행으로 구분한다.
     • [주요 헤더 정보]
     • Content-Type : 메시지 바디의 데이터 형식을 설정
     • Content-Length : 메시지 바디의 전체 크기를 설정(단위: byte)
   • 빈 라인 : 헤더의 끝을 의미한다. 헤더 크기는 가변이기 때문에 이 표시로 헤더의 끝을 식별
   • 응답 메시지 바디 : 서버 -> 클라이언트로 보내는 데이터를 담는 부분
2. 주요 상태 코드

응답	상세 코드	설명
1xx: information (정보)	100	Continue : 클라이언트한테 요청을 받았으나 나머지 정보 계속 달라고 요청
2xx: Success (성공)	200	OK : 요청이 성공적으로 수행
	201	Created : PUT 메소드에 의해 원격 서버에 파일이 생성됨
	202	Accepted : 웹 서버가 명령 수신
3xx: Redirection (요청 자원 위치 재지정)	301	Moved Permanetly : 요청 자원의 위치가 영구적으로 변경되었으며, Location 응답 헤더를 통해 변경된 URL 정보 전달
	302	Found : 요청 자원의 위치가 임시적으로 변경되었으며, Location 응답 헤더를 통해 변경된 URL 정보 전달
	303	Not Modified : 요청한 자원이 변경되지 않았으므로 클라이언트 로컬 캐시에 저장된 자원을 이용하라는 의미
4xx : Client error (클라이언트 오류)	400	Bad Request : 요청 메시지 문법 오류
	401	Unauthorized  : 요청 자원을 실행하는데 필요한 권한이 없음을 의미. (자원에 대한 인가가 필요)
	403	Forbidden  : 요청한 자원에 대한 접근 차단
	404	Not Found  : 요청한 자원이 존재하지 않음
5xx : Server Error (서버 오류)	500	Internal Server Error  : 내부 서버 오류