요약
회원가입, 로그인, 로그아웃
더 큰 개념인 인증, 권한부여
HTTPS
- HTTP + Secure
- HTTP 프로토콜 내용을 암호화
- HTTP는 중간에 누군가 요청 과정을 들여다 볼 수 있었다.
- 여기서 암호화 과정을 거쳐 key가 없다면 요청을 들여다 볼 수 없게 만듬
- 인증서, CA, 비대칭 키 암호화
인증서(Certificate)
- 데이터 제공자 신원 보장
- 도메인 종속
- 클라이언트 인증서의 도메인과 서버에서 주는 도메인을 비교하는 과정을 거친다.
CA(Certificate Authority)
- 공인 인증서 발급 기관
비대칭 키 암호화
- 전혀 다른 키 두개 쌍으로 암호화, 복호화를 한다.
- HTTPS를 이용하는 서버는 하나는 숨기고 하나는 공개해서 통신한다.
- 모든 통신에 대해서 공개키 방식을 사용하지는 않음
- 연산이 복잡함 ⇒ 통신의 초창기에서만 비밀 키로 사용하기 위한 키를 만들어내기 위해서 사용
- Hand Shake → 비밀 키 생성 → 상호 키 검증
인증서 커밋
인증서(cert.pem) 은 공개키, 인증기관의 서명을 포함하는 파일이라 공개되어도 상관없다.
개인 키(key.pem) 은 개인 키이므로 커밋해선 안된다. gitignore필요
ngrok
http 서버를 https로 바꿔주는(터널링시키는) 프로그램
Hashing
- 암호화의 기본
- 암호화는 일련의 정보를 임의의 방식을 사용하여 다른 형태로 변환, 해당 방식에 대한 정보를 소유한 사람이 아니면 이해할 수 없게 하는 과정
- 대표적으로 SHA1(요즘은 SHA256을 많이 씀)이 있다.
Hashing 세가지 철칙
- 모든 값에 대해 해시 값을 계산하는데 오래걸리지 않아야 한다.
- 최대한 해시 값을 피해야 하며, 모든 값은 고유한 해시값을 가진다.
- 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 한다.
Salt
- 암호화해야 하는 값에 어떤 ‘별도의 값’을 추가하여 결과를 변형하는 것
- 암호화만 해놓으면 해시된 결과가 늘 동일 ⇒ 해시된 값과 원래 값을 테이블을 만들어서 디코딩 하는 경우가 생김(레인보우 테이블)
- 원본값에 임의로 약속된 ‘별도의 문자열’을 추가하여 해시를 진행하면 알고리즘이 노출되어도 원본값을 보호할 수 있게 된다.
Salt 사용 유의점
- Salt는 유저와 패스워드 별로 유일한 값을 가져야 한다.(데이터베이스에 저장해놓고 비교할 때 사용)
- 사용자 계정을 생성할 때와 비밀번호를 변경할 때 마다 새로운 임의의 Salt를 사용하여 해싱해야 한다.
- Salt는 절대 재사용 하지 말아야 한다.
- Salt는 DB의 유저 테이블에 같이 저장되어야 한다.
Cookie
- HTTP는 stateless 한데 여러 쇼핑몰을 돌아다녀도 장바구니가 유지되는 이유
- 웹사이트에 진입했을 때 서버가 일방적으로 클라이언트에 전달하는 작은 데이터
- 서버가 웹 브라우저에 정보를 저장하고 불러올 수 있는 수단
- 해당 도메인에 대한 쿠키가 존재하면 웹 브라우저는 도메인에 http요청을 할 때 마다 쿠키가 함께 전송된다.
Cookie 이용법
- 쿠키의 특성 : 삭제하지 않는다면 사라지지 않는다. ⇒ 사용자 선호, 테마 등 장시간 보존해야 하는 정보에 적합하다. 로그인 로그아웃 같은 인증 정보도 쿠키에 많이 저장한다. 그런데 쿠키는 밖에서 들여다보기 쉽기 때문에 해싱을 잘 해놔야 한다.
Cookie 전달 방법
- 서버에서 헤더에 Set-Cookie 옵션으로 쿠키를 전달하고 클라이언트에서 쿠키를 전달 받으면 매 요청마다 Cookie 가 또 같이 전달된다(헤더에?).
Cookie 옵션
-
Domain : 서버와 요청의 도메인이 일치하는 경우에 쿠키 전송
-
Path : 서버와 요청의 세부경로가 일치하는 경우 쿠키 전송
-
MaxAge or Expires : 쿠키의 유효기간 설정(일정 시간 후 자동 소멸) - 피시방 같이 사용자가 여럿일 때 사용
-
HttpOnly : 스크립트의 쿠키 접근 가능 여부 설정 - 쿠키는
-
Secure : HTTPS 프로토콜에서만 쿠키 전송 여부 결정 → true, false
-
SameSite : CORS 요청의 경우 옵션 및 메서드에 따라 쿠키 전송 여부 결정 - CSRF공격을 막는데 효과적
- Lax 옵션 : get 요청만 쿠키 전송
- Strict 옵션 : 사이트가 다르면 쿠키 전송 불가
- None 옵션 : 모든 메서드 요청에 대해 쿠키 전송 가능 - Secure 쿠키 옵션이 필요함
Session
- 서버가 Client에 유일하고 암호화된 ID를 부여
- 중요 데이터는 서버에서 관리
Session 전달 방법
user와 password 정보가 맞으면 서버에서 클라이언트에 session을 부여해주고 이후에는 추가 인증이 필요 없는 구조
Session vs Cookie
| 설명 | 접속 상태 저장 경로 | 장점 | 단점 | |
|---|---|---|---|---|
| cookie | 쿠키는 그저 http의 stateless한 점을 보완하는 도구 | 클라이언트 | 서버의 부담을 덜어줌 | 쿠키 그 자체는 인증이 아님 |
| session | 접속 상태를 서버가 가짐(stateful), 접속 상태와 권한 부여를 위해 세션아이디를 쿠키로 전송 | 서버 | 신뢰할 수 있는 유저인지 서버에서 추가로 확인 가능 | 하나의 서버에서만 접속 상태를 가지므로 분산에 불리 |
Session의 추가적인 단점
유저가 많으면 서버의 일정 메모리를 항상 세션 유지 데이터가 차지하기 때문에 서버 성능이 저하된다.
쿠키를 여전히 사용하기 때문에 XSS공격을 당할 수 있다.
axios
fetch랑 거의 비슷한데 밖에서 axios.get, axios.post처럼 요청을 미리 나누고
json변환을 따로 안해도 기본적으로 탑재되어있다.
https 트레이드오프
기밀성(메세지를 가로챌 수 없음), 무결성(메세지가 조작되지 않음), 가용성(성능)
은 서로 트레이드오프가 있다.
해싱의 특징
비가역성(1방향 함수)
req.session
클라이언트에 쿠키로 저장된 세션내용인데 이거랑 서버에 저장된 세션 내용이 같은지에 대한 검증은 express에서 해준다.(따로 우리가 코드 작성 필요 x)
- req.session.save 메소드 session을 저장하고 실행할 함수를 콜백인자로 주기
- req.session.destroy 메소드 그 session id의 session 정보 삭제
다른 Origin 쿠키 전달
클라이언트 요청에 withCredentials : true 속성(axios에서)
서버 cors에 credentials : true(express에서)
를 적어줘야 쿠키가 자동으로 전송됨
- origin이 같은 경우는 자동으로 전송됨
