[인증/보안] 기초

HTTPS

• HTTP + Secure Socket Layer (HTTP over SSL)

• 인증서

• CA

• 비대칭키 암호화, 대칭키 암호화를 혼용하여 사용

인증서

브라우저가 데이터를 제공한 서버가 정말로 데이터를 보냈는지 인증을 확인하는 용도

• 데이터 제공자의 신원 보장

• 도메인 종속

CA

인증서를 발급하는 공인된 기관 (Certificate Authority)

• 엄격하게 공인된 기관들

• 브라우저별로 신뢰하는 CA의 정보를 가지고 있어 차이가 존재함

• 자격이 유지되는 것이 아니라 박탈당할 수도 있음

암호화

대칭키 방식

• 양쪽 공통의 비밀키를 공유하여 데이터를 암·복호화

비대칭키 방식

• 공개키와 비밀키를 가지고 상대가 나의 공개 키로 암호화한 테이터를 개인이 가진 비밀 키로 복호화

클라이언트 <-> 서버간 데이터 전달

대칭키를 사용하지만, 탈취의 위험이 있기에 대칭키를 주고 받을 때 비대칭키 방식으로 주고 받는다.

• 중간에 대칭키가 탈취되더라도, 개인키가 없기에 복호화할 수 없다.

Hashing

어떤 문자열에 '임의의 연산'을 적용하여 다른 문자열로 변환하는 것

• 해시값을 해독할 때에는 긴 시간이 걸려야 하지만, 만드는데에는 오래 걸리지 않아야 함

• 모든 값은 고유한 해시값을 가져야 하며, 서로 다른 해시값이어야 함

• 대표적인 해시 알고리즘: SHA-1, SHA-256

• SHA-256은 입력값에 상관없이 출력값의 길이가 항상 256비트이다.

Salt

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

• 해싱만으로는 매번 동일한 결과가 나와 해시된 값을 원래 테이블(레인보우 테이블)로 만들어 복호화해버리는 경우가 생김

• 원본값에 임의로 약속된 '별도의 문자열'을 추가하여 해싱을 진행하면 기존 해시값과 전혀 다른 해시값이 반환되어 알고리즘의 노출에도 원본값을 보호할 수 있음

주의점

• 유저와 패스워드 별로 유일한 값을 가져야 함

• 사용자 계정을 생성할 때와 비밀번호를 변경할 때마다 새로운 임의의 Salt를 사용해서 해싱

• 재사용 금지

• DB의 유저 테이블에 같이 저장되어야 함

Cookie

서버에서 클라이언트에 데이터를 저장하는 방법 중 하나이다. 서버가 원한다면 클라이언트의 쿠키를 이용하여 데이터를 가져올 수 있다.

1. 서버가 클라이언트에 데이터를 저장할 수 있다.

특정 조건을 만족하는 경우에만 다시 가져올 수 있다.

2. 쿠키를 이용한 상태 유지

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

기본적으로 쿠키는 오랜 시간 유지될 수 있고, 자바스크립트를 이용하여 쿠키에 접근할 수 있기에 민감한 정보를 담는 것은 위험한다.

쿠키 설정

Domain

도메인은 www.naver.com과 같은 서버에 접속할 수 있는 이름이며, 쿠키 옵션에서 도메인은 포트 및 서브 도메인의 정보, 세부 경로를 포함하지 않는다.

즉, http://www.localhost.com:8080/users/login이라는 URL이 있다면, 해당 도메인은 localhost.com이 된다.

Path

세부 경로는 서버가 라우팅할 때 사용하는 경로이다.

위 URL에서 Path는 /users/login이 된다.

명시하지 않는다면 기본적으로 /로 설정된다.

설정된 Path를 모두 만족한다면, Path 뒤에 있는 추가적인 경로는 사용 가능하다.

• /users/login/velog ( O )
• /users/velog ( X )

MaxAge or Expires

