[Section 4] [인증/보안] 기초

전체 내용 목차

• HTTPS
• Hashing
• Cookie
• Session
• JWT
• 웹 보안 공격에 대하여

 

HTTPS 

Hyper Text Transfer Protocol Secure Socket layer 의 약자. 또는 HTTP over SSL(TLS), HTTP over Secure.

HTTP에 비해 보안이 강화된 프로토콜.

HTTP 요청을 "SSL" 혹은 "TLS" 알고리즘을 이용해 통신과정에서 데이터를 암호화하여 전송 하는 방법.

전송되는 데이터 자체를 암호화 하는것이다. 해싱은 특정 값(문자열)만을 암호화하는것이다.

두개는 다른점임을 인지하자.

 

 

HTTPS 프로토콜은 검증기관으로 부터 검증이 된 사이트만이 HTTPS 프로토콜을 사용 가능함.

 

• HTTPS의 사용 목적
  
  1. 데이터 암호화
     데이터를 "SSL" 혹은 "TLS" 알고리즘으로 데이터를 암호화 하므로 3자가 패킷을 중간에 탈취해도 알수가 없음.
     
     
     
     
  2. 인증된 사이트임을 확인
     HTTPS라는 프로토콜을 쓰는 사이트라는것은 이미 기관에서 검증된 사이트이므로 안전함.
