TIL 21.06.28

Jaemin Jung·2021년 7월 1일

Today I Learned

목록 보기

48/62

오늘한일

http에 암호화 개념이 추가된 https를 알게되었고,
Hashing과 cookie, session등을 추가적으로 배웠다.
이를 통한 과제를 수행하였는데 처음으로 해결을 못해본 스프린트다.
그래도 계속 붙들고 있어보는중..
이해하기위해서 블로깅이 며칠 밀리는중이다.

Achievement goals

암호화와 hashing, salting 등의 개념을 이해할 수 있다.
HTTP와 HTTPS의 차이점을 이해할 수 있다.
권한 부여(Authorization)와 인증(Authentication)에 대해 이해할 수 있다.
쿠키의 작동 원리를 이해할 수 있다

HTTPS

HTTPS는 Hyper Text Transfer Protocol Secure의 약자로 HTTP 프로토콜의 암호화된 버전이다.
기존에 HTTP 요청은 중간 과정에서 어떤 메세지를 전달하는지 확인이 가능하다.
만약 서버로 로그인 요청을 하게 된다면 중요한 개인 정보들이 쉽게 노출 될 수 있었다.
이에 대해서 HTTP 요청을 SSL 혹은 TLS라는 알고리즘을 이용해,
HTTP 통신을 하는 과정에서 내용을 암호화하여 데이터를 전송 하는 방법인 HTTPS가 나오게 되었다.

http + secure = https

클라이언트는 어떤 임의의 데이터를 생성해서 서버에 보낸다.
서버는 응답으로 임의의 데이터와 인증서를 클라이언트에 보낸다.
클라이언트는 인증서가 진짜인지 브라우저에 내장된 CA들의 정보를 통해 확인한다.
여기까지의 과정을 Hand Shake라고 한다.

인증서 (CA)

데이터를 제공한 서버가 정말 데이터를 제공하는 서버인지 인증 확인하는 용도이다.
서버는 인증서와 함께 응답을 전송한다.
클라이언트는 인증서에 도메인과 응답객체 도메인이 같은지 확인한다.
중간자 공격을 하면 인증서의 도메인이 변경되어 서버가 안전하지 않다는 화면을 보여준다.
브라우저 주소창에 보이는 좌물쇠 버튼을 클릭하면 인증서를 확인 가능하다.
CA는 공인 인증서 발급 기관으로 앞서 작성하였던 인증서를 발급하는 기관이다.

비대칭 키 암호화

HTTPS는 전혀 다른 키 한쌍으로 암호화 및 복호화 가능
a키로 특정 데이터를 암호화 한다면, 복호화할때는 b키가 필요한 방식이다.

그래서 HTTPS를 이용하는 서버는 두 키중 하나는 공개하고 하나는 비공개하여
데이터를 안전하게 전송 하도록 보호한다.

로직

사용자는 공개키로 비밀번호를 암호화해서 서버에 보낸다.
(이 과정에서 중간에 다른 사용자가 같은 공개키로 복호화하려 해도 불가능하기에 데이터는 안전하다.)

서버에서는 비공개키로 암호화된 데이터를 보내주며, 이는 공개키로 복호화가 가능하다.
(따라서 악의적인 목적으로 실제 서버를 위장한 도메인에서 악성 데이터를 보내도,
이는 서버의 공개키로 풀리지가 않기 때문에 외부 공격에도 안전하다.)

Hashing

클라이언트에서 이메일과 비밀번호를 가지고 정보를 요청할때
서버는 데이터베이스에서 해당 이메일과 비밀번호를 검증하고 요청한 데이터를 가져와
응답으로로 서버에게 넘겨준뒤 서버가 클라이언트에게 넘겨준다.

이때 해커가 중간 과정에서 공격을 하면 이메일까지는 괜찮겠지만 비밀번호가 그대로 노출된다.
이를 방지하기 위해서 비밀번호를 암호화 해서 전송한다.

Hashing은 암호화 과정이라고 말할 수 있겠다.
인련의 정보를 임의의 알고리즘 방식을 사용하여 다른 형태로 변환하여 해당 정보를 전달한다.
예시 -> bicycle => dkezeng 넘겨받은 알파벳 위치를 변경하여 반환

Hashing 조건

모든 값에 대해 해시 값을 계산하는데 오래걸리지 않아야 한다.
최대한 해시 값을 피해야 하며, 모든 값은 고유한 해시 값을 가진다.
아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 한다.

대표적으로 sha1알고리즘을 이용하며 요즘은 sha256이상을 사용한다.
sha1은 컴퓨터 성능의 발전으로 어느정도 복호화가 가능해졌다 -> rainbow table로 이를 확인 가능

salt

앞서 적은것을 바탕으로 Hashing만으로는 완벽한 보안이라고 말하기 어렵다고 할 수 있다.
그래서 이러한 Hashing된 데이터에 salt라는것을 추가한다.
salt는 암호화해야 하는 값에 어떤 별도의 값을 추가하여 결과를 변형하는 것을 말한다.
원본값에 임의로 별도의 문자열을 추가하여 Hashing을 진행한다면 기존 hash값과 전혀 다른 해시값이 나오기에 좀더 안전한 암호값이 되는것이다.

