12주 4일차 - Auth Basic

12주 4일차 - Auth Basic

1. 배운 것

2. 내용 정리

• 프록시란, 클라이언트와 서버 사이에 대리로 통신을 수행하는 것을 가리켜 ‘프록시(Proxy)’, 그 중계 기능을 하는 서버를 프록시 서버라고 합니다. 클라이언트, 혹은 반대로는 서버가 다른 네트워크에 간접적으로 접속할 수 있기 때문에, 보안, 캐싱을 통한 성능, 트래픽 분산 등의 장점을 가집니다.

HTTPS

• 왜 HTTPS가 HTTP보다 안전한 지 이해한다.
• HTTPS의 암호화 방식에 대해 이해한다.
  • HTTPS에서 사용하는 대칭키, 비대칭키 방식에 대해 이해한다.
• 직접 로컬에서 HTTPS 인증서를 발급할 수 있다.
• Hashing이 필요한 이유에 대해 이해한다.
• 데이터베이스에 유저의 비밀번호와 같이 민감한 정보를 평문으로 저장하지 않는 이유에 대해 이해한다.
• Salt가 필요한 이유에 대해 이해한다.

HTTPS (HTTP + Secure)

HTTP 프로토콜에 암호화를 추가하여 보안성을 높인 방식.

기존 HTTP 방식은 누군가가 HTTP 요청의 내용을 그대로 들여다 볼 수 있었기에 보안에 취약하였으나 HTTPS 방식은 인증서, CA, 비대칭 키 암호화 등으로 요청 내용을 방어하여 보안성을 향상하였다.

• 대칭 키 방식: 서버와 클라이언트가 양쪽이 공통의 비밀 키를 공유하여 데이터를 암호화/복호화 하는 것.
• 비대칭 키 방식: 각각 공개키와 비밀키를 가지고 상대가 공개키로 암호화한 데이터를 개인이 가진 비밀키로 복호화하는 것.
• 비대칭 키 방식은 대칭 키 방식보다 알고리즘이 훨씬 복잡하기 때문에 컴퓨터에 부담을 주므로 처음에 대칭키를 주고받을 때에만 비대칭키 방식으로 주고받아 리소스 사용을 줄이고 이후에 대칭키가 찰취되더라도 개인키가 없이는 복호화가 불가능하므로 보안성을 유지한다.
• 인증서 : 데이터를 보내준 서버가 정말로 데이터를 보내준 서버인지 인증, 확인 용.
  • 인증서의 내용에 서버의 도메인 정보가 포함되어 있어 데이터 제공자의 인증을 용이하게 한다.
  • 클라이언트의 요청을 받으면 서버는 인증서와 함께 응답을 전송한다.
  • 응답을 받은 클라이언트는 인증서에 작성된 도메인 === 응답객체의 도메인 을 비교한다. 둘이 일치한다면 서버가 정말로 데이터를 제공해 준 서버인지 확인 가능.
  • 이를 통해 제3자 공격으로 인한 도메인 변경 시 클라이언트는 서버가 데이터를 제공해 준 서버가 아님을 알 수 있다.
• CA (Certificate Authority) - 공인 인증서 발급 기관
  • 브라우저마다 각각 신뢰하는 CA의 정보를 가지고 있다.
  • 따라서 각 브라우저마다 인증서가 차이가 있음.
  • 인증서의 자격이 항상 유지되는 게 아니라 박탈될 수도 있다.
• 비대칭 키 암호화
  • 어느 하나의 키로 암호화를 진행 시 쌍이 되는 다른 키로 복호화를 진행해야 함.
  • 즉 키 A로 암호화를 하면 암호화 키 A와 쌍인 키 B로만 복호화 가능.
  • 둘 중 하나의 키는 비공개, 다른 하나는 클라이언트에게 공개하여 안전하게 데이터를 전송 가능.
  • 하지만 모든 통신에 대해 공개 키 방식을 사용하지는 않는다.
  • 이는 매우 연산이 복잡한 알고리즘이기 때문에 통신의 초창기에서만 비밀 키로 사용하기 위한 키를 만들기 위해 사용된다.

HTTPS의 통신 과정 3단계

아래 3단계를 거쳐 HTTPS 연결이 성립된다. 이 과정에서 중간자 공격을 감지할 수 있다.

클라이언트가 서버로부터 받은 암호화된 내용을 복호화하는데 성공한다면 성공적으로 비밀 키가 만들어진 상태이이고 HTTPS 연결이 성립된 상태.

1. Hand Shake - 서로를 확인하는 단계
   1. 클라이언트: 서버에게서 받은 인증서를 브라우저나 os에 내장된 CA 리스트를 통해 인증서를 검증하고 인증된 CA에서 발급한 인증서가 아닐 경우 화면에 경고창을 띄움.(ERR_CERT_AUTHORITY_INVALID) 인증서의 도메인과 데이터를 세공하는 서버의 도메인이 일치한다면 CA 기관의 공개키로 서버 인증서를 복호화.
   2. 서버: CA의 비밀키로 암호화된 인증서 전달
2. 비밀 키 생성
   1. 클라이언트: 전달받은 키를 이용해 서버와 키를 만들어낼 임의의 정보를 암호화하여 전송
   2. 서버: 임의의 정보를 암호화하여 전송
3. 상호 키 검증
   1. 과정 2를 복호화하는데 성공하면 실제 데이터 송수신에 필요한 암호화 및 복호화 진행

