HTTP는 원래 단순 문서 전송을 목적으로 설계되었기 때문에 보안(Security) 측면에서 많은 약점을 가지고 있다. 특히 웹이 전자상거래, 금융 서비스, 개인정보 처리에 쓰이면서 안전한 데이터 전송, 사용자 인증, 접근 제어, 무결성 보장, 프라이버시 보호가 필수 요구사항이 되었다. 이번 장에서는 HTTP가 직면한 보안 위협과 이를 해결하기 위한 핵심 메커니즘을 정리한다.
HTTP의 보안 위협
HTTP 자체는 평문 텍스트 전송을 기본으로 하기 때문에 다음과 같은 위협에 노출된다.
1. 도청(Eavesdropping)
HTTP는 암호화나 무결성 검증이 없는 평문 프로토콜이기 때문에 네트워크 환경에 그대로 노출된다.
도청(Eavesdropping)은 가장 흔한 위협으로 중간 공격자가 패킷을 캡처하기만 해도 로그인 자격 증명이나 세션 쿠키가 그대로 드러난다. 이는 공용 Wi-Fi 환경에서 흔히 발생할 수 있다.
변조(Tampering)는 트래픽을 가로채어 내용을 수정하는 공격으로 예를 들어 상품 결제 금액을 고의로 바꾼다거나 응답 본문에 악성 스크립트를 삽입할 수 있다.
위조(Forgery)는 신원을 속이는 행위다. 피싱 사이트는 은행의 UI를 그대로 복제해 사용자를 속이고 공격자는 합법 서버로 가장하여 민감한 정보를 탈취한다.
재전송 공격(Replay Attack)은 합법적인 요청을 캡처 후 동일하게 다시 전송하는 방식으로 동일 결제가 반복 처리되거나 로그인 요청이 강제로 재시도될 수 있다.
이러한 공격은 “HTTP는 신뢰할 수 있는 전송”이라는 가정 하에 설계된 태생적 한계에서 비롯된다.
HTTP 보안의 목표
HTTP 보안은 크게 네 가지 목표를 가진다.
- 기밀성(Confidentiality) – 제3자가 메시지 내용을 읽을 수 없도록 암호화하는 것이다. 이는 TLS 같은 전송 계층 보안을 통해 구현된다.
- 무결성(Integrity) – 전송 중 데이터가 변조되지 않았음을 보장하는 것으로 MAC(Message Authentication Code) 또는 해시 기반 검증이 필요하다.
- 인증(Authentication) – 상대방이 주장하는 신원이 맞는지를 확인하는 과정이다. 서버 인증은 피싱 사이트 차단에 클라이언트 인증은 사용자 권한 제어에 필요하다.
- 부인 방지(Non-repudiation) – 통신 이후 당사자가 “그런 요청을 한 적이 없다”고 주장하지 못하도록 증거를 남기는 기능이다. 보통 전자 서명과 로그 저장으로 달성된다.
HTTP 보안 요소
1. HTTPS (HTTP over SSL/TLS)
HTTPS는 HTTP를 안전하게 만드는 가장 중요한 방법이다. 동작 과정은 다음과 같다.
- 클라이언트가
ClientHello메시지로 지원 가능한 암호화 알고리즘 목록과 난수 값을 전송한다. - 서버는
ServerHello와 함께 서버 인증서(공개키 포함) 를 보낸다. 인증서는 CA가 서명했기 때문에 브라우저가 신뢰성을 검증할 수 있다. - 클라이언트는 인증서를 검증한 후 서버 공개키로 대칭 세션 키를 암호화하여 전송하거나(ECDHE라면 키 교환 수행) 키 합의를 진행한다.
- 최종적으로 세션 키가 합의되면 이 키로 모든 HTTP 데이터를 암호화한다.
이를 통해 통신은 도청 불가(암호화), 변조 탐지(무결성 검증), 서버 신원 검증(인증서)이 보장된다.
Client → Server: ClientHello (지원 암호화 알고리즘 목록)
Server → Client: ServerHello + 인증서(공개키)
Client → Server: 대칭키를 공개키로 암호화해 전송
[Handshake 완료 후 암호화된 HTTP 데이터 교환]2. HTTP 인증(Authentication)
HTTP 레벨에서 제공하는 인증 방식은 다음과 같다.
-
Basic 인증은 가장 단순하며
username:password를 Base64로 인코딩해 전송한다. 암호화되지 않은 네트워크에서는 사실상 평문과 동일하다. -
Digest 인증은 서버가 전달한 nonce와 요청 URI, 메서드, 사용자 자격 증명을 조합해 MD5 해시를 계산한 값을 보낸다. 이를 통해 패스워드를 직접 노출하지 않는다. 그러나 MD5의 보안 한계와 구현 복잡성으로 인해 잘 쓰이지 않는다.
-
NTLM, Kerberos 같은 환경 특화 인증은 기업 내 Windows 기반 시스템에서 사용된다.
-
현대 웹 서비스는 HTTP 자체 인증 대신 TLS 위에서 세션 쿠키, JWT, OAuth 2.0 같은 상위 계층 인증 방식을 조합하는 것이 일반적이다.
3. 메시지 무결성
HTTP는 예전에는 Content-MD5 헤더를 통해 응답 본문에 대한 해시를 제공했지만 MD5의 취약성과 중간 처리 과정(압축, 인코딩 등) 때문에 신뢰할 수 없었다. 현재는 TLS 레코드 계층에서 MAC이나 AEAD(GCM, ChaCha20-Poly1305 등)를 사용해 무결성을 보장한다. 또한 금융 거래처럼 중요한 경우에는 애플리케이션 계층에서 별도의 디지털 서명을 적용해 데이터가 종단 간으로 위조되지 않았음을 증명하기도 한다.
4. 암호화
암호화는 두 가지 수준에서 적용된다.
-
전송 계층 암호화는 HTTPS를 통해 클라이언트와 서버 사이 트래픽 전체를 보호한다.
-
메시지 계층 암호화는 본문 자체를 암호화하는 방식이다. 이메일에서는 S/MIME, PGP 같은 기법이 사용되며 웹 API에서는 JSON Web Encryption(JWE)이 활용되기도 한다.
실제 서비스에서는 TLS를 통한 전송 보안 + 저장 시 데이터베이스 암호화를 병행하여 전송 구간과 저장 구간 모두를 안전하게 만든다.
5. 프록시와 보안
프록시와 캐시, 게이트웨이는 웹 아키텍처에서 자주 등장한다. HTTPS 환경에서는 클라이언트가 프록시에게 CONNECT 메서드로 원 서버와의 터널을 요청한다. 프록시는 단순히 TCP 바이트 스트림만 전달하고 이후 TLS 핸드셰이크는 클라이언트와 서버가 직접 수행한다. 이렇게 하면 프록시는 암호화된 내용을 볼 수 없다. 하지만 기업 환경에서는 TLS 가시성 프록시를 두어 중간에서 복호화 후 다시 암호화하는 경우도 있다. 이는 내부 보안 감사에는 유용하지만 사용자의 프라이버시 측면에서는 주의가 필요하다.
6. 보안 관련 HTTP 헤더
현대 웹 보안은 HTTPS만으로 충분하지 않으며, 브라우저 보안 헤더로 취약점을 보완해야 한다.
-
Strict-Transport-Security (HSTS): 브라우저가 해당 도메인에 반드시 HTTPS로만 접속하게 하여 다운그레이드 공격을 방지한다. -
X-Frame-Options: 페이지가 다른 사이트의 iframe에 포함되지 못하게 하여 클릭재킹 공격을 막는다. -
X-Content-Type-Options: nosniff: 브라우저가 MIME 타입을 추측하지 않고 서버가 제공한 타입만 사용하게 한다. -
Content-Security-Policy (CSP): 스크립트와 리소스 로딩 출처를 강력히 제어하여 XSS 공격을 근본적으로 줄인다. -
Set-Cookie속성:Secure,HttpOnly,SameSite속성을 설정해 세션 탈취와 CSRF를 방지한다.
📝 배운점
HTTP 보안은 단순히 데이터를 암호화하는 문제가 아니라 위협 모델에 맞춘 다층적인 대응이 필요하다는 점을 배웠다. HTTPS는 기본적으로 기밀성과 무결성을 제공하고 서버 신원을 검증하지만 여기에 그치면 부족하다. 사용자 인증은 TLS 위에서 안전하게 수행되어야 하며 메시지 무결성을 강화하려면 애플리케이션 레벨 서명까지 고려할 수 있다. 또한 현대 브라우저가 제공하는 보안 헤더와 쿠키 속성은 XSS, CSRF, 클릭재킹 같은 현실적 공격을 막는 데 필수적이다.
결국 보안은 한 가지 기술로 완성되지 않고 전송 계층(TLS) + 애플리케이션 인증/무결성 + 브라우저 보안 정책이 유기적으로 맞물려야 한다. 이 장을 통해 “HTTPS를 쓰면 안전하다”는 단순한 결론이 아니라 HTTPS 위에 정책·헤더·인증·운영 관리가 함께 쌓여야 비로소 안전한 웹이 된다는 것을 다시 한 번 확인했다.
