이게 무엇?
인증/보안
Before You Learn
: 네트워크 및 HTTP 관련 지식
: 요청/응답 형태로 이루어지는 HTTP의 클라이언트 - 서버 모델에 대한 이해
: HTTP 특징(무상태성)에 대한 이해
HTTPS
: Hyper Text Transfer Protocol Secure Socket Layer 약자
: HTTP over SSL(TLS), HTTP over Secure
: HTTP + SSL/TLS
: HTTP 요청을 SSL/TLS 알고리즘을 이용해 HTTP 통신을 하는 과정에서 데이터를 암호화하여 전송하는 방법
HTTPS 목적
목적1 암호화
: 제 3자가 서버와 클라이언트가 주고받는 정보를 탈취할 수 없도록 함
-서버와 클라이언트는 서로가 합의한 방법으로 데이터를 암호화하여 주고 받음
-중간에 제 3자에게 데이터가 탈취되더라도 그 내용을 알아볼 수 없음
if. HTTP, 요청 및 응답이 탈취된다면 전달되는 데이터 내용을 알아볼 수 없음
but. 데이터 암호화하여 전송하는 HTTPS 사용 시, 암호화되어 전송되므로 유출 가능성 낮아짐
HTTPS에서는 클라이언트와 서버가 데이터를 주고 받을 때, 비대칭키 방식과 대칭키 방식을 혼용하여 사용함
대칭키 방식
: 양쪽이 공통의 비밀 키를 공유하여 데이터를 암호화 및 복호화하는 것
비대칭키 방식
: 각각 공개키와 비밀키를 가지고 상대가 나의 공개키로 암호화한 데이터를 개인이 가진 비밀키로 복호화 하는 것
(복호화: 암호화된 데이터를 함호화 되기 전의 형태로 바꾸는 처리)
클라이언트와 서버가 데이터를 주고받을 때는 대칭키를 사용
왜냐면? 비대칭키 알고리즘은 대칭키 알고리즘보다 훨씬 복잡함
그래서 대칭키를 사용하여 데이터를 암호화/복호화하는 것이 컴퓨터에 부담을 덜 주기 때문
그런데 대칭키를 주고받다가 정보가 탈취되면?
암호화하든 안하든 모든 데이터에 대해 복호화 가능하게 됨
그래서 HTTPS는 대칭키를 주고 받을 때는 비대칭키 방식으로 주고 받음
: 비대칭키는
공개키로 암호화한 정보에 대해 개인이 가진 비밀키로만 풀 수 있으므로 중간에 대칭키가 탈취되어도 개인키 없이는 복호화 불가능하기 때문
"HTTPS는 대칭키와 비대칭키 방식을 이용해 데이터를 암호화 함"
목적2 인증서
: 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있음
: 인증서는 서버의 신원 보증(접속한 사이트가 유사하게 만든 가짜 사이트가 아님을 보장하는 역할)
-인증서를 발급해주는 제 3자인 공인된 기관= Certificate Authority, CA
"인증서가 CA의 비밀키로 암호화되어 있으므로 CA의 공개키로 복화화 가능함
따라서 해당 CA에서 발급한 인증서라는 것을 보증할 수 있음"
-TLS 또는 SSL : 서버와 클라이언트 간의 CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 아우른 프로토콜
(SSL과 TLS는 사실상 동일한 규약, SSL이 표준화되면서 바뀐 이름=TLS)
HTTPS 특징
특징1 기밀성 : 비밀이 잘 지켜지는지
=메시지를 가로챌 수 없음 =타인이 읽을 수 없음
특징2 무결성 : 다른 사람에게 메시지를 보낼 때 내용이 변하지 않음
=메시지가 조작되지 않음 =타인이 수정할 수 없음
in code
-인증서를 resources 폴더에 이동
-application.properties 파일에 관련 설정을 추가
server.ssl.key-store=classpath:localhost.p12 #인증서 경로를 적음
server.ssl.key-store-type=PKCS12 #인증서 형식을 적음
server.ssl.key-store-password=changeit #인증서 비밀번호를 적음
#비밀번호인 changeit은 비밀번호를 설정하지 않았을 때의 기본값
#인증서 비밀번호는 인증서를 생성할 떄 설정하거나 생성 후 변경할 수 있음- 클라이언트에서 서버로 메시지를 보냄
- 서버에서 클라이언트로 메시지에 대한 답장을 보냄
- 서버에서 클라이언트로 인증서(서버의 공개키) 등을 보냄
- 클라이언트가 인증서(서버의 공개키)를 확인
(신뢰할 수 있는 인증 기관에서 발급했는지) - 클라이언트는 대칭키를 만들고,
서버에 서버의 공개키를 보냄(내용은 클라이언트의 대칭키) - 서버가 개인키를 가지고 클라이언트가 보낸 것을 오픈함
- 서버는 클라이언트에게 메시지를 클라이언트가 보낸 대칭키로 암호화해서 전송
- 클라이언트가 대칭키를 통해 메시지를 복호화
- 이후로는 클라이언트와 서버가 대칭키를 통해 통신함
개인키는 누구에게도 발송하지 않음
(개인키로 암호화, 공개키로 오픈 : 전자서명, 누가 보냈는지 확인하기 위해, 출처용, 목적이 암호화가 아님)
(공개키와 개인키(=비밀키/비공개키)는 세트로 만들어짐)
(비대칭키 암호화 == 공개키 암호화)
Hashing 해싱
if. 인증 과정을 거치지 않으면
누구나 모든 정보에 접근할 수 있기 때문에 보안 이슈 발생 가능함
if. 비밀번호를 이용한 인증 흐름 설계
비밀번호를 DB에 저장해서 암호화한다면 문제 발생하지 않음
암호화 : 일련의 정보를 임의의 방식을 사용하여 다른 형태로 변환하여 해당 방식에 대한 정보를 소유한 사람을 제외하고 타인이 이해할 수 없도록 '알고리즘'을 이용해 정보를 관리하는 과정
Hashing : 어떠한 문자열에 '임의의 연산'을 적용하여 다른 문자열로 변환하는 것
해시 알고리즘의 특징
특징1 모든 값에 대해 해시 값을 계산하는데 오래 걸리지 않아야 한다
-해시값을 해독decoding할 때에는 많은 시간이 걸려야 하지만, 해시값을 만드는데 오래 걸리지 않아야함
-오래 걸린다면, 로그인할 때마다 유저는 오래 기다려야 하기 때문에~
특징2 최대한 해시값을 피해야 하며, 모든 값은 고유한 해시값을 갖는다
-Hashing 해싱은 어떠한 수학적 연산(알고리즘)을 통해 입력받은 문자열을 다른 문자열로 변환함
-아주 낮은 확률로 전혀 다른 문자임에도 같은 해시값을 갖는 경우가 존재
-최대한 이런 상황이 발생하지 않도록 하는 알고리즘이 배포되어 있음
특징3 아주 작은 단위의 변경이라도 완전히 다른 해시값을 가져야 한다
-문자가 대문자에서 소문자로 변경되더라도 완전 다른 해시값을 가져야 해시값으로 추측할 수 없게 해야함
-완전 다른 값으로 반환해야 함
대표적 해시 알고리즘
:SHA1, SHA256(대표적으로 많이 사용됨), SHA512 등 존재
:숫자가 클수록 해시값이 복잡함=보안이 강화됨
Salt
salt
: 암호화 해야하는 값에 어떤 '별도의 값'을 추가해서 결과를 변형시킴
if. Hashing만 이용할 경우
안전해보이지만 특정 알고리즘을 통한 해시값이 항상 같기 때문에 해시값-원본값 대조한 테이블로 원본 비밀번호를 알아내는 경우가 있음
-이러한 경우를 위해서 기존 문자열에 Salt값을 추가함
-추가한 값을 Hashing하면 예상하기 힘든 전혀 다른 문자열(해시값)이 만들어짐
-Salt 이용하면 사용한 알고리즘이 노출되더라도 원본 비밀번호 데이터를 보호할 수 있음
기존: (암호화 하려는 값) -> (해시값)
Salt 사용 : (암호화 하려는 값) + (Salt 값) -> (해시값)
Salt 사용 시 주의점
주의1 Salt는 유저와 패스워드 별로 유일한 값을 가져야 함
주의2 사용자 계정을 생성할 때와 비밀번호를 변경할 때마다 새로운 임의의 Salt를 사용해서 해싱해야 함
주의3 Salt는 절대 재사용하지 말아야 함
주의4 Salt는 DB의 유저 테이블에 같이 저장되어 함
Cookie
Cookie 쿠키
: 서버에서 클라이언트에 데이터를 저장하는 방법의 하나
쿠키를 이용하는 것=
단순히 서버에서 클라이언트에 쿠키를 전송하는 것만 의미하지 않고 클라이언트에서 서버로 전송하는 것도 포함됨
쿠키 특징 : 서버가 클라이언트에 데이터를 저장할 수 있음
하지만 데이터 저장 후 아무 때나 데이터를 가져올 수 없음
데이터를 저장한 이후 특정 조건이 만족하는 경우에만 가져올 수 있음
쿠키 옵션
옵션1 Domain 서버와 요청의 도메인이 일치하는 경우 쿠키 전송
쿠키 옵션에 도메인이 존재한다면,
클라이언트에서는 쿠키의 도메인 옵션과 서버의 도메인이 일치해야만 쿠키를 전송할 수 있음
if. 요청해야 할 URL = http://www.localhost.com:3000/users/login
Domain = localhost.com
서브 도메인 = www
포트번호 = 3000
옵션2 Path 서버와 요청의 세부 경로가 일치하는 경우 쿠키 전송
if. 요청해야 할 URL = http://www.localhost.com:3030/users/login
path 세부 경로(서버가 라우팅할 때 사용하는 경로) = /users/login
(명시하지 않으면 기본적으로 / 으로 설정)
if. path = /users 로 설정
-> /users/codestates : 쿠키 전송 가능
-> /posts/codestates : path 옵션(/users) 만족하지 못함 : 쿠키 전송 불가
옵션3 MaxAge or Expires 쿠키 유효기간 설정 옵션
MaxAge : 앞으로 몇 초 동안 쿠키가 유효한지 설정
Expires : 언제까지 유효한지 Date를 지정(클라이언트 시간 기준)
-지정된 시간/날짜 초과 시 쿠키 자동 파괴
위 옵션 여부에 따라 세션 쿠키 Session Cookie/ 영속성 쿠키 Persistent Cookie로 나뉨
-세션 쿠키 Session Cookie
: MaxAge/Expires 옵션이 없는 쿠키
: 브라우저가 실행 중일 때 사용할 수 있는 임시 쿠키
: 브라우저 종료 시 해당 쿠키 삭제됨
-영속성 쿠키 Persistent Cookie
: 브라우저 종료 여부와 관계없이 MaxAge/Expires에 지정된 유효 시간만큼 사용 가능한 쿠키
옵션4 Secure HTTPS에서만 쿠키 전송 설정 옵션
: 옵션값 true :HTTPS 프로토콜 이용하는 경우에만 쿠키 전송
: 옵션없으면 프로토콜 상관없이(Http/Https) 모두 쿠키 전송 가능
옵션5 HttpOnly 자바스크립트의 쿠키 접근 가능 여부 설정
: 옵션값 true :자바스크립트에서 쿠키 접근 불가능
: 기본값 false :자바스크립트에서 쿠키 접근 가능 : XSS 공격에 취약함
옵션6 SameSite 같은 사이트에서만 쿠키 사용할 수 있게 설정
: Cross-Origin 요청받은 경우, 요청에서 사용한 메서드와 해당 옵션(GET, POST, PUT PATCH...)의
조합으로 서버의 쿠키 전송 여부를 결정하게 됨
: Lax :Cross-Origin 요청이면 'GET'메서드에 대해서만 쿠키 전송
: Strict :Cross-Origin 아니면 same-site인 경우에만 쿠키 전송
: None :항상 쿠키 보낼 수 있음 : 꼭 Secure 옵션 필요
쿠키 특성을 이용하여 서버는 클라이언트에 인증정보에 담은 쿠키를 전송
클라이언트는 전달받은 쿠키를 요청과 같이 전송하여 Stateless한 인터넷 연결을 Stateful 하게 유지 가능함
하지만 기본적으로 쿠키는 오랜 시간 동안 유지될 수 있고,
자바스크립트를 이용해 쿠키 접근이 가능함
: 쿠키에 민감한 정보를 담는 것은 위험함
Session
사용자가 웹사이트에서 로그인 할 때 정확하게 입력했다면 :서버는 인증에 성공했다고 판단함
이후 장바구니에 물품을 추가하는 등 또 인증이 필요한 작업을 요청할 경우 :서버가 해당 유저가 인증에 성공했음을 알고 있다면, 유저가 매번 로그인할 필요가 없을 것
(인증에 따라 리소스의 접근 권한이 달라짐)
-서버 : 사용자가 인증에 성공했음을 알고 있어야함
-클라이언트 : 인증 성공을 증명할 수단을 가져야 함
session 세션 : 사용자가 인증에 성공한 상태/ 서버와 클라이언트간의 연결이 활성화된 상태
(서버는 일종의 저장소에 세션을 저장함)
세션이 만들어지면 세션을 구분할 수 있는 세션 아이디도 만들어지는데
보통 클라이언트에 세션 성공을 증명할 수단으로써 세션 아이디를 전달함
: 이때 웹사이트에서 로그인을 유지하기 위한 수단으로 쿠키를 사용
: 쿠키에는 서버에서 발급한 세션 아이디를 저장함
쿠키를 통해 유효한 세션 아이디가 서버에 전달되고,
세션 스토어에서 해당 세션이 존재하면
서버는 해당 요청에 접근 가능하다고 판단함
but 쿠키에 세션 아이디가 없을 경우, 서버는 해당 요청이 인증되지 않았음을 알림
로그아웃을 하려면?
두 가지 작업 필요
-서버 : 세션 정보를 삭제해야 함
-클라이언트 : 쿠키를 갱신해야 함
