[네트워크] HTTP 상태유지 기술 & SOP와 CORS & REST

✅ 쿠키와 세션

: HTTP 프로토콜의 특성인 비연결성(connectionless)과 무상태성(stateless)을 보완하기 위해 만들어진 기술

 

ex) HTTP 특성상 매번 페이지를 이동할 때마다 로그인을 다시 해야 한다.
-> 이렇게 상태 정보를 저장할 필요가 있을 때 쿠키와 세션 사용

 

비연결성 : 한 번의 요청과 응답이 오간 후에 맺었던 연결을 끊어버림
무상태성: 통신이 끝나면 상태 정보를 기억하지 않음

 

---

📍 쿠키(Cookie)

: 클라이언트 PC에 저장되는 작은 기록 정보 파일

 

[특징]

• Key-Value 쌍으로 구성
• 이름, 값, 만료일, 경로 정보로 구성
• 도메인 당 20개의 쿠키를 가질 수 있음
• 하나의 쿠키는 4KB까지 저장 가능

 

[작동 방식]

1. 클라이언트가 서버에 HTTP 요청을 보냄
2. 서버는 요청을 처리한 후, 응답 헤더 `Set-Cookie`에 쿠키를 담아서 응답
3. 클라이언트는 받은 쿠키를 로컬에 저장
4. 클라이언트는 이후 서버에 요청할 때마다 쿠키를 자동으로 요청 헤더 `Cookie`에 추가하여 전송

 

[문제점]

`Cookie`는 `Javascript`를 사용하여 접근이 가능하다.

즉, 공격자가 Script를 작성해 사용자의 쿠키 정보를 탈취할 수 있으므로 XSS(Cross Site Script)에 매우 취약하다고 할 수 있다.

 

XSS (Cross-Site Scripting): 관리자가 아닌 권한이 없는 사용자가 웹 사이트에 스크립트를 삽입하는 공격

 

---

📍 세션(Session)

: 쿠키가 보안상 취약하다는 단점을 해결하기 위해, 서버 측에서 관리하는 사용자 정보 파일

 

[특징]

• 쿠키를 기반으로 하고 있음
• 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여
• 브라우저가 종료될 때까지 인증 상태 유지

 

[작동 방식]

1. 클라이언트가 서버에 HTTP 요청을 보냄
2. 서버는 요청 헤더의 `Cookie` 필드에 세션 ID가 포함되어 있는지 확인
3. 세션 ID가 없을 경우, 서버는 새로운 세션 ID를 생성하여 응답 헤더 `Set-Cookie`에 담아서 전송
4. 서버는 생성된 세션 ID를 저장하여 클라이언트의 상태를 관리
5. 클라이언트는 쿠키를 이용하여 세션 ID 값을 서버에 전달하여 이전 상태를 유지

 

[문제점]

세션은 서버에 저장되기 때문에, 세션이 많아질수록 부하 문제가 발생한다.

즉, 사용자가 많을수록 속도가 저하된다.

 

---

📍 쿠키 vs. 세션

쿠키와 세션의 가장 큰 차이는 “상태 정보의 저장 위치”

쿠키는 클라이언트에, 세션은 서버에 저장한다.

 

[왜 쿠키와 세션을 같이 사용할까?]

세션이 쿠키의 단점을 보완하기 위해 나왔음에도, 쿠키와 세션을 같이 사용한다.

 

세션은 서버에 저장되므로, 사용자가 많을 경우 소모되는 서버 자원이 상당하다.

따라서 자원관리 차원에서, 쿠키와 세션을 적절히 병행해서 사용하여 서버 자원의 낭비를 방지해야 한다.

• 속도: 쿠키 > 세션
• 보안: 쿠키 < 세션

---

✅ JWT (Json Web Token)

: 인증에 필요한 정보들을 Json 객체에 담은 후 비밀키로 서명한 토큰

 

세션 인증 방식의 서버가 부하된다는 문제점을 해결한다.

 

[작동 방식]

1. 클라이언트가 서버에 로그인 요청
2. 서버는 비밀키를 사용해 JWT 토큰 발급
3. JWT 토큰을 헤더에 담아 클라이언트에 전달
4. 클라이언트는 JWT 토큰을 로컬에 저장
5. 클라이언트는 API를 호출할 때마다 헤더에 JWT 토큰을 넣어서 전송
6. 서버는 헤더를 확인하여 JWT의 서명을 공개키로 인증하고 API에 대한 응답 반환 

[구조]

Header.Payload.Signature

 

