1. Toy - 32일차
- 히스토그램 넓이를 구하는 문제
- 구간 트리를 변형해 푸는 문제
2. 인증 / 보안
- HTTPS(HTTP + Secure)
HTTP 내용을 암호화
인증서
CA
비대칭 키 암호화
를 사용
인증서 (Certificate)
데이터 제공자 신원 보장
도메인 종속
인증서 도메인과 응답 도메인을 비교하여 확인
CA (Certificate Authority)
인증서 발급 기관
비대칭 키 암호화
키 A로 암호화 => 키 B로만 복호화 가능
공개키 : 한쌍의 키 중 하나만 공개, 연산이 복잡
=> 클라이언트 Hello
<= 서버 Hello, 공개키, 인증서 전달 ---- Hand Shake
=> 키 제작용 랜덤 스트링 전달
<= 키 제작용 랜덤 스트링 전달 ---- 비밀키 생성
=> 세션 키로 암호화 된 메세지 전달
<= 세션 키로 암호화 된 메세지 전달 ---- 상호 키 검증
HTTPS 스프린트 실습 위해 mkcert 사용
cert.pem << 인증서, 공개키, 인증기관의 서명 포함
key.pem << 복호화 키, 공개되면 안되는 것
ngrok을 통해 터널링
HTTP로 만들어진 서버를 HTTPS 프로토콜로 터널링
터널링 되는 것 확인..
서버 => DB
패스워드를 암호화해서 저장
Hashing
어떠한 문자열에 임의의 연산을 적용하여 암호화
1) 모든 값에 대해 해시 값을 계사하는데 오래걸리지 않아야 한다.
2) 최대한 해시 값을 피해야 하며, 모든 값은 고유한 해시 값을 가진다.
3) 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 한다.
=> 이렇게 만들어져 있다~
대표적인 해쉬 알고리즘 => SHA1, SHA256
Salt
암호화해야 하는 값에 별도의 값을 추가하여 결과를 변형하는 것
1) 기존에 암호화만 해놓는다면 해시된 결과가 항상 같다
=> 해시된 값에 원래 값을 테이블(레인보우 테이블)로 만들어 복호화 해버릴 수 있음
2) 원본값에 임의로 약속된 별도의 문자열을 추가하여 해시를 진행한다면, 원본값을 보호할 수 있도록한 안전 장치 => Salt
3) 기존 : 기존 값 => 해시 값
Salt : 기존 값 + 솔트 값 => 해시값
Salt는 유저와 패스워드 별로 유일한 값을 가져야 한다
계정을 생성, 변경할 때마다 새로운 임의의 Salt를 사용해서 해싱해야 함
재사용하면 안됨 Salt는 유저 테이블에 같이 저장되어야 한다
쿠키
서버가 일방적으로 클라이언트에 전달하는 작은 데이터
서버가 웹브라우저에 정보를 저장하고 불러올 수 있는 수단
웹 브라우저는 도메인에 HTTP 요청 시, 해당 도메인에 대해 쿠키가 존재하면 쿠키를 함께 전달
장기간 저장해야하는 정보에 적합
ex) 사용자 선호, 테마, 로그인 상태 유지, 장바구니 등등..
Set-Cookie: ~
Cookie Options
-Domain 서버와 요청의 도메인이 일치하는 경우
-Path 서버와 요청의 세부경로(라우팅)가 일치하는 경우(하위 라우팅의 경우도 쿠키 전송 가능)
-MaxAge or Expires 쿠키의 유효기간 설정(MaxAge는 초, Expries는 Date 지정)
-HttpOnly 스크립트의 쿠키 접근 가능 여부, true일 경우 JS접근 불가, 기본 설정 false, false일 경우 XSS 공격에 취약
-Secure HTTPS 프로토콜에서만 쿠키 전송 여부
-SameSite CORS 요청의 경우 옵션 및 메서드에 따라 쿠키 전송 여부 결정 CSRF 공격
-SameSite 옵션
-Lax GET 메서드 요청만 쿠키 전송 가능
-Strict 쿠키 전송 불가
-None 모든 메서드 요청에 대해 쿠키 전송 가능
- CSRF 발행된 유효한 토큰을 악용하는 공격
쿠키는 오랜 시간 저장되고, JS로 접근이 가능하기에, 민감한 정보는 위험!
3. Session
<> 쿠키 : 클라이언트에 정보 저장
<> 세션 : 서버에 정보 저장, 데이터에 대한 암호화된 세션id만 쿠키에 저장
단점
서버 저장 공간
-
로그인
인증에 성공했음을 서버가 알고있다면 매번 로그인 할 필요가 없다
클라이언트는 세션ID를 쿠키에 가지고
서버는 세션을 저장 -
로그아웃
서버 세션 삭제
클라이언트 쿠키 갱신 -
express-session 사용
review
1) 로그인 요청
2) 해싱, 데이터베이스 요청
3) 세션id 생성 및 세션 스토어에 세션 저장
4) 쿠키에 세션 id 설정
5) 브라우저에 쿠키 저장
6) 유저 정보 재사용 시, 세션 id와 함께 요청
7) 세션 스토어에서 세션 id가 유효한지 판단
8) 유효하다면 정보 정보 응답
fetch 대신 axios 써보기
쿠키 보안
1) 옵션 설정(maxAge, Expire)
2) 세션 아이디는 클라이언트의 특정 ip로만 접속하게끔
CSRF (Cross Site Request Forgery)
- 다른 사이트에서 유저가 보내는 요청을 조작(forgery)하는 것
- 해커가 직접 데이터를 접근할 수 없다 >> 요청을 조작하는 것이기에
CSRF의 조건
쿠키를 사용한 로그인
예측할 수 있는 요청/parameter를 가짐
CSRF 토큰을 사용해 방지 - 유저의 브라우저와 웹 앱에만 제공
Same-site cookie 사용 - 같은 도메인에서만 세션/쿠키를 사용
