BEB Section 2 - 인증/보안 기초

0️⃣ Code

https://github.com/cliffclimber-721/simple-network

GitHub - cliffclimber-721/simple-network: Just an simple code of how to code with Express framework

 

1️⃣ HTTPS

 HTTP + Secure 라고 생각하면 쉽고 기존의 HTTP 통신 프로토콜에서 보안 체계가 하나 더 생성되어 내용을 암호화한 통신 프로토콜을 의미한다.

 

 HTTP를 사용하는 경우에 클라이언트와 서버가 서로 통신하고 있을 때 요청되는 내용을 그대로 볼 수 있었다. 암호화된 내용이 아무것도 없기 때문에 중요한 정보가 노출되기 쉽고, MiTM(중간자 공격)이 발생하는 경우도 있었다. 하지만 HTTPS는 암호화되어 내용을 전달하기 때문에 중요한 정보가 노출이 되어도 정확한 정보를 파악하기 어렵다. HTTPS 프로토콜은 3개의 방식을 사용하여 암호화를 진행한다.

 

• 인증서 : 정말 데이터를 보내는 서버인지 인증하는 용도로 사용된다. 데이터 제공자에 대한 신원 보장이 가능하다.
  • 서버는 인증서와 함께 response을 전송하는데, 인증서에 있는 도메인과 response로 통해 받은 도메인이 같다면 확실하다는 것을 인지하는데, 중간에 해커가 request의 정보를 탈취해 중간자 공격이 이뤄지면, 인증서에 있는 도메인과 response에 있는 도메인이 같지 않아 제공된 정보가 맞는지 확실하게 말해줄 수 없다. 
• CA(Certificate Authority) : 공인인증서 발급 기관, 자격이 박탈당하는 경우도 있다.
• 비대칭 키 암호화 : 만약 키 A를 통해 암호화를 했다면, 해당되는 데이터를 복호화하기 위해선 그에 상응하는 키 B로만 복호화가 가능하다.

 

2️⃣ SSL, TLS

 HTTPS 프로토콜은 SSL이나 TLS 알고리즘을 통해 통신 과정을 암호화하여 데이터를 전송한다. 인증을 통해 신원을 보장받을 수 있다고 앞서 언급했는데 이에 대해 중요한 이유는 따로 있다.

• 클라이언트는 데이터 제공자가 제공한 데이터를 사용할 수밖에 없다.
• 중간자 공격에 취약

 

3️⃣ 암호화

사실 전 wireshark를,, 알아요.

 

 HTTPS 프로토콜 특징 중 하나는 암호화된 데이터를 주고 받기 때문에 중간에 인터넷 요청이 탈취되더라도 그 내용을 알아보기 어렵다. 기존 HTTP 프로토콜은 요청이나 응답을 탈취하면 프로그램을 이용해 해당 요청으로 인해 전달되는 데이터의 내용을 확인할 수 있다.

 데이터를 암호화해 전송하는 HTTPS 프로토콜을 사용한다면 중요한 데이터가 유출될 가능성이 적어지게 된다.

 

 

4️⃣ 인증서

 HTTPS 프로토콜의 다른 특징 중 하나는 브라우저가 응답과 함께 전달된 인증서 정보를 확인할 수 있다는 점이다. 

 

🅰️ 중간자 공격

출처 : 나무위키

 네트워크 통신을 조작해 통신 내용을 도청하거나 조작하는 공격 기법이다. 중간자 공격의 작동원리는 총 4가지 존재한다.

• 스니핑 : 시스템 및 네트워크에서 들어오고 나가는 데이터 패킷을 캡처하는데 사용되는 기술
• 패킷 주입 : 공격자가 일반 데이터와 함께 악의적 데이터를 주입하는 것
• 세션 하이재킹 : 두 시스템 간 연결이 활성화된 상태를 가로채는 것이고, 세션 만료 오류를 발생시킨다.
• SSL 스트리핑 : 공격자가 SSL/TLS 연결을 차단해 프로토콜 보안성이 있는 HTTPS에서 안전하지 않은 HTTP로 전환한다.

 

 

5️⃣ Hashing

 어떠한 문자열에 대해 임의의 연산을 적용해 다른 문자열로 변화하는 것을 의미한다. 그에 대한 조건이 총 3가지 존재한다.

 

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

 

