| 설명 | 접속상태 저장경로 | 장점 | 단점 | |
|---|---|---|---|---|
| Cookie | http의 stateless한 것 보완하는 도구 | 클라이언트 | 클라이언트에 저장하므로 서버에 부담 덜어줌 | 쿠키 자체는 인증이 아님 |
| Session | 서버가 접속상태를 가짐(stateful) 접속상태와 권한부여를 위해 세션아이디를 쿠키로 전송 | 서버 | 신뢰할 수 있는 유저인지 서버에서 추가로 확인 가능 | 하나의 서버에서만 접속상태를 가지므로 분산에 불리 |
Q, HTTP stateless인제 어떻게 유저 정보가 유지될까요?
= 쿠키 덕분이다
Cookie
서버가 웹 브라우저에 정보를 저장하고 다시 불러올 수 있는 수단
- 해당 도메인에 대해 쿠키가 있으면, 웹 브라우저는 도메인에게 http 요청 시 쿠키를 함께 전달
사용처
사용자 선호, 테마 등 장시간 보존해야하는 정보 저장에 적합
- 장바구니, 마케팅 정보 등
Cookie Options
데이터 저장 후, 특정 조건들이 만족되어야 다시 불러올 수 있음
<예시>
'Set-Cookie':[
'cookie=yummy',
'Secure=Secure; Secure',
'HttpOnly=HttpOnly; HttpOnly',
'Path=Path; Path=/cookie',
'Doamin=Domain; Domain=codestates.com'
]1. Domain
쿠키 접근 가능한 도메인 지정
- 도메인
- 쿠키 옵션에서 도메인은 포트 및 서브 도메인 정보, 세부 경로를 포함하지 않음
- ex) 요청 URL -
http://www.localhost.com:3000/users/login면 여기서 Domain은localhost.com
- 서브 도메인
www같이 도메인 앞에 작성된 부분
- 도메인 설정이 있다면 클라이언트에서 쿠키의 도메인 옵션과 서버의 도메인이 일치해야만 쿠키 전송 가능
그렇다면naver.com에서 받은 쿠키를apple.com에 전송하는 일을 막을 수 있음
2. Path
서버가 라우팅할 때 사용하는 경로로 쿠키가 접근할 수 있는 경로
-
만약 요청 URL이
http://www.localhost.com:3000/users/login인 경우라면 여기에서 Path, 즉 세부 경로는/users/login이 됩니다. -
명시하지 않으면 기본값은
/ -
설정된 경로를 포함하는 하위 경로까지만 쿠키 접근 가능
- ex) Path -
/users,
요청 세부경로 -/users/codestates면 => 쿠키 전송 가능
요청 세부경로 -/posts/codestates는
Path 옵션(/users)이 달라서 => 쿠키 전송 불가
- ex) Path -
3. MaxAge or Expires
쿠키의 유효기간을 지정하는 옵션
만약 쿠키가 계속 남아있으면 탈취되기 쉬워지므로, 유효기간을 설정하는 것이 보안 측면에서 도움이 된다
MaxAge
-
쿠키가 유효한 시간을 초 단위로 설정하는 옵션.
-
현재시간부터 지정시간까지 유지하고 시간이 초과되면 삭제됨
// 1시간 뒤 쿠키 삭제 document.cookie = "user=John; max-age=3600"; // 음수값 0으로 지정하면 => 쿠키 바로 삭제됨 document.cookie = "user=John; max-age=0";
Expires
- 클라이언트 시간을 기준으로 지정된 시간, 날짜를 초과하면 쿠키 삭제됨
// 현재시간에서부터 하루뒤에 쿠키 삭제 - 유효기간 하루 let date = new Date(Date.now() + 86400e3); date = date.toUTCString(); // GMT(Greenwich Mean Time)포맷으로 설정해야 돼서 해당코드 작성 document.cookie = "user=John; expires=" + date;
세션 쿠키 (Session Cookie)
- MaxAge나 Expires 옵션이 없는 쿠키로, 브라우저를 종료하면 쿠키는 삭제됨
영속성 쿠키 (Persistent Cookie)
- MaxAge나 Expires 옵션이 있는 쿠키로, 브라우저의 종료 여부와 상관없이 지정된 유효시간만큼 쿠키 사용가능
4. Secure
프로토콜에 따라서 쿠키의 전송 여부를 정하는 옵션
-
Secure 옵션이
true로 설정된 경우HTTPS일때만 쿠키를 전송 가능 -
Secure 옵션이 없다면 프로토콜에 상관없이
HTTP나HTTPS모두 쿠키 전송 가능
5. HttpOnly
자바스크립트에서 브라우저의 쿠키에 접근 여부를 결정
-
옵션이
true인 경우, 자바스크립트에서 쿠키 접근불가 -
명시하지 않으면 기본값은
false,
document.cookie를 이용해 자바스크립트에서 쿠키접근이 가능하므로 XSS 공격에 취약
6. SameSite
Cross-Origin 요청을 받은 경우, 요청에서 사용한 메소드와 해당 옵션(GET, POST, PUT, PATCH …)을 기준으로 서버의 쿠키 전송 여부를 결정
- 크로스 사이트 요청 위조(cross-site request forgery, XSRF)공격을 방지하기 위한 옵션
- Lax
: GET 메소드에서만 쿠키 전송 가능 - Strict
: 엄격한 옵션, Cross-Origin이 아닌 same-site 인 경우에만 쿠키 전송 가능 - None
: 항상 쿠키 전송 가능. 다만 Secure 옵션이 필요
same-site
: 요청 보낸 Origin과 서버의 도메인, 프로토콜, 포트가 같은 경우.하나라도 다르면 Cross-Origin으로 구분됨- 서버 => 클라이언트로 옵션들을 지정 후 쿠키를 전송하고싶으면
헤더에Set-Cookie프로퍼티로 쿠키 담아 전송. - 클라이언트 => 서버에게 쿠키를 전송해야하면
클라이언트는 헤더에Cookie속성에 쿠키를 담아 서버에 쿠키 전송
쿠키를 이용한 상태 유지
-
서버 => 클라이언트로 인증정보를 담은 쿠키를 전송,
클라이언트 => 서버에 요청과 전달받은 쿠키를 전송하여 Stateless한 인터넷 연결을 Stateful하게 유지 가능해짐 -
하지만 쿠키에
HttpOnly옵션을 사용하지 않으면
계속 유지되므로 자바스크립트를 이용해서 쿠키에 접근할 수 있기 때문에 쿠키에 중요한 정보를 담는 것은 위험함 -
만약 저장된 인증정보를 이용해 해커가 유저인척 서버에 요청을 보내고
서버는 누가 요청을 보낸 건지 확인하지 않고 유저의 요청으로 받아들이면, 개인정보 같은 중요한 정보를 탈취될 수 있어서 보안에 문제가 생길 수 있다.
참고
Session
중요 데이터를 서버에 저장
- 서버가 클라이언트에 유일하고 암호화된 ID를 부여
단점
- 서버 성능 안좋아짐 - 서버 저장 공간 메모리를 차지하므로
- XSS 공격으로 세션 쿠키가 탈취되면 개인정보 유출됨
express-session
: express 서버에서 쉽게 세션을 대신 관리하는 미들웨어
const express = require('express');
const session = require('express-session');
const app = express();
app.use(
session({
secret: '@codestates',
resave: false,
saveUninitialized: true,
cookie: {
domain: 'localhost',
path: '/',
maxAge: 24 * 6 * 60 * 10000,
sameSite: 'none',
httpOnly: false,
secure: true,
},
})
);쿠키 옵션과 비슷해 보이지만
-
세션의 경우 secret 옵션의 비밀키를 이용해 암호화해 세션 id를 생성하고, 클라이언트에 쿠키로 전송한다
-
세션 id에 종속되는 고유한 세션 객체를 가지며 서버에 저장된다.
-
클라이언트에 유저의 개인정보를 담지않고도
서버가 클라이언트의 세션 id를 이용해 유저의 인증여부를 판단 가능.
세션 객체
: 유저별로 독립적으로 생성된 객체.
-
세션 객체는
req.session으로 접근 가능하고,
이를 통해 세션에 임의 데이터를 저장하거나 불러올 수 있다. -
세션 객체에 값 담기, 값 불러오기, 세션 파괴하는 법은 다음을 참고하라
GitHub: express-session
참고