쿠키가 유효한 기간을 정하는 옵션이다.

MaxAge는 앞으로 몇 초 동안 쿠키가 유효할지를 설정하는 옵션이다.
Expires는 MaxAge와 비슷하지만 언제까지 유효한지 Date를 지정한다.

이후 지정된 시간, 날짜를 초과하면 쿠키는 자동으로 파괴된다.

• 영속성 쿠키: MaxAge,Expires 옵션이 없는 쿠키로, 브라우저가 실행 중일 때 사용할 수 있는 임시 쿠키이다. 브라우저를 종료하면 삭제된다.

• 세션 쿠키: 브라우저의 종료 여부와 상관 없이 지정된 유효 기간만큼 사용가능하다.

Secure

쿠키를 전송해야 할 때 사용하는 프로토콜에 따른 쿠키 전송 여부를 결정하는 옵션이다.

• True: HTTPS를 사용하는 경우에만 전송할 수 있다.

• False: 프로토콜에 상관없이 모두 쿠키를 전송할 수 있다.

HttpOnly

자바스크립트에서 브라우저의 쿠키에 접근 여부를 결정한다.

• True: 자바스크립트에서는 쿠키에 접근이 불가

• False: 자바스크립트에서 쿠키에 접근이 가능하여 XSS 공격에 취약

SameSite

Cross-Origin의 요청을 받은 경우 요청에서 사용한 메소드와 해당 옵션의 조합으로 서버의 쿠키 전송 여부를 결정한다.

• Lax: Cross-Origin 요청이면 GET 메서드에 대해서만 쿠키를 전송

• Strict: Cross-Origin이 아닌 same-site인 경우에만 쿠키를 전송

• None: 항상 쿠키를 보내줄 수 있지만, Secure 옵션이 필요

요청을 보낸 URL이 서버의 도메인, 프로토콜, 포트와 같은 경우 Same-Site이며 다르면 Cross-Origin으로 분류한다.

서버 -> 클라이언트로의 첫 쿠키 전송은 헤더에 Set-Cookie라는 프로퍼티에 쿠키를 담아 전송한다.

클라이언트 -> 서버로의 쿠키 전송은 헤더에 Cookie 프로퍼티를 담아 전송한다.

Session

세션이란?

사용자가 인증에 성공한 상태를 세션이라고 부른다.

서버와 클라이언트의 연결이 활성화된 상태이다.
서버가 클라이언트가 사용자 인증에 성공했음을 알고 있고, 클라이언트는 인증의 성공을 증명할 수 있는 수단을 가지고 있음을 의미한다.

특징

서버는 인메모리나 세션 스토어 같은 일종의 저장소에 세션을 저장한다.
세션이 만들어지면, 각 세션을 구분하기 위한 세션 아이디가 주어지고, 대게 클라이언트가 세션 성공을 증명할 수단으로서 사용된다.

웹 사이트에서 로그인을 유지하기 위한 수단으로 쿠키를 사용하고, 쿠키에 서버에서 발급한 세션 아이디를 저장한다.

로그아웃의 구현

로그아웃을 구현하기 위해서는 서버와 클라이언트 두 곳에서 작업이 이루어진다.

서버는 세션 정보를 삭제하고, 클라이언트 쿠키의 세션 아이디를 무효한 값으로 갱신해야 한다.

Cookie vs Session

	설명	접속 상태 저장 경로	장점	단점
Cookie	쿠키는 http의 stateless한 것을 보완해주는 도구	클라이언트	서버의 부담을 덜어준다.	쿠키 그 자체로는 인증이 될 수 없음
Session	접속 상태를 서버가 가지며(stateful), 접속 상태와 권한 부여를 위해 세션 아이디를 쿠키로 전송한다.	서버	신뢰할 수 있는 유저인지 서버에서 추가로 확인 가능	하나의 서버에서만 접속 상태를 가져 분산에 불리함