네트워크

[네트워크] REST, JWT, 보안 개념, 프록시

생선묵김치찌개 2025. 3. 28. 13:19

쿠키

- 클라이언트(브라우저)와 서버 간의 상태 정보를 저장하고 주고받기 위한 작은 데이터 조각

- key=value 값으로 이뤄진 간단한 텍스트

- 탈취 될 위험 큼

 

구성요소

  • 값 (Value : 저장할 쿠키의 이름과 값)
  • 생명주기 (Expires : 만료일 설정)
  • 경로 (Path : 해당 페이지 경로에서만 쿠키 사용 접근이 가능)
  • 도메인(Domain : 해당 도메인 페이지에서만 쿠키 사용 접근이 가능)

 

생성방법

- response header 에서 Set-cookie 영역에서 설정할 쿠키의 이름 , 값 , 쿠키의 옵션 등을 담아 전송

사용 예시

- 세션 관리 : 인가 작업

- 개인화 : 다크모드, 광고 그만보기

- 트래킹 : 사용자의 행동을 기록하고 분석 (Google Analystic)

 

세션

- 쿠키와 마찬가지로 상태가 없는 HTTP를 상태 있게 만들어주는 핵심 메커니즘

- 클라이언트와 서버 간의 상태 정보를 서버 측에 저장하는 방식

- Set-Cookie: JSESSIONID=abc123 와 같이 쿠키에 세션 ID를 담아 응답하고 클라이언트는 세션 ID만 가짐

- 서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해진다

- 로그인 시 세션을 사용하면 세션 ID 자체를 탈취하여 클라이언트인척 위장할 수 있다

 

동작 방식

1. 클라이언트가 서버에 로그인 요청

2. 서버는 유효한 로그인 정보이면 세션 생성 + 세션ID 생성

3. 클라이언트에게 Set-Cookie: JSESSIONID=abc123 와 같이 쿠키에 세션ID를 담아 응답

4. 이후 요청마다 브라우저가 Cookie: JSESSIONID=abc123 자동 전송

5. 서버는 세션ID를 기반으로 사용자 정보를 찾아서 처리

 

 

쿠키 vs 세션 : 가장 큰 차이는 저장 위치

항목 쿠키 세션
저장 위치 클라이언트 (브라우저) 서버 (메모리 or DB)
보안성 낮음 (데이터 노출 가능) 상대적으로 높음
데이터 용량 제한적 (4KB 이하) 비교적 제한 없음
유지 기간 설정 가능 (영구 or 임시) 브라우저 종료 or 일정 시간 후 만료
자동 전송 모든 요청에 자동 포함됨 세션 ID를 쿠키로 자동 포함
자원 부담 서버 부담 적음 서버 자원 많이 사용
사용 예 자동 로그인, 방문 기록 로그인 상태 유지, 장바구니, 사용자 인증
클라이언트 노출 여부 ✅ 있음 (브라우저 저장) ❌ 없음 (세션 ID만 전달)

 

 

JWT

-  인증에 필요한 정보들을 암호화시킨 JSON 토큰

-  JWT 토큰(Access Token)을 HTTP 헤더(Authorization)에 실어 서버가 클라이언트를 식별 

 

JWT의 구조

- 헤더, 페이로드, 서명으로 나뉨

- 헤더 : 해시 알고리즘의 종류, JWT 타입임을 명시

- 페이로드 : 실제 정보 조각 (Claim)

- 서명 : 헤더+페이로드를 비밀키로 서명한 값 (위변조 방지용)

 

JWT 인증/인가 로직

- 클라이언트는 JWT를 로컬스토리지 or 쿠키 등에 저장

- 요청시 Authorization: Bearer <JWT> 헤더에 토큰 넣고 다님

 

 

SOP와 CORS

- SOP (Same-Origin Policy) : "다른 출처(origin)에서 온 리소스에는 기본적으로 접근을 차단한다"는 원칙

- CORS (Cross-Origin Resource Sharing) : 다른 출처의 리소스 요청을 허용하기 위해 "Access-Control-Allow-Origin" 헤더 사용

 

출처(origin)란?

http://example.com:80/index.html
└──────────┬─────────┘
(protocol)://(host):(port) 가 모두 같아야 같은 Origin

 

SOP가 막는 것들

- 다른 출처의 리소스에 대해 브라우저가 자바스크립트를 통해 접근하는 것을 막습니다.

<img src="..."> ✅ 가능
<script src="..."> ✅ 가능
<link href="..."> ✅ 가능
AJAX (fetch, XMLHttpRequest) ❌ 차단됨 (→ 이걸 허용하려면 CORS 필요)

 

CORS 동작방식

1. 클라이언트에서 HTTP요청의 헤더에 Origin을 담아 전달

2. 서버는 응답헤더에 Access-Control-Allow-Origin을 담아 클라이언트로 전달

- Access-Control-Allow-Origin : 이 리소스를 접근하는 것이 허용된 출처 url

3. 클라이언트에서 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교

 

 

Rest란?

- 자원을 URI로 표현하고, HTTP 메서드로 자원의 행위를 조작하는 아키텍처 스타일

 

 

URL, URI, URN 

URI란? (Uniform Resource Identifier)

- 리소스를 식별하기 위한 고유한 이름, 경로- URI = URL + URN

 

URL란? (Uniform Resource Locator)

- 리소스의 위치(주소)를 나타냄

 

URN란? (Uniform Resource Name)

- 위치 정보 없이 리소스를 고유하게 구분

 

 

보안 공격

XSS 공격

- 공격자가 만든 악성 스크립트가 웹페이지에 삽입되어, 다른 사용자에게 전달되고 브라우저에서 실행되는 공격

1. 게시판이나 댓글 등 사용자 입력을 받는 곳에 JS 삽입

2. 이 입력이 필터링 없이 그대로 출력되면, 페이지를 본 다른 사용자의 브라우저에서 JS가 실행

 

 

 

방어 방법

방법 설명
🔸 입력 값 검증 및 필터링 <script> 같은 태그, 특수문자 입력 제한
🔸 출력 시 이스케이프(Escape) 사용자 입력을 HTML로 출력할 때 반드시 이스케이프 처리
→ < → &lt;, > → &gt;

 

- 이스케이프 처리를 하면 사용자가 악의적으로 입력한 JS를 태그가 아닌 문자열로 인식해버림

 

CSRF 공격

- 사용자의 인증 정보를 도용해, 사용자가 의도하지 않은 요청을 서버에 보내는 공격

1. 사용자가 A 사이트에 로그인 (세션 or 쿠키 인증 상태)

2. 공격자가 만든 악성 사이트 B에 방문

 

3. 악성 사이트 B에 A 사이트로 요청 보내는 코드 실행됨

 4. A 사이트는 요청을 신뢰하고 처리

 

방어 방법

방어 방법 설명
🔐 CSRF Token 사용 요청마다 유일한 토큰을 발급 & 서버는 이 토큰을 검증 → 토큰 없거나 위조되면 요청 거부

 

SQL Injection

- 악의적인 SQL 쿼리문을 삽입하여 데이터베이스를 비정상적으로 조작하는 공격

 

방어 방법

방법 설명
PreparedStatement (Prepared SQL) SQL에 변수 자리를 미리 지정하고, 값만 바인딩 → SQL 코드 삽입 불가
ORM 사용 JPA, Hibernate 등 ORM은 내부적으로 PreparedStatement 사용