Hashing

서버는 클라이언트가 입력한 비밀번호를 평문으로 저장해선 안된다. 따라서 해싱하여 암호화하여 저장해야 한다.

이 때 해싱은 어떠한 문자열에 ‘임의의 연산'을 적용하여 다른 문자열로 변환하는 것을 말한다.

DB가 해킹당하더라도 비밀번호는 해싱된 상태로 저장되어 있기 때문에 해당 값으로 로그인 할 수는 없다.

Salt

암호화해야 하는 값에 어떤 ‘별도의 값'을 추가하여 결과를 변형하는 것을 말함.

암호화만 진행한다면 어떠한 값에 대해 해싱한 값이 항상 동일하기 때문에 알고리즘이 노출되면 해킹되었을 때 복호화되어 피해가 발생할 수가 있기 때문에 암호화 하려는 값 + Salt용 값 ⇒ hash 값 을 만든다.

즉 기존 해시값과 전혀 다른 해시값이 반환되어 알고리즘이 노출되더라도 원본값을 보호하는 안전 장치가 Salt 이다.

• 레인보우 테이블 : 특정 입력값을 해싱한 결과를 대량으로 모아놓은 표. 이를 대비하기 위해선 개발자만이 아는 별도의 값, 즉 Salt를 추가하여 해싱한 값이 달라지도록 해야 함.

Cookie/ Session

• 쿠키의 작동 원리를 이해할 수 있다
• 회원가입 및 로그인 등의 유저 인증에 대해 설명할 수 있다.
• 세션의 개념을 이해할 수 있다.
• 쿠키와 세션은 서로 어떤 관계이며, 각각이 인증에 있어서 어떤 목적으로 존재하는지 이해할 수 있다.
• 세션의 한계를 이해할 수 있다.

Cookie

• Cookie 란?
  • 어떤 웹사이트에 들어갔을 때, 서버가 일방적으로 클라이언트에 전달하는 작은 데이터를 말한다.
  • 서버가 웹 브라우저에 정보를 저장하고 불러올 수 있는 수단이 된다.
  • 해당 도메인에 대해 쿠키가 존재하면 웹 브라우저는 도메인에게 http 요청 시 쿠키를 함께 전달.
  • 장기간 보존해야 하는 사용자 맞춤 정보 (로그인 유지, 테마, 마케팅 정보 등) 저장에 적합하다.
  • 해싱 등 암호화가 되어있어야 함.
  • 민감정보는 쿠키로 저장하지 않아야 한다.
• Cookie 전달 방법
  • 서버의 응답 헤더에서 Set-Cookie 프로퍼티에 쿠키의 이름, 값, 경로 등의 옵션을 저장한다.
  • 쿠키가 당긴 응답을 받은 클라이언트는 응답 헤더에 존재하는 Set-Cookie 프로퍼티를 확인하고 그 안에 저장된 쿠키의 이름, 값 등의 정보를 서버에게 전달한다.
  • 즉 서버가 쿠키를 저장하면, 이후 클라이언트의 매 요청에 자동으로 쿠키가 함께 전송된다.
  • 이를 통해 로그인 상태 유지, 설정한 테마 유지 등이 가능해진다.
• Cookie Options
  • Domain : 서버 === 요청한 도메인 ⇒ 쿠키 전송
  • Path : 서버 === 요청의 세부경로 ⇒ 쿠키 전송
  • MaxAge or Expires : 쿠키의 유효기간을 설정하는 옵션.
  • HttpOnly : 자바스크립트의 쿠키 접근 가능 여부 설정 옵션. true 시 접근 불가. 기본값 false.
  • Secure : HTTPS 프로토콜에서만 쿠키 전송 여부 결정 옵션. true 시 HTTPS를 이용할 경우만 쿠키 전송.
  • SameSite : CORS 요청의 경우 옵션 및 메서드에 따라 쿠키 전송 여부 결정 옵션. (CSRF 공격 방지) 이때 same-site는 요청을 보낸 Origin과 서버의 도메인, 프로토콜, 포트가 같은 경우를 말합니다. 이 중 하나라도 다르다면 Cross-Origin으로 구분됩니다.
    • Lax : 사이트가 달라도 GET 메서드 요청만 쿠키 전송 가능
    • Strict : 사이트가 다르면 쿠키 전송 불가
    • None : 사이트가 달라도 모든 메서드 요청에 대해 쿠키 전송 가능
      • sameSite=’none’ 옵션은 보안성이 낮으므로 Secure 쿠키 옵션이 필요하다.

이러한 쿠키의 특성을 이용하여 서버는 클라이언트에 인증정보를 담은 쿠키를 전송하고, 클라이언트는 전달받은 쿠키를 서버에 요청과 같이 전송하여 Stateless한 인터넷 연결을 Stateful하게 유지할 수 있습니다.

하지만 기본적으로 쿠키는 오랜 시간 동안 유지될 수 있고, HttpOnly 옵션을 사용하지 않았다면 자바스크립트를 이용해서 쿠키에 접근할 수 있기 때문에 쿠키에 민감한 정보를 담는 것은 위험합니다.

---

Session

사용자가 인증에 성공한 상태(ex: 로그인 성공) 를 세션이라고 부른다.

쿠키는 데이터를 클라이언트에서 저장하지만 세션은 데이터를 서버에서 저장한다.

서버가 클라이언트에 유일하고 암호화된 ID를 부여함. 중요 데이터는 서버에서 관리한다.