password(비밀번호123) => (hash 값)
password(비밀번호123) + salt(공책) => (전혀다른 hash 값)

아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 하기 때문!

http는 stateless와 conectionless의 특징을 가지고있다.
상태를 가지고 있지 않고, 항상 연결 되어 있는것이 아니다.
이러한 특징을 보완하기위해 cookie가 등장하였다.
cookie는 웹사이트에 들어갔을 때, 서버가 일방적으로 클라이언트에 전달하는 작은 데이터를 말한다.
예를 들어서 장바구니에 저장한 상품 목록이나, 로그인 되어있는 상태는 쿠키에 의해서 유지 되는것이다.
서버는 cookie를 이용해서 데이터를 저장하고 필요할때 이 데이터를 가져올 수 있다.
cookie는 서버가 웹 브라우저에 정보를 저장하고 불러올 수 있는 수단인 것이다.

특정 조건들이 만족하는 경우에만 데이터를 사용할 수 있는데 이러한 조건들을 쿠키 옵션으로 표현 가능하다.

Domain: 서버와 요청의 도메인이 일치하는경우 쿠키 전송
Path: 서버와 요청의 세부 경로가 일치하는 경우 쿠키 전송
MaxAge or Expires: 쿠키의 유효기간 설정 -> 일정시간 후 자동 소멸
HttpOnly: 스크립트의 쿠키 접근 가능 여부 결정 -> 민감한정보를 담지 안흔ㄴ게 좋다
Secure: https 프로토콜에서만 쿠키 전송 여부 결정
SameSite: cors요청의 경우 옵션 및 메서드에 따라 쿠키 전송 여부 결정 -> csrf
- lax: 겟 메서드 요청만 쿠키전송
- strict: 쿠키 전송 불가
- none: 모든 메서드 요청에 대해 쿠키전송 가능 -> secure쿠키 옵션이 필요

이러한 옵션들을 지정한 다음 서버에서 클라이언트로 쿠키를 처음 전송하게 된다면
헤더에 Set-Cookie라는 프로퍼티에 쿠키를 담아 쿠키를 전송하게 된다.

이후 클라이언트 혹은 서버에서 쿠키를 전송해야 한다면 클라이언트는 헤더에 Cookie라는 프로퍼티에
쿠키를 담아 서버에 쿠키를 전송하게 된다.

Session

세션은 서버와 클라이언트가 연결이 활성화된 상태를 말한다.
만약 사용자가 정확한 아이디와 비밀번호를 입력했다면, 서버는 인증에 성공했다고 판단할것이다.
이때 "인증에 성공했음"을 서버가 알고 있다면, 매번 로그인을 할 필요가 없다.
이 "인증에 성공했음"이라는 정보를 서버에 저장하고,
확인 용도로 쓰일 세션 아이디를 쿠키로 클라이언트에 저장하여 인증 정보를 핸들링 한다.

여기서 stateless를 보완해주는 쿠키로 바로 사용하면 될텐데 session이 왜 등장하나 싶은데,
쿠키는 앞서 작성한대로 클라이언트에 정보가 저장되기때문에 보안에 취약하고,
접 삭제하거나 유효기간을 정해주지않는 이상 그 정보가 계속 남아있기 때문에 좋지 못한 방법이다.

하지만 쿠키를 이용한 Session도 단점은 존재한다.
우선 세션은 하나의 서버에서만 저장 가능하기때문에 여러 서버가 존재하는 서비스라면,
각각 서버마다 세션 아이디를 저장해야 하기에 비효율적이다.
또, 서버에 저장해야하기 때문에 그만큼 서버의 메모리를 사용하고 성능이 낮아질 우려가 크다.
마지막으로, 여전히 쿠키에 의존하기 때문에 쿠키의 한계점을 그대로 가지고있다.
예를들어서 공공장소의 pc에서 로그인을 하여 쿠키에 세션아이디가 저장되어있다면, 다른 이용자는
이를 그대로 사용할 수 있다. "세션 아이디가 저장되었다."라는 사실로 실제 사용자라고 판단하기 때문이다.

Cookie
쿠키는 그저 http의 무상태성을 보완해주는 도구
접속 상태 저장 경로 클라이언트
서버에 부담을 덜어주고 쿠키 그자체는 인증이아님
쿠키는 직접 삭제하거나 유효기간을 정해주지않는 이상 계속 남아있기 때문에 좋지 못한 인증 정보 보관 방법임

Session
세션은 접속 상태를 서버가 가짐 (stateful) 접속 상태와 권한 부여를 위해 세션아이디를 쿠키로 전송
접속 상태 저장 경로 서버
신뢰할 수 있는 유저인지 서버에서 추가로 확인 가능
하나의 서버에서만 접속 상태를 가지므로 분산에 불리
세션은 클라이언트에 암호화된 세션 아이디만을 쿠키로 전달하기때문에 중요한 데이터는 서버에 보관
인증 정보 보관이 용이