Hashing
Hashing의 암호화 하는 방법은
어떤 문자열에 임의의 연산을 적용 하여 다른 문자열을 변환하는 것
Salt
암호화해야 하는 값에 어떤 별도의 값을 추가하여 결과를 변형하는 것
Salt와 Hashing을 사용하는 과정
HTTPS
HTTPS를 사용해야 하는 이유
HTTP보다 상대적으로 안전한 방법이고, (인증기관)데이터 제공자(서버)의 신원을 보장 받을 수 있기 때문이다
Hashing을 통하여 암호화하는 방법과 HTTPS에서 사용하는 암호화 방식은 차이점이 있다
HTTPS에서 암호화 하는 방식
- 대칭키, 비대칭키 암호화 방식
- 공개키, 개인키 비대칭키 암호화를 통해서 보안을 유지하고 있다
HTTPS의 두가지 특징
기밀성과무결성을 보장을 한다, 즉 클라이언트와 서버의 통신이 안전하다는 것을 보장한다
Cookie
HTTP응답의 응답코드, header, body 중 3가지 영역중에서 header에 set-Cookie: 키=값 메소드를 활용을 해서 키와 값을 담아서 보내준다
헤더의 속성중 set-Cookie에 키-값 형태로 클라이언트에 넘겨준다
클라이언트는 밭은 쿠키로 매요청 때마다 받은 쿠키가 없어지기 전까지 모든 요청에 쿠키에 담긴 키=값을 보내게 된다
그러므로 server는 로그인 했는지 안했는지 및 각각의 통신들이 별개라도 알아볼 수 있다
set-Cookie는 서버가 클라이언트에게 전달하는 방법이다
Cookie: 키=값은 클라이언트가 서버에게 전달하는 방식이다
쿠키를 요청에 포함하고 싶으면 다음 2가지 작업을 해준다 (withCredentials)
프론트 : withCredentials : true (axios)
서버 : Access-Control-Allow-Credentials : true (cors)
요청시에 withCredentials : true를 해주고, 마찬가지로 서버의 응답헤더에 Access-Control-Allow-Credentials : true를 해주어여 한다
withCredentials
Credentials 이란 쿠키, 인증헤더, TLS client certificates(증명서)를 말한다
Credentials 이 있는 CORS 요청은 Client와 Server 둘다 Credentials를 사용하겠다는 속성을 설정해줘야 통신이 가능하다
따라서 CORS(Cross-Origin Resource Sharing) 요청시 Client에서 XMLHttpRequest.withCredentials 속성을 true 로 설정을 해야한다
요청을하기 전에 withCredentials가 true로 설정되어 있지 않으면 다른 도메인의 XMLHttpRequest가 자신의 도메인에 대한 쿠키 값을 설정할 수 없다
withCredentials를 true로 설정하여 얻은 타사 쿠키는 여전히 동일한 출처 정책을 준수하므로 document.cookie 또는 응답 헤더를 통해 요청하는 스크립트에서 액세스 할 수 없다결론적으로, withCredentials = true 를 해준다는 것은, client 와 server 가 쿠키 값을 공유하겠다는 말이다
Cookie 옵션
-
domain
같은 도메인, 같은 사이트 -
path
같은 경로 (endpoint) -
httpOnly
자바스크립트 사용 여부
자바스크립트의 스크립트 태그를 이용하여 접근하고 있는지 걸러 준다 -
MaxAge, Expires
만료 기간 설정 -
sameSite
3rd-cookie- LAX : 3rd-party가 GET일 때만 허용
- strict : 3rd-party 쿠키 차단
- none : 적용 안함(HTTPS 일 때만 가능)
sameSite는 CSRF 공격예방을 해준다
CSRF 공격을 막아준다
(어떤사이트에서 온 쿠키인지 구분하지 않는 점을 악용해서 공격하는 방법이 CSRF 다)
공격자 클라이언트가 다른 사용자의 인증정보가 담긴 쿠키로 서버에 요청해서 응답을 유도한다
- secure
HTTPS에 쿠키를 전달
1st-party Cookie
사용자가 네이버에 방문을 했을 시, 방문한 웹사이트, 즉 네이버에서 직접 발행해주는 쿠키파일3rd-party Cookie
사용자가 네이버에 방문을 했는데, 다른 웹사이트에서 즉 다른웹사이트 서버에서 사용자 컴퓨터에 쿠키를 발행 해준다
(내가 접속한 사이트가 아닌 서버에서 배 브라우저로 쿠리를 심는 과정, 접속한 사이트 도메인에서 발행이 되지 않은 쿠키)
Cookie의 인증 상 한계
MaxAge, Expires, HttpOnly, SameSite 등 각 종 옵션들을 이용해 XSS, CSRF 등의 공격에 대비할 수 있는 방법이 있기는 하지만 결국은 클라이언트에 정보를 저장하기 때문에 인증 상 한계가 존재 한다
즉 클라이언트에 정보를 저장하기 때문에 브라우저에서 열어볼 수 있다
Session
쿠키와 세션 비교
Session의 단점 중 하나의 서버에서만 접속 상태를 가지므로 분산에 불리하다
server의 session store가 있다
session store는 server가 가지고 있기 때문에 하나의 서버에서만 검증 할 수 있다
만약 분산시스템으로 서버를 여러개로 구축해야 한다면 Session 인증에서는 한계가 있다
그 한계를 보안 한것이 token이다
세션에서 로그아웃의 중요성
세션 아이디가 담긴 쿠키가 유츌된 상태에서는 해당 쿠키를 이용한 요청이 유츌된 쿠키를 이용한 공격인지, 정말로 사용자가 요청을 보낸건지 서버는 확인할 방법이 없다
즉, 서버에서 세션을 파괴하는 과정이 반드시 필요하다
세션을 로그아웃 한다는 것은 세션 스토어에 저장되어 있던 쿠키가 가진 정보를 지우는 것이다
로그아웃 하는 방법
-
서버에 있는 세션 스토어에서 세션을 지운다 (destroy())
클라이언트에도 쿠키에 세션 정보가 저장되어 있다, 이것은 서버에서 지울수가 없다
서버에서는 클라이언트에게 쿠키를 심어 줄수는 있어도 지울 수는 없다
1.유효기간설정
2.로그아웃 했을때 쿠키에다 다시한번 빈스트링 및 임이의 다른 정보를 넣어 준다
(클라이언트에 ''(빈스트링) 세션 정보를 다시 전달) -
서버 세션 스토어에서 세션을 지우고, 클라이언트에서 세션 아이디를 직접 없앤다
Token
세션과 토큰 비교
인증 정보가 어디에 저장 되는 지 가 핵심이다
Session은 서버에 저장
Token은 클라이언트에 저장 (AccessToken 쿠키에 저장)
Token 장점
토큰은 분산환경에 유리하다
만약 서버가 여러대라면 서비스가 수평적으로 확장을 했거나 로드밸런싱이 필요한 경우에는 여러개의 서버에서도 토큰만 있으면 인증이 될 수 있게 해주기 때문에 분산환경에 유리하다
Session 단점
서버에 부담이 많이 간다
만약 사용자가 많이 늘어나게 되면, 더 많은 트레픽을 처리 하기위해 서버를 여러개로 확장하게 되는 경우가 발행하면 세션은 서버에서만 인증해야 되므로, 다른 확장된 새로운 서버에서는 인증을 하지 못하는 경우가 발생한다
세션을 분산시키는 시스템을 설계하는게 복잡한 일이다
하지만 토큰은 어디서나 생성이 가능하기 때문에 토큰을 확인하는 서버가 토큰을 꼭 만들어야 하는 것은 아니며, 어떤 서버에서도 토큰을 만들 수 있고 그 토큰만 있으면 인증이 된다
확장성이 토큰의 큰 장점이다
인증을 구현하기 위해 토큰에 담아야 할 정보는 무엇인가
암호화 된 유저정보를 토큰에 담아 클라이언트에 저장
Header에는 어떠헥 암호화를 할것인지 방법이 들어간다
Payload에는 유저의 정보
Signatur에는 salt값의 조합으로 암호화된 값
엑세스 토큰과 리프레쉬 토큰
엑세스 토큰
유효기간이 짧다
권한을 가질 수 있게 해 주는 토큰
리프레쉬 토큰
유효기간이 길다
엑세스 토큰을 새로 발급시켜준다
OAuth
- Authorization Code를 받고
- 그 코드를 다시 보내서 AccessToken을 받아온다
인증과 권한 관리 차이
인증
사용자가 유효한지 판단 (credential, 자격증명)
ex) 지하철, 버스에 탈 수 있게 해주는 장치 (교통카드)
권한 부여
어떤 권한을 확득할 수 있는지 결정 (무엇을 할 수 있는지 지정)
ex) 장애인석, 경로석, 임산부석에 않을 권한을 획득
