HTTPS
-
HTTP는 누군가가 요청한 내용을 볼 수 있었다. 하지만, 이러한 내용을 암호화시키는 것이 바로 HTTPS이다. HTTPS는 SSL(Secure Socket Layer) 프로토콜을 이용하여 웹 브라우저와 서버가 데이터를 주고받는 방식.
1. 인증서 2. CA 3. 비대칭 키 암호화방식을 사용한다.
-
인증서에는 도메인과 응답객체 도메인을 쓰고 서버는 인증서에 해당하는 주소인지를 확인한다.
-
CA는 인증서를 발급해주는 기관이다.
-
HTTPS는 비대칭 키 암호화 방식을 따른다.
HTTPS 사용 이유
1.클라이언트는 데이터 제공자가 제공해준 데이터를 사용할 수 밖에 없다.
2.서버에 데이터 요청을 하고 이후 받은 데이터를 이용해서 화면을 렌더링하는 등의 작업을 해야한다. -
이러한 이유로 데이터 제공자의 신원을 보장받을 수 있기 때문에 사용한다.
MKCERT
-
로컬환경에서 신뢰할 수 있는 인증서를 만들 수 있음
HASH
-
로그인의 경우 데이터를 요청할 때 사용자의 정보에 대한 내용을 받는다. 서버는 db에서 이메일과 패스워드를 받고, 패스워드는 사용자외 누구나 알아선 안된다. db에서 조차도 패스워드에 대한 내용이 보이면 안된다. 해당 문제에 대한 해결 방법이 바로 해시화를 이용한 방법이다.
-
해시(Hash)는 암호화 알고리즘의 한 종류로 어떤 문자열에 "임의의 연산"을 적용하여 다른 문자열로 반환하는 알고리즘이다.
해시화의 3가지 원칙
-
모든 값에 대해 해시 값을 계산하는데 오래 걸리지 않아야한다.
-
최대한 해시 값을 피해야하며, 모든 값은 고유한 해시 값을 가진다.
-
아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야한다.
SALT
- 패스워드 같은 경우에도 우연히 해커가 레인보우 테이블(사전공격을 위한 해시값 검색에 최적화 시킨 것)을 이용한 크래킹 공격으로 해시값에 대한 내용을 해킹한다면, 아주 위험해진다. 이에 대한 대처방법은 바로 salt를 이용한 방법이다.
-
salt는 유저와 패스워드 별로 유일한 값을 가져야한다.
-
사용자 계정을 생성할 때와 비밀번호를 변경할 때마다 새로운 임의의 Salt를 사용해서 해싱해야한다.
-
Salt는 재사용 하지말아야한다.
-
Salt는 DB유저 테이블에 같이 저장되어야한다.
COOKIE
-
어떤 웹사이트에 들어갔을 때 , 서버가 일방적으로 클라이언트에 전달하는 작은 데이터이다.
-
해당 도메인에 대해 쿠키가 존재한다면, 웹 브라우저는 도메인에게 http 요청 시 쿠키와 함께 전달한다.
-
예를 들어, 여러 페이지에 나갔다 들어와도 기존의 로그인 상태가 유지되어있는 것을 확인할 수 있다. HTTP는 무상태성이지만, 이러한 상태를 유지 혹은 정보를 유지하는 방법 중 하나가 COOKIE이다.
-
쿠키는 유저가 삭제하지 않고 유효기간이 정해지지 않으면, 영원하게 존재할 수 있다. 그렇기 때문에 인증정보를 저장하기에는 좋지 않다.
COOKIE의 다양한 옵션
-
쿠키는 스크립트로 접근이 가능하기 때문에 XSS 공격에 취약하다 . 하지만 COOKIE의 옵션 중 HttpOnly를 이용한다면 이에 대한 대응이 가능하다.
-
CORS 요청의 메소드에 따라 서버가 쿠키를 전송할 지의 여부는 Samesite 옵션을 통해 설정할 수 있는데 이를 통해 csrf의 취약점을 방지할 수 있다.
- CSRF ?
다른 오리진에서 유저가 보내는 요청을 조작하는 것을 의미한다.
-> 대처방법은 CSRF 토큰, Same-Site Cookie 사용
SESSION
-
서버가 Client에 유일하고 암호화된 ID를 부여한다.
-
쿠키는 http의 무상태성을 보완해주는 도구이고, 클라이언트에 저장하게 된다. 세션은 접속상태를 서버가 가지게되고, 접속 상태와 권한 부여를 위해 세션아이디를 쿠키로 전송한다. 요약하자면, 세션은 서버에 저장하고, 쿠키는 클라이언트에 저장하므로 세션과 쿠키를 적절하게 사용해야한다는 점이다.
-
세션id를 통해 클라이언트에 인증정보를 저장하지 않고 클라이언트마다 신분증같은 세션id를 통해 쿠키에 담아 클라이언트에 전달하게 된다. 중요한 정보는 담지 않는다.
SESSION의 단점?
-
서버의 메모리에 저장하기 때문에 이용자가 상당히 많으면 메모리 저장 일정부분을 차지 하여 서버에 영향이 가게 된다. 세션과 쿠키는 같이 사용하기 때문에 HttpOnly 옵션을 사용하지 않으면, XSS에 취약하다
-
하나의 서버에서만 접속 상태를 가져서 분산에 불리하다.
TOKEN
- 토큰은 사용자 인증을 위해 정보를 서명한 것이다. 토큰은 세션과 달리 토큰에 사용자 인증을 위한 정보가 담겨있다.
SESSION과의 차이점?
- 세션 값 자체에는 정보가 담겨있지 않지만, 토큰 값에는 정보가 담겨있어 길이가 더 길다.
- 서버에 사용자 정보를 저장하지 않고, 토큰의 서명과 데이터를 검증하는 것만으로 인증이 가능하다.(클라이언트에 담을 수 있다.)
TOKEN 인증의 장점
-
무상태성 확장성(서버는 클라리언트에 대한 정보를 저장할 필요가 없다. 토큰을 헤더에 추가함으로 인증을 완료한다.)
-
안정성( 암호화한 토큰을 사용한다.)
-
어디서나 생성 가능하다. (토큰을 생성하는 서버가 꼭 토큰을 만들지 않아도 된다.)
-
권한 부여에 용이(payload 안에 어떤 정보에 접근이 가능한지 정의가 가능)
JWT(JSON Web Token)
- 토큰 인증에서 가장 많이 사용되는 인터넷 표준
- 데이터들이 JSON 형태로 작성되며, 데이터를 비밀키 또는 공개키로 서명해서 사용한다.
Oauth
- 인증을 위한 표준 프로토콜
- 클라이언트에게 권한을 제공하는 프로세스를 단순화하는 프로토콜 중 한 방법
- 웹 어플리케이션을 다른 SNS로 통해 로그인 할 때 아이디 비밀번호를 공유한다면, 위험하기 때문에 등장한 것이 OAUTH방식이다. ( sns 로그인을 할 때 비밀번호 입력하지 않고 클릭만하면 로그인 되는 것을 생각하면됨)
OAUTH의 용어
-
GRANT TYPE : 클라이언트가 액세스 토큰을 얻는 방법, 가장 많이 쓰이는 타입이 authorization code grant Type이다.
-
Authorization Code Grant Type : 액세스 토큰을 받아오기 위해서 먼저 Authorization Code를 받아 액세스 토큰과 교환하는 기법 (보안성 강화 목적, 액세스 토큰보다 리프레시 토큰의 유효 시간이 더 길게 설정해서 사용하는 방법)
- 액세스 토큰은 일정시간 혹은 유효시간이 지나면 만료되고, 만료될 때마다 사용자에게 인증권한을 요청하는 것이 불편하기 때문에 리프레시 토큰을 활용한다.
기본적인 개념을 urclass에서 훑고 나름대로 정리해본 내용이다. 세션&쿠키 토큰 방법의 차이를 이해했고, 어떠한 방식이 장단점이 있는지 알 수 있었다. 개념에 대해 약간 애매모호한 점이 있었는데 , SPRINT를 진행하면서 좀 더 빈 개념을 이해할 수 있었다.
