인증/보안 기초

주제들
1. 회원 가입 및 로그인, 로그아웃과 같은 기능을 구현하게 됩니다. 인증(authentication)에 대해서도 알아본다.
2. 클라이언트, 서버, 데이터베이스 모두를 다루면서, Full Stack 개발 환경에서의 전체적 흐름 및 작동을 직접 확인합니다.

HTTPS

• 인증서(Certificate)
  데이터 제공자 신원 보장, 도메인 종속

• CA
  Certificate Authority, 공인 인증서 발급 기관

• 비대칭 키 암호화
  전혀 다른 키 한 쌍으로 암호화 및 복호화를 하게 된다. 한 키는 감추고 하나는 클라이언트에 공개를 한다. 데어터를 안전하게 전송을 할 수 있게 한다.

Hand Shake => 비밀 키 생성 => 상호 키 검증

인증에서 HTTPS 프로토콜을 사용해야만 하는 이유는 HTTP보다 상대적으로 안전한 방법이고, 데이터 제공자의 신원을 보장받을 수 있기 때문입니다.

• 데이터 제공자의 신원을 확인하고 보장받는 게 인증에서 중요한 이유

1. 클라이언트는 데이터 제공자가 제공해 준 데이터를 사용할 수 밖에 없습니다.
   클라이언트는 서버에 데이터 요청을 하고 이후 받은 데이터를 이용해서 화면에 렌더링하는 등의 작업을 해야 합니다.
2. 요청 및 응답을 중간에서 가로채는 중간자 공격에 취약합니다. '중간자 공격'은 클라이언트와 서버 사이에서 공격자가 서로의 요청, 응답의 데이터를 탈취 및 변조하여 다시 전송하는 공격입니다.

인증서
HTTPS 프로토콜의 또 다른 특징 중 하나는 브라우저가 응답과 함께 전달된 인증서 정보를 확인할 수 있다는 점입니다. 이러한 경고를 직접 보여줌으로써 브라우저들은 인증된 CA가 발급한 인증서를 이용하여 데이터를 제공하는 안전한 서버를 사용할 수 있게 사용자를 유도합니다.

key.pem의 경우 개인 키이므로 git에 커밋하지 말고 암호처럼 다루어야 합니다.

암호화는 일련의 정보를 임의의 방식을 사용하여 다른 형태로 변환하여 해당 방식에 대한 정보를 소유한 사람을 제외하고 이해할 수 없도록 '알고리즘'을 이용해 정보를 관리하는 과정

Hashing
어떠한 문자열에 '임의의 연산'을 적용하여 다른 문자열로 변환하는 것
1. 모든 값에 대해 해시 값을 계산하는데 오래 걸리지 않아야 한다.
2. 최대한 해시 값을 피해야 하며, 모든 값은 고유한 해시 값을 가진다.
3. 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 한다.

Salt
암호화해야 하는 값에 어떤 '별도의 값'을 추가하여 결과를 변형하는 것
1. 암호화만 해놓는다면 해시된 결과가 늘 동일
해시된 값과 원래 값을 테이블(레인보우 테이블)로 만들어서 decoding 해버리는 경우도 생긴다.
2. 원본값에 임의로 약속된 '별도의 문자열'을 추가하여 해시를 진행한다면
기존 해시값과 전혀 다른 해시값이 반환되어 알고리즘이 노출되더라도 원본값을 보호할 수 있도록 하는 안전 장치
3. 기존: (암호화 하려는 값) => (hash 값)
Salt 사용: (암호화 하려는 값) + (Salt 용 값) => (hash 값)

Salt 사용 시 주의점
1. Salt는 유저와 패스워드 별로 유일한 값을 가져야 합니다.
2. 사용자 계정을 생성할 때와 비밀번호를 변경할 때마다 새로운 임의의 Salt를 사용해서 해싱해야 합니다.
3. Salt는 절대 재사용하지 말아야 합니다.
4. Salt는 DB의 유저 테이블에 같이 저장되어야 합니다.

Cookie
어떤 웹사이트에 들어갔을 때, 서버가 일방적으로 클라이언트에 전달하는 작은 데이터

• 서버가 웹 브라우저에 정보를 저장하고 불러올 수 있는 수단
• 해당 도메인에 대해 쿠키가 존재하면, 웹 브라우저는 도메인에게 http 요청 시 쿠키를 함께 전달

Cookie Options

• Domain: 서버와 요청의 도메인이 일치하는 경우 쿠키 전송

• Path: 서버와 요청의 세부경로가 일치하는 경우 쿠키 전송

• MaxAge or Expires: 쿠키의 유효기간 설정

• HttpOnly: 스크립트의 쿠키 접근 가능 여부 결정
  쿠키는

• Secure: HTTPS 프로토콜에서만 쿠키 전송 여부 결정

• SameSite: CORS 요청의 경우 옵션 및 메서드에 따라 쿠키 전송 여부 결정
  Spring Security 관련된 자료들을 찾다보면 CSRF(Cross-Site Request Forgery) 설정을 비활성화시키라는 글을 많이 발견할 수 있습니다.

1. 김코딩이 은행 사이트에 로그인합니다.
2. 은행은 김코딩에게 유효한 토큰을 할당합니다.
3. 해커가 은행의 요청으로 가장한 위조된 요청을 보냅니다.
4. 해커의 링크를 클릭한 김코딩은 자기도 모르는 새 은행에 위조된 요청이 보내집니다.
5. 위조된 요청은 이전에 할당된 김코딩의 유효한 토큰을 통해 은행에서 실행됩니다.
   옵션에 따른 서버의 쿠키 전송 여부

• Lax: GET 메서드 요청만 쿠키 전송 가능
• Strict: 쿠키 전송 불가
• None: 모든 메서드 요청에 대해 쿠키 전송 가능

• sameSite='none' 옵션은 Secure 쿠키 옵션이 필요합니다.

쿠키를 이용하는 것은 단순히 서버에서 클라이언트에 쿠키를 전송하는 것만 의미하지 않고 클라이언트에서 서버로 전송하는 것도 포함됩니다.
서버가 클라이언트에 데이터를 저장할 수 있습니다.
서버는 쿠키를 이용하여 데이터를 저장하고 원할 때 이 데이터를 다시 불러와 사용할 수 있습니다.
데이터를 저장한 이후 아무 때나 데이터를 가져올 수 없습니다. 데이터를 저장한 이후 특정 조건들이 만족하는 경우에만 다시 가져올 수 있습니다. 이런 조건들은 쿠키 옵션으로 표현할 수 있습니다.