6️⃣ Salt

 암호화해야하는 값에 별도의 값을 추가하여 결과를 변형하는 것을 의미한다. 

 

7️⃣ Cookie

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

 그래서 쿠키를 이용하는 것은 단순히 서버에서 클라이언트에 쿠키를 전송하는 것만 의미하지 않고 클라이언트에서 서버로 쿠키를 전송하는 것도 포함된다. 결국 서로 필요충분조건을 맞춰가며 쿠키를 전송한다고 생각하면 쉬울 듯 싶다.

 서버는 쿠키를 이용하여 데이터를 저장하고 원할 때 해당되는 데이터를 다시 불러와 사용할 수 있다. 하지만 데이터 저장 이후 아무 때나 데이터를 가져올 수 없고, 저장 이후 특정 조건이 만족해야만 다시 가져올 수 있다. 이 조건들은 쿠키 옵션으로 표현 가능하다.

 

1. 도메인 
   • www.daum.net 과 같이 서버에 접속할 수 있는 이름을 뜻한다. 여기에선 포트 번호나 서브 도메인 정보, 세부 경로를 포함하지 않는다. → 서브 도메인은 www 같은 애들을 말한다.
     • 그래서 여기서 말하는 도메인은 daum.net을 말한다.
   • 쿠키 옵션에 도메인 정보가 존재한다면 클라이언트에서는 쿠키 도메인 옵션과 서버 도메인이 일치해야 쿠키 전송이 가능하다.
2. Path
   • 서버가 라우팅할 때 사용하는 경로이다.
   • 요청해야하는 URL이 http://www.localhost.com:3000/users/login 라면, 세부 경로는 /users/login 에 해당된다.
   • 명시하지 않으면 / 로 설정한다.
3. MaxAge or Expires
   
   • 쿠키 유효기간을 정하는 옵션을 말한다.
   • MaxAge : 몇 초 동안 쿠키가 유효한지 설정
   • Expires :  유효한 날짜를 지정 → 날짜 초과되면 쿠키는 자동 파괴된다.
     • 하지만 두 옵션 모두 지정되지 않는 경우, 브라우저를 닫아야만 쿠키가 제거된다.
4. Secure
   • 쿠키를 전송해야할 때 사용하는 프로토콜에 따른 쿠키 전송 여부를 결정한다. 
     • 만약 해당 옵션이 true 로 설정된 경우, HTTPS 프로토콜을 이용하여 통신하는 경우에만 쿠키 전송이 가능하다.
5. HttpOnly
   • 브라우저의 쿠키에 접근 여부를 결정한다.
     • 만약 해당 옵션이 true 로 설정된 경우, 쿠키 접근이 불가능하다.
     • 명시적이지 않은 경우 기본적으로 false 로 지정되어있는데, 이런 경우 쿠키에 접근 가능하기 때문에 XSS 공격에 취약하다.
6. SameSite
   • Cross-Origin 요청을 받은 경우, 요청에서 사용한 메소드와 해당 옵션 조합으로 서버의 쿠키 전송 여부를 결정하게 된다.
     • Lax : GET 메소드에 대해서만 쿠키 전송 가능
     • Strict : same-site인 경우 쿠키 전송 가능
     • None : 항상 쿠키를 보내줄 수 있다. Secure 옵션이 필수적이다.
   • 옵션을 지정한 다음 서버에서 클라이언트로 쿠키를 처음 전송하게 된다면 헤더에 Set-Cookie라는 프로퍼티에 쿠키를 담에 쿠키를 전송하게 된다. 이후 클라이언트나 서버에 쿠키를 전송해야 한다면 클라이언트는 헤더에 Cookie라는 프로퍼티에 쿠키를 담아 쿠키를 전송하게 된다.

 

 쿠키를 이용한 상태 유지

 기본적으로 쿠키는 오랜 시간동안 유지될 수 있고, JS를 이용해 쿠키에 접근할 수 있기 때문에 쿠키에 민감한 정보를 담는 것은 위험하다. 

 인증 정보를 탈취해 서버에 요청을 보낸다면 서버는 누가 요청을 보낸건지 상관하지 않고 인증된 유저의 요청으로 취급하기 때문에 개인 유저 정보같은 민감한 정보에 접근 가능하다.