• HTTPS의 기술 원리
  
  1. 대칭키
     총 키가 1개.
     서버와 클라이언트가 데이터를 주고 받을때 사용하는 방식.
     클라이언트와 서버가 같은 키를 가지고 "암호화", "복호화" 를 다 하는 방식.
     서버가 클라이언트에게 이 키를 전달해주어야 한다.
     
     EX : 키는 3.
     4라는 데이터를 클라이언트가 서버로 넘길때 X 3(키) 을하여 암호화.
     12라는 암호화 된 데이터를 서버가 받아서 / 3(키) 하여 복호화.
  2. 비대칭키 ( = 공개키)
     클라, 서버 각각 자신의 공개키, 개인키 2개씩 갖고 있으므로 총 4개의 키가 존재. 
     서버와 클라이언트가 최초에 대칭키를 주고 받을때 사용하는 방식.
     A키로 암호화 했으면 B키로만 복호화 가능.
     B키로 암호화 했으면 A키로만 복호화 가능.
     
     사용 예 :
     - 전자서명 : 개인키로 암호화, 공개키로 복호화 
     - 데이터 암호화 : 공개키로 암호화, 개인키로 복호화
     
     
     통신 과정 :
     1. 클라가 서버에게 앞으로 통신하자는 메세지를 보냄 (의미없는 데이터)
     2. 서버는 메세지를 받고 통신을 하기 위해 자신의 "공개키", "개인키"를 생성
     3. 서버는 "알겠다"는 의미의 메세지(의미없는데이터)와 클라에게 인증서, 그리고 자신의 공개키 전달.  ( "앞으로 나한테 보낼땐 이 공개키로 암호화 해서 보내줘~ " 라는 서버의 의사표현)
     3. 클라도 서버에게 자신의 공개키를 전달 ("너도 앞으로 나한테 보낼땐 이 공개키로 암호화 해서 보내줘~" 라는 클라의 의사표현
     4. 이후부터 클라에서 데이터 보낼때, 서버로부터 받은 서버의 공개키로 암호화 하여 전달. (서버는 자신의 개인키로 복호화)
     5. 서버에서 데이터 보낼때, 클라로부터 받은 클라의 공개키로 암호화 하여 전달. (클라는 자신의 개인키로 복호화)
     
     
     
  3. 인증서
     서버가 자신의 공개키와 함께 전달해주는 인증서이다.
     이 인증서는 자신의 사이트가 안전한 사이트이고, 인증되었음을 나타낸다.
     이 인증은 제 3자인 CA(Certificate Authority) 에서 인증하여 준다.
     이 인증서는 CA의 개인키로 암호화된 인증서로, 클라이언트 (브라우저) 는 CA의 공개된 공개키로 복호화하연 인증서를 확인할 수 있다.
     만약 인증되지 않은 불법 사이트가 인증서를 보내려고 해도, CA의 개인키가 아닌 다른 키로 암호화 하였기 때문에 공개된 CA의 공개키로는 복호화가 안되기 때문에, 합법적인 인증서가 아님을 알 수 있고 해당 서버가 불법 서버임을 알 수 있다.

 

//매우 유용

https://www.youtube.com/watch?v=jyZ7TQaFy_o 

 

 

참조 : https://www.youtube.com/watch?v=2_NHHMxnWoc 

 

https://www.youtube.com/watch?v=H6lpFRpyl14&t=563s 

 

 

 

Hashing

어떠한 문자열에 "임의의 연산"을 적용하여 다른 문자열로 변환하는 것.

EX : 비밀번호.

 

- 해싱의 원칙

1. 모든 값에 대해서 해싱하는데 오래 걸리지 않아야 한다.
2. 최대한 기존에 해싱된 값 (해싱의 결과로 암호화 된 결과) 을 피해야 하며, 모든 값은 고유한 해시값을 가진다. (기존 해싱값과 중복이 되선 안된다는 것이다)
3. 해싱되기 전에 값 (문자열)이 아주 조금 다르더라도 해싱의 결과는 완전히 다른 값을 가져야 한다.
   ABC 의 해싱 결과가 BCD일 경우, (알파벳 순서 +1씩 증가)
   ABD 의 해싱 결과가 BCE 이면 안된다. 라는 것이다. (C, D 만 다르므로 해싱의 결과가 끝에 3번째만 다른 결과가 나왔다.. 이러면 안된다) 

- Salt
암호화 해야 하는 값에 "별도의 값"을 추가하여 변형하는것.

즉, 해싱 과정에서 "별도의 값"을 추가하여 해싱하는것이다.

이것이 필요한 이유는 다음과 같다.

 

1. 암호화만 해놓는다면 해시된 결과가 늘 동일하므로 문제.
    해싱된 결과를 대량을 기억해두고 원본값 유추 가능하기 때문이다.

2. 해싱 알고리즘이 노출 됬을 경우에도 원본값 보호 가능.
     알고리즘이 노출됬을 경우, 해싱된 비밀번호를 해싱 알고리즘으로 복호화 하려고 해도

     약속된 "Salt" 을 알지 못하기 때문에 원본으로 복화하가 되지 않는다. 

     

 

- Salt 사용시 유의 사항

 

1. Salt는 유저와 패스워드 별로 유일한 값을 가져야 한다.

2. 사용자 계정을 생성할때와 비밀번호를 변경할때마다 새로운 임의의 Salt를 사용해야 한다.

3. Salt는 절대 재사용 해서는 안된다.

4. Salt는 DB의 유저 테이블에 같이 저장되어야 한다.
    유저마다 각자의 Salt값을 가지고 있고, 해당 데이터는 클라이언트에게 전달할 일이 없다.

    서버 DB에만 저장되어 있는 값이다.

    그렇기 때문에 Salt가 유출될 일은 없다.

    클라이언트가 비밀번호를 입력하여 서버에게 전달 하였을때, 서버는 Salt값과 서버상에 해싱 알고리즘으로 암호화하여 

    비밀번호를 생성해낸다.

 

 

Cookie

서버에서 클라이언트에게 넘겨준 데이터를 클라이언트에서 저장하고 있는것.

 

EX : 유저 이름, 닉네임, SessionID 등등...

 

그로 인해, 서버가 클라이언트에 저장된 쿠키 정보를 다시 요청할 수도 있음.

즉, 쿠키 정보는 최초에 서버에서 클라에게 내려주지만,

그 이후부터는 클라가 서버에게 전달하기도 함.

 

그러나, 이러한 쿠키 정보도 서버가 아무때나 가지고 올 수는 없다.

바로 다음과 같은 옵션들 때문이다.

 

1. Domain
   http://www.localhost.com:3000/users/login 에서 localhost.com 부분(도메인) 이 같아야만 쿠키 전달 가능.
   
   
2. Path
   http://www.localhost.com:3000/users/login 에서 /users/login 부분(Path)이 같아야만 쿠키 전달 가능.
   Path로 설정된 path보다 추가적인 path를 가지고 있는 경로에서 요청할 경우에도 전송 가능.
   즉,
   Path가 /users로 설정되어 있고, 요청하는 세부 경로가 /users/codestates 인 경우라면 쿠키 전송이 가능
   
   
3. MaxAge | Expires
   쿠키가 유효한 기간을 정하는 옵션.
   MaxAge는 앞으로 몇 초 동안 쿠키가 유효한지 설정.
   Expires 은 MaxAge와 비슷합니다. 다만 언제까지 유효한지 Date를 지정.
   
   - 세션 쿠키: MaxAge 또는 Expires 옵션이 없는 쿠키로, 브라우저가 실행 중일 때 사용할 수 있는 임시 쿠키.
     브라우저를 종료하면 해당 쿠키는 삭제.
   
   - 영속성 쿠키: 브라우저의 종료 여부와 상관없이 MaxAge 또는 Expires에 지정된 유효시간만큼 사용가능한 쿠키.
   
   
4. Secure
   만약 해당 옵션이 true로 설정된 경우, 'HTTPS' 프로토콜을 이용하여 통신하는 경우에만 쿠키를 전송 가능.
   false일 경우, http://www.codestates.com 또는 https://www.codestates.com에 모두 쿠키를 전송 가능.
   
   
   
5. HttpOnly
   자바스크립트에서 브라우저의 쿠키에 접근 여부를 결정한다.
   만약 해당 옵션이 true로 설정된 경우, 자바스크립트에서는 쿠키에 접근이 불가.
   명시되지 않는 경우 기본으로 false로 지정.
   
   
   
6. SameSite
   Cross-Origin 요청을 받은 경우 요청에서 사용한 메소드와 해당 옵션(e.g. GET, POST, PUT, PATCH …)의 조합으로 서버의 쿠키 전송 여부를 결정하게 됩니다. 사용 가능한 옵션은 다음과 같습니다.

• Lax :Cross-Origin 요청이면 'GET' 메소드에 대해서만 쿠키를 전송할 수 있습니다.
• Strict : Cross-Origin이 아닌 same-site 인 경우에만 쿠키를 전송 할 수 있습니다.
• None: 항상 쿠키를 보내줄 수 있습니다. 다만 쿠키 옵션 중 Secure 옵션이 필요합니다.
  
  

+ 네이티브 (EX : 모바일) 에는 없는 개념.

브라우저에만 존재.

 

참조 : https://velog.io/@kaitlin_k/cookie-%EC%98%B5%EC%85%98

 

Session

서버에 저장되는 클라이언트에 대한 데이터.

 

클라이언트가 비밀번호와 아이디를 입력하여 서버에 로그인 요청을 하면,

서버는 비밀번호를 검증한 뒤, 서버에 해당 클라이언트에 대한 Session을 생성, 저장한다. (서버가 해당 클라이언트를 인가한 상태, 인가는 권한 부여이다)

그리고 그 Session의 ID를 암호화하여 클라이언트에게 전달하여 주고, (이때, 클라이언트에게 쿠키로써 저장하라고 함)

다음 요청부터 클라이언트는 쿠키에 저장된 SessionID를 같이 보내게 되고,

서버는 해당 SessionID가 현재 서버에 저장된 SessionID인지 확인을 하여 맞다면,

로그인한 상태의 클라이언트임을 인지하여 로그인 상태로써 클라이언트는 해당 사이트를 사용 가능하다.

 

+ 로그 아웃 구현 하려면?

서버 : 세션 정보 삭제

클라이언트 : 쿠키 갱신

 

서버가 클라이언트의 쿠키를 임의로 삭제할 수는 없습니다. 대신, set-cookie로 클라이언트에게 쿠키를 전송할 때 세션 아이디의 키값을 무효한 값으로 갱신할 수 있음.

 

 

+ 서버에서 Session은 주로 인메모리 DB 혹은 세션스토어에 저장.

 

 

참조 : https://seob.dev/posts/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EC%BF%A0%ED%82%A4%EC%99%80-SameSite-%EC%86%8D%EC%84%B1/

 

JWT

추후 정리

 

 

 

웹 보안 공격에 대하여

추후 정리