[C/F TIL] 56~58일차 - Cookie/ Session

Code States
Front-end boost camp
Today
I
Learned

🥗 맑고 덥댜잉 56~57일차 백엔드 ㅠ...

🥗 Cookie

• 쿠키 : 서버에서 클라이언트 영속성 있는 데이터를 저장하는 방법
• 단순히 서버에서 클라이언트에 쿠키를 전송하는 것만 의미하지 않고 클라이언트에서 서버로 쿠키를 다시 전송하는 것도 포함
• 데이터를 저장한 이후 아무 때나 데이터를 가져올 수는 없음
  -- 데이터를 저장한 이후 특정 조건들이 만족되어야 다시 가져올 수 있기 때문

✔️ 쿠키 옵션 종류

• Domain : 서버에 접속할 수 있는 이름(ex. www.google.com)
• Path : 세부 경로로써 서버가 라우팅할 때 사용하는 경로
• MaxAge or Expires : 쿠키가 유효한 기간을 정하는 옵션
• Secure : 사용하는 프로토콜에 따른 쿠키의 전송 여부를 결정하는 옵션, 도메인이 localhost인 경우 HTTPS가 아니어도 쿠키 전송 가능
• HttpOnly : 자바스크립트로 브라우저의 쿠키에 접근이 가능한지 여부 결정, 해당 옵션이 true로 설정된 경우, 자바스크립트로 쿠키게 접근 불가
• SameSite : Cross-Site 요청을 받은 경우, 요청에서 사용한 메서드와 해당 옵션의 조합을 기준으로 서버의 쿠기 전송 여부를 결정하게 됨. 이때, Cross-Origin과 Cross-Site를 혼동하지 않도록 주의
  -- Cross-Origin : 서버의 도메인, 프로토콜, 포트 중 하나라도 다른 경우 Cross-Origin으로 구분됨
  -- Cross-Site : eTLD+1이 다른 경우 Cross-Site로 구분
  -- SameSite 옵션 : Lax - 사이트가 서로 달라도, GET 요청이라면 쿠키 전송이 가능/ Strict - 사이트가 서로 다르면, 쿠키 전송 불가/ None - 사이트가 달라도, 모든(GET, POST, PUT 등등) 요청에 대해 쿠키 전송 가능

• 쿠키를 이용한 상태 유지 : 쿠키의 특성을 이용해 서버는 클라이언트에 인증정보를 담은 쿠키를 전송하고, 클라이언트는 전달받은 쿠키를 서버에 요청과 함께 전송하여 Stateless한 인터넷 연결을 Stateful하게 유지 가능
  -- 하지만 기본적으로 쿠키는 오랜 시간 동안 유지될 수 있고 HttpOnly 옵션을 사용하지 않았다면 자바스크립트를 이용해서 쿠키에 접근할 수 있기 때문에 쿠키에 민감한 정보를 담는 것은 위험함

🥗 Session

✔️ 세션기반 인증

• 로그인
  
  -- 서버가 해당 유저는 인증에 성공했음을 알고 있다면 유저가 매번 로그인할 필요가 없을 것
  -- 서버: 사용자가 인증에 성공했음을 알고 있어야함
  -- 클라이언트 : 인증 성공을 증명할 수단을 갖고 있어야 함
  -- 세션 : 사용자가 인증에 성공한 상태
  -- 세션이 만들어지면, 각 세션을 구분할 수 있는 세션 아이디도 만들어지는데, 보통 클라이언트에 세션 성공을 증명할 수단으로써 세션 아이디 전달
  -- 웹사이트에서 로그인을 유지하기 위한 수단으로 쿠키를 사용
  -- 쿠키에는 서버에서 발급한 세션 아이디를 저장함

• 로그아웃
  -- 서버 : 세션 정보를 삭제
  -- 클라이언트 : 쿠키를 변경하거나 삭제해야 함

• express-session
  -- Node.js가 이런 세션을 대신 관리해주는 express-session이라는 모듈을 가지고 있음

🥗 Hashing

• 해싱 : 가장 많이 쓰이는 암호화 방식 중에 하나
• 해싱은 복호화 불가, 암호화만 가능
• 함수(Hash Function)을 사용해 암호화 진행
• 해싱의 특징
  -- 1. 항상 같은 길이의 문자열 리턴
  -- 2. 서로 다른 문자열에 동일한 해시 함수를 사용하면 반드시 다른 결과값이 나옴
  -- 3. 동일한 문자열에 동일한 해시 함수를 사용하면 항상 같은 결과값이 나옴
• 레인보우 테이블 : 항상 같은 결과값이 나온다는 특성을 이용해 해시 함수를 거치기 이전의 값을 알아낼 수 있도록 기록해 놓은 테이블
  -- 보안상 위협이 될 수도... 이를 보완하기 위해? 솔트 활용
• 솔트 : 소금을 치듯 해싱 이전 값에 임의의 값을 더해 데이터가 유출되더라도 해싱 이전의 값을 알아내기 더욱 어렵게 만들어 주는 방법
• 해싱의 목적 : 데이터 그 자체를 사용하는 것이 아니라, 동일한 값의 데이터를 사용하고 있는지 여부만 확인하는 것이 목적이기 때문
• 서버 측에서 비밀번호를 모르는 상태에서도 로그인 요청을 처리할 수 있다!
  -- 해싱한 값끼리 비교해서 일치하는지 확인하면 됨!!

해싱은 민감한 데이터를 다루어야 하는 상황에서 데이터 유출의 위험성은 줄이면서 데이터의 유효성을 검증하기 위해 사용되는 단방향 암호화 방식이다!