웹 보안과 통신 구조

1. 쿠키(Cookie)란?

HTTP는 Stateless(무상태) 프로토콜입니다.

즉, 서버는 요청을 보낸 사람이 이전에도 요청을 보낸 사람인지를 기억하지 못합니다.

하지만 웹 서비스는 로그인 상태 유지, 장바구니 유지 등 기억하는 기능이 필요합니다.

이런 상태를 유지하기 위해 사용하는 것이 바로 쿠키입니다.

1-1. 쿠키의 기본 개념

쿠키는 브라우저에 저장되는 작은 데이터 조각입니다.

1. 서버가 응답을 보낼 때 Set-Cookie 헤더를 통해 쿠키를 내려보냅니다.
2. 브라우저는 이 쿠키를 로컬에 저장합니다.
3. 브라우저는 같은 서버로 요청을 보낼 때 자동으로 Cookie 헤더에 쿠키를 담아 전송합니다.
4. 서버는 이 쿠키를 보고 어떤 사용자로부터 온 요청인지 등을 파악할 수 있습니다.

// 예시 응답 헤더
Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure

1-2. 쿠키의 주요 속성들

쿠키에는 여러 가지 중요한 속성들이 있습니다.

• Domain: 어느 도메인에 이 쿠키를 전송할지 결정합니다.
• Path: 어느 경로(URL)에서 이 쿠키를 전송할지 결정합니다.
• Expires/Max-Age: 쿠키의 유효 기간을 설정합니다.(브라우저를 닫아도 유지할지, 세션이 끝나면 삭제할지 등)
• Secure: https 연결에서만 쿠키를 전송하도록 강제합니다.
• HttpOnly: 자바스크립트에서 document.cookie로 쿠키에 접근하지 못하게 합니다. → xss 공격으로 쿠키가 탈취되는 것을 방지

---

2. SameSite 속성

SameSite는 CSRF 같은 공격을 줄이기 위해 도입된 쿠키 속성입니다.

쿠키를 어떤 상황에서 브라우저가 자동으로 전송할지를 제어하는 옵션입니다.

2-1. SameSite 옵션 종류

1. SameSite=Strict
   • 완전히 같은 사이트에서만 쿠키를 전송합니다.
   • 다른 사이트에서 링크를 타고 들어올 경우 쿠키를 보내지 않습니다.
   • 보안은 가장 강하지만 UX가 불편해질 수 있습니다.
2. SameSite=Lax
   • 기본값으로 많이 사용됩니다.
   • GET 방식의 일반적인 내비게이션(링크 클릭, 주소창 입력 등)에서는 쿠키를 전송합니다.
   • 하지만 대부분의 cross-site POST 요청 등은 쿠키를 전송하지 않습니다.
3. SameSite=None; Secure
   • 어떤 출처에서 오든지 쿠키를 전송하겠다는 의미입니다.
   • 단, 이 경우 반드시 Secure(https 전용)가 함께 있어야 합니다.
   • ex) 프론트 백엔드가 도메인이 다른 경우, 외부 도메인에서 공통 로그인 등을 사용할 때 등

---

3. CSFR(Cross-Site Request Forgery)

3-1. CSFR이란?

CSFR은 간단히 말하면 사용자의 브라우저를 속여서, 사용자가 의도하지 않은 요청을 다른 사이트에 보내게 만드는 공격입니다.

3-2. CSRF 공격 시나리오 예시

1. 사용자가 A은행 사이트에 로그인합니다. → 브라우저에 sessionId 쿠키가 저장됩니다.
2. 사용자는 로그아웃하지 않고, 다른 탬에서 악성 사이트 B에 접속합니다.
3. 악성 사이트에는 다음과 같은 코드가 숨어 있습니다.

<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="to" value="공격자_계좌">
  <input type="hidden" name="amount" value="1000000">
</form>

<script>
  document.forms[0].submit();
</script>

1. 사용자의 브라우저는 https://bank.com/transfer로 요청을 보내면서 자동으로 은행의 세션 쿠키를 포함합니다.
2. 은행 서버 입장에서는 정상 로그인된 사용자의 요청처럼 보일 수 있습니다.

⇒ 사용자가 클릭하지도 않았는데 돈이 빠져나갈 수 있는 상황입니다.

3-3. CSRF 방어 방법

1. CSRF Token 사용 (가장 대표적인 방법)
   • 서버가 폼이나 페이지를 내려줄 때 CSRF Token을 함께 내려보냅니다.
   • 이 토큰은 예측하기 어려운 랜덤값입니다.
   • 클라이언트는 요청 시 이 토큰을 같이 전송합니다.
   • 서버는 세션에 저장된 토큰 값과 요청에 담긴 토큰 값이 일치하는지 확인합니다.
   • 악성사이트는 이 토큰 값을 알 수 없어 공격이 어려워집니다.
2. SameSite 쿠키 활용
   • 세션 쿠키에 SameSite=Lax 또는 Strict를 설정하면 다른 사이트에서 발생한 요청에 쿠키가 전송되지 않도록 막을 수 있습니다.
   • 이 경우, 외부에서 만들어진 POST 요청 등은 세션 쿠키 없이 도착하므로, 서버에서 인증되지 않은 요청으로 처리할 수 있습니다.
3. 중요한 요청은 사용자 재확인 절차 추가
   • 비밀번호 변경, 송금, 결제, 탈퇴 등 중요한 작업일 경우 비밀번호 재입력이나 추가 인증 등을 요구하여 공격 난이도를 높입니다.

