HTTP·HTTPS·쿠키·세션 | 정보보안기사 필기

1. HTTP는 요청과 응답으로 동작한다

HTTP(Hypertext Transfer Protocol)는 클라이언트가 요청(request)을 보내고 서버가 응답(response)을 반환하는 응용 계층 프로토콜이다.

요청에는 보통 다음 정보가 들어간다.

메서드(method): 어떤 동작을 원하는지 나타낸다.
대상(target): 어떤 자원에 요청하는지 나타낸다.
헤더(header): 호스트, 콘텐츠 형식, 인증·상태 정보 등 부가 정보를 전달한다.
본문(content/body): 필요할 때 실제 데이터가 들어간다.

응답에는 보통 다음 정보가 들어간다.

상태 코드(status code): 처리 결과의 종류를 나타낸다.
응답 헤더: 콘텐츠 형식, 캐시, 쿠키 설정 등 부가 정보를 전달한다.
응답 본문: HTML, JSON, 이미지 등 실제 결과 데이터가 들어갈 수 있다.

간단한 요청과 응답 예시

HTTP코드 영역 안에서 좌우로 이동할 수 있습니다.

GET /account/orders HTTP/1.1
Host: shop.example
Cookie: SID=7f3c...a91
Accept: text/html

HTTP코드 영역 안에서 좌우로 이동할 수 있습니다.

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-store

이 예시에서 Cookie 헤더는 브라우저가 이전에 받은 상태 정보를 다시 서버로 전달하는 지점이다.

2. HTTP 메서드는 동작의 의미를 표현한다

대표적인 메서드는 다음과 같다.

메서드	기본 의미	보안에서 주의할 점
GET	자원의 현재 표현을 조회	조회 요청에 민감한 변경 동작을 넣지 않는 것이 중요
HEAD	GET과 같지만 응답 본문은 전달하지 않음	정보 노출·서버 동작 점검 시 메서드 허용 범위를 확인
POST	요청 내용을 서버가 목적에 맞게 처리	입력 검증, 인증·인가, CSRF 방어가 중요
PUT	대상 자원의 표현을 요청 내용으로 생성·교체	쓰기 권한과 객체 인가를 확인
DELETE	대상 자원 제거	강한 인가와 요청 정당성 확인 필요
OPTIONS	통신 옵션 확인	불필요한 기능·허용 메서드 노출 여부 확인

메서드 이름 자체가 접근 권한을 보장하지는 않는다. 서버는 어떤 메서드가 오더라도 현재 사용자가 그 자원과 동작을 수행할 권한이 있는지 별도로 검사해야 한다.

3. 상태 코드는 처리 결과의 범주를 알려 준다

HTTP 상태 코드는 첫 자리로 큰 범주를 구분한다.

1xx: 처리 중인 정보성 응답
2xx: 요청 성공
3xx: 리다이렉션·캐시 재검증 등 요청을 완료하기 위한 추가 동작
4xx: 클라이언트 요청 측 오류
5xx: 서버 처리 오류

예를 들어 200 OK는 성공, 401 Unauthorized는 인증이 필요하거나 인증 정보가 유효하지 않은 상황에 사용되고, 403 Forbidden은 서버가 요청을 이해했지만 접근을 허용하지 않는 상황에 사용된다. 404 Not Found는 대상 자원을 찾지 못했음을 뜻한다.

상태 코드만으로 내부 원인을 전부 알 수 있는 것은 아니다. 운영에서는 상태 코드, 애플리케이션 로그, 웹 서버 로그, DB 상태 등을 함께 보며 어느 단계에서 실패했는지 구분한다.

4. HTTP가 상태 비저장이라는 뜻

HTTP에서는 각 요청이 원칙적으로 독립적으로 해석될 수 있다. 서버가 아무 추가 장치도 두지 않는다면 이전 요청의 사용자가 누구였는지 다음 요청만 보고 자동으로 연결할 수 없다.

하지만 쇼핑몰은 다음 정보를 이어서 기억해야 한다.

로그인한 사용자
장바구니
선택한 언어
진행 중인 결제 단계

이때 브라우저에 작은 상태 값을 저장하는 쿠키(cookie)와, 서버가 로그인 상태를 관리하는 세션(session)을 결합하는 방식이 많이 사용된다.

5. 쿠키는 브라우저가 보관하고 요청에 실어 보내는 값이다

서버는 응답의 Set-Cookie 헤더를 통해 브라우저에 쿠키를 저장하도록 지시할 수 있다.