: Header, Payload, Signature 3개로 구성

• Header : 알고리즘, 토큰 타입
• Payload : 사용자 정보의 한 조각인 클레임(claim)
• Signature(서명) : 헤더와 페이로드의 문자열을 합친 후에, 헤더에서 선언한 알고리즘과 비밀키를 이용해 암호화한 값

 

Header와 Payload는 단순히 Base64로 인코딩 되어 있어 누구나 쉽게 복호화할 수 있지만,

Signature는 비밀키가 없으면 복호화할 수 없다.

 

---

✅  SOP와 CORS

두 정책은 모두 출처(origin)와 관련된 개념이다.

출처는 URL의 프로토콜, 호스트, 포트 3가지로 정의된다.

 

📍 SOP (Same Origin Policy)

: 같은 출처(same origin)에 한해서 리소스를 허용하는 정책 = 다른 출처의 리소스와 상호 작용하는 것을 제한하는 정책

 

앞서 말했듯이 URL의 프로토콜, 호스트, 포트가 모두 같은 출처를 동일 출처라고 한다.

 

[동일 출처 예시]

`http://store.com/dir/page.html` 를 기준으로 동일 출처인지 비교하면 다음과 같다.

• `http://store.com/dir2/page.html`는 동일 출처
• `http://store.com/dir/page2.html`는 동일 출처
• `https://store.com/dir/page.html`는 프로토콜(https)이 달라 다른 출처
• `https://store.com:81/dir/page.html`는 포트(:81)가 달라 다른 출처
• `https://store2.com/dir/page.html`는 호스트(store2)가 달라 다른 출처

 

---

📍 CORS (Cross Origin Resource Sharing)

: SOP를 완화해 주는 기술로, 서버에서 특정 리소스를 받아올 수 있도록 허용하는 정책

 

서버는 특정 출처를 명시하여 해당 출처에서 오는 요청을 허용할 수 있다.

 

예를 들어, 한 컴퓨터에서 리액트 서버(3000 포트)와 스프링 서버(8080 포트)는 서로 포트가 다르므로 다른 출처이다.

따라서, 두 서버가 리소스를 주고받으려면 CORS를 설정해서 이를 허용하도록 명시해줘야 한다.

 

 

---

✅  REST (Representational State Transfer)

 

: 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미 

 

결합도를 낮춰, 서버와 클라이언트가 별도로 구축될 수 있도록 한다.

 

1. HTTP URI를 통해 자원을 명시하고,
2. HTTP Method를 통해
3. 해당 자원에 대한 CRUD 연산을 적용하는 것을 의미

 

 

---

📍 REST 구성 요소

1. 자원(Resource) - HTTP URI
2. 자원에 대한 행위 - HTTP Method
3. 자원에 대한 행위의 내용 - HTTP Message Payload

 

---

📍 REST 제약조건 6가지

1. Client-Server: 클라이언트와 서버가 독립적으로 동작
2. Stateless: 각 요청은 독립적이며, 서버는 상태를 저장하지 않음
3. Cache: 클라이언트가 서버의 응답을 캐시하여 성능 향상할 수 있음
4. Layered System: 클라이언트와 서버 사이에 여러 중간 계층 서버가 있을 수 있음
5. Uniform Interface: 전체적인 시스템 아키텍처를 간단하게 파악할 수 있도록 하기 위한 약속된 인터페이스 사용
   • JSON이 가장 유명한 방식
6. Code on Demand(Optional): 클라이언트에 보내는 데이터를 바로 실행 가능한 코드형태로 보내서 이것을 클라이언트 내에서 실행

 

---

📍 RESTful 이란

:  REST의 원리를 따르는 시스템

 

RESTful API는 REST의 6가지 제약조건을 잘 따르는 API

즉, 자원을 URI로 명확히 표현하고 HTTP 메서드를 사용하여 자원을 조작하는 API이다.

 

---

✅  URL, URI, URN

• URI(통합 자원 식별자): 인터넷상의 리소스 자원을 식별하는 고유한 문자열. URI의 하위 개념으로 URL과 URN이 존재
• URL(위치): 웹 주소라고도 불리며, 네트워크상에서 리소스의 위치를 찾는데 사용
• URN(이름): 네트워크상에서 리소스의 이름. 위치와 관계없이 리소스를 식별하는 데 사용

`http://store.com/dir/page.html?page=1`를 기준으로 설명하자면

• `http://store.com/dir/page.html?page=1`는 URI
• `http://store.com/dir/page.html`은 URL

---