---

4. XSS(Cross-Site Scripting)

4-1. XSS란?

XSS는 간단히 말하자면, 공격자가 웹 페이지 안에 악성 스크립트를 심어 두고, 그 페이지를 본 사용자의 브라우저에서 스크립트를 실행시키는 공격입니다.

사용자의 쿠키를 탈취하거나, 악성 사이트로 리다이렉트, 피싱 페이지로 이동 등 위험이 발생할 수 있습니다.

4-2. XSS 종류

1. Strored XSS (저장형)
   • 악성 스크립트가 서버 DB에 저장됩니다.
   • ex) 게시글, 댓글, 프로필 소개 등
   • 해당 데이터를 읽는 모든 사용자가 피해자가 됩니다.
2. Reflected XSS(반사형)
   • 악성스크립트가 URL 파라미터 등에 담겨 요청됩니다.
   • 서버가 이것을 다시 응답페이지에 그대로 반영하면 실행됩니다.
   • 보통 특정 링크를 클릭한 사용자가 피해자가 됩니다.
3. DOM 기반 XSS
   • 서버 응답 자체는 안전하지만, 프론트엔드 자바스크립트 코드가 DOM을 조작하는 과정에서 사용자 입력을 제대로 검증하지 않을 경우 발생합니다.

4-3. XSS 방어 방법

1. 출력 시 Escape / Encoding 처리
   • HTML에 사용자 입력을 출력할 때, < → &lt; , > → > , " → " 등으로 변환하여 브라우저가 스크립트로 인식하지 못하게 합니다.
   • 템플릿 엔진(Thymeleaf, Mustache 등)은 보통 기본적으로 이런 처리를 도와줍니다.
2. 입력 검증(Validation)
   • 스크립트가 들어올 수 있는 입력(예: 댓글, 소개글 등)에 대해 특정 태그를 제한하거나, 길이 제한 등을 걸어 둡니다.
3. HttpOnly 쿠키 사용
   • 세션 쿠키에 HttpOnly를 설정하면 자바스크립트에서 쿠키를 읽을 수 없습니다.
   • XSS가 발생해도 쿠키 탈취를 어느 정도 막을 수 있습니다.
4. CSP(Content Security Policy) 설정
   • 브라우저에게 “어디에서 온 스크립트만 실행해도 되는지”를 알려주는 보안 정책입니다.
   • 예:
     • script-src 'self' → 현재 도메인에서 온 스크립트만 허용
     • 임의의 인라인 스크립트, 외부 스크립트를 차단

---

5. Reverse Proxy / Load Balancer 구조

5-1. Proxy vs Reverse Proxy

1) 일반 Proxy (Forward Proxy)

• 클라이언트 쪽에 있는 대리인
• 클라이언트가 직접 서버에 요청하지 않고 프록시 서버를 거쳐서 요청합니다.
• 프록시 서버가 대신 인터넷에 요청을 보내고, 응답을 클라이언트에게 전달합니다.
• 주로 회사 내부망, 학교, 검열 회피, 캐싱 등의 목적에 사용합니다.

2) Reverse Proxy (역방향 프록시)

• 서버 쪽에 있는 대리인
• 클라이언트는 Reverse Proxy를 “진짜 서버”처럼 봅니다.
• Reverse Proxy가 실제로는 여러 대의 서버 중 하나로 요청을 전달합니다.
• ex) Nginx, Apache HTTP Server, HAProxy 등

Reverse Proxy를 사용하는 이유:

• 실제 서버 IP를 숨기고 보안을 강화합니다.
• SSL/TLS(HTTPS) 처리(TLS 종료)를 프록시에서 처리하여 뒤쪽 서버의 부담을 줄입니다.
• 정적 파일(이미지, CSS, JS)을 캐싱하여 속도를 높입니다.
• 여러 백엔드 서버로 요청을 분산할 수 있습니다.
• → 이때 Load Balancer 역할을 하기도 합니다.

5-2. Load Balancer(로드 밸런서)

로드 밸런서는 들어오는 요청들을 여러 서버에 골고루 나누어주는 역할을 합니다.

예를 들어, 웹 서버가 1대일 때는 트래픽이 몰리면 버틸 수 없지만, 3대로 나누면 각각의 서버에 1/3씩만 부담이 가게 만들 수 있습니다.

로드 밸런서의 주요 기능:

1. 트래픽 분산
   • Round Robin, Least Connections 등 다양한 방식으로 분배합니다.
2. Health Check
   • 특정 서버가 죽었는지 주기적으로 확인합니다.
   • 죽은 서버로는 트래픽을 보내지 않습니다.
3. Failover
   • 일부 서버에 장애가 나도 다른 서버로 요청을 보내 서비스 전체 장애를 막습니다.
4. 확장성
   • 서버를 수평 확장(Scaling Out) 하기 쉽게 만들어 줍니다.

5-3. Reverse Proxy와 Load Balancer의 관계

• Reverse Proxy는 클라이언트 ↔ 서버 사이에 있는 중간 서버입니다.
• 이 Reverse Proxy가 여러 서버로 트래픽을 분산하는 기능까지 수행하면 Load Balancer 역할을 하는 Reverse Proxy가 됩니다.

실제 현업에서는 다음과 같은 구성이 자주 사용됩니다.

• 클라이언트 → Nginx(Reverse Proxy + Load Balancer) → 여러 대의 WAS(Tomcat, Spring Boot 등)