HTTP코드 영역 안에서 좌우로 이동할 수 있습니다.

Set-Cookie: SID=7f3c...a91; Path=/; Secure; HttpOnly; SameSite=Lax

이후 조건이 맞는 요청에서 브라우저는 해당 값을 Cookie 헤더에 포함해 전송한다.

HTTP코드 영역 안에서 좌우로 이동할 수 있습니다.

Cookie: SID=7f3c...a91

쿠키에 실제 사용자 비밀번호나 서버 내부 권한 정보를 그대로 저장해야 하는 것은 아니다. 세션 방식에서는 보통 추측하기 어려운 세션 식별자(session ID)만 브라우저에 두고, 실제 로그인 상태와 권한 같은 정보는 서버 측 세션 저장소에서 관리한다.

6. 쿠키 속성이 보호하는 범위를 구분한다

6.1 Secure

Secure 속성이 붙은 쿠키는 브라우저가 HTTPS 연결을 통해서만 전송하도록 제한한다. 세션 쿠키가 평문 HTTP 통신으로 노출되는 위험을 줄이는 데 중요하다.

6.2 HttpOnly

HttpOnly는 브라우저의 일반적인 클라이언트 스크립트가 해당 쿠키 값을 읽지 못하게 제한한다. XSS가 발생했을 때 document.cookie 같은 방식으로 세션 쿠키 값을 직접 훔치는 위험을 줄일 수 있다.

그러나 HttpOnly가 XSS 자체를 제거하는 것은 아니다. 악성 스크립트가 브라우저 안에서 사용자의 권한으로 요청을 보내는 등 다른 피해는 여전히 가능할 수 있다.

6.3 SameSite

SameSite는 다른 사이트에서 시작된 요청에 쿠키를 어느 범위까지 자동 첨부할지 제한하는 속성이다.

Strict: 교차 사이트 상황에서 가장 강하게 제한한다.
Lax: 일부 상위 수준 탐색 등 제한된 경우를 허용한다.
None: 교차 사이트 전송을 허용하는 용도이며 현재 브라우저 환경에서는 보통 Secure와 함께 사용한다.

SameSite는 CSRF 위험을 낮추는 데 도움이 되지만, 애플리케이션의 상황에 따라 CSRF 토큰 같은 별도 검증이 여전히 필요하다. 따라서 “SameSite만 설정하면 모든 CSRF가 해결된다”고 외우면 안 된다.

6.4 Domain과 Path

Domain과 Path는 쿠키가 어느 호스트와 경로 범위에 전송될지를 조절한다. 범위를 불필요하게 넓히면 더 많은 요청과 하위 영역에 세션 값이 노출될 수 있으므로 필요한 범위만 지정한다.

7. 세션은 서버가 사용자 상태를 연결하는 방식이다

일반적인 서버 측 세션 방식은 다음과 같이 동작한다.

사용자가 ID와 비밀번호 등으로 인증을 시도한다.
인증에 성공하면 서버는 새로운 세션 상태를 만든다.
서버는 세션과 연결된 예측하기 어려운 세션 ID를 브라우저에 전달한다.
브라우저는 다음 요청에 세션 ID를 포함한다.
서버는 세션 ID로 서버 측 상태를 찾아 사용자를 식별한다.
각 요청마다 기능·객체에 대한 인가를 별도로 확인한다.
로그아웃이나 만료 시 서버 측 세션을 무효화한다.

세션 ID는 비밀번호 자체는 아니지만, 유효한 세션 ID를 탈취한 공격자가 피해자의 로그인 상태를 재사용할 수 있다면 사실상 인증 결과를 가로챈 것과 비슷한 문제가 된다.

8. HTTPS는 HTTP를 TLS로 보호한다

HTTPS는 별도의 새로운 애플리케이션 의미를 만드는 프로토콜이라기보다 HTTP 통신을 TLS로 보호하여 전송하는 방식으로 이해하면 된다.

TLS가 제공하는 핵심 보호 목표는 다음과 같다.

기밀성: 통신 내용이 제3자에게 그대로 노출되는 위험을 줄인다.
무결성: 전송 중 데이터가 몰래 바뀌는 것을 탐지할 수 있게 한다.
상대 인증의 기반: 일반적인 웹에서는 서버 인증서를 이용해 접속 대상의 신원을 검증한다.

다만 TLS는 서버 내부의 잘못된 인가 로직, SQL 삽입, XSS, 취약한 세션 생성 같은 애플리케이션 자체의 결함을 수정하지 않는다.