[Section 4] 인증/보안 기초

🧑🏻‍💻 TIL(Today I Learned)

---

✔️  HTTPS, Hashing, Cookie, Session, 웹 보안 공격

 

💡 HTTPS(Hyper Text  Transfer Protocol Secure Socket layer)

➡️ HTTP over SSL(TLS), HTTP over Secure

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

 

🔎 특징

1. 제 3자가 서버와 클라이언트가 주고받는 정보를 탈취할 수 없도록 하는 것
   : 서버와 클라이언트는 서로가 합의한 방법으로 데이터를 암호화하여 주고받음 때문에 제 3자에게 데이터가 탈취되더라도 내용을 알아볼 수 없음 
   : HTTPS에서는 클라이언트와 서버가 데이터를 암호화하여 주고받기 위해 비대칭키 방식과 대칭키 방식을 혼용하여 사용함 
   ※ 대칭키 방식 : 양쪽이 공통의 비밀키를 공유하여 데이터를 암호화 및 복호화하는 것
      비대칭키 방식 : 각각 공개키와 비밀키(개인키)를 가지고 상대가 나의 공개키로 암호화한 데이터를 개인이 가진 비밀키로 복호화하는 것을 의미함 
   
   
2. 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있다는 것
   : 이 인증서는 서버의 신원을 보증하여 우리가 접속한 웹 페이지가 해커가 정교하게 따라한 가짜가 아님을 보장해 주는 역할을 함
   : 이때 보증할 수 있는 제 3자를 Certificate Authority, CA 라고 부름
   : CA는 인증서를 발급해 주는 엄격하게 공인된 기관을 말함, CA들은 서버의 공개키와 정보를  CA의 비밀키로 암호화하여 인증서 발급
   : 즉 인증서는 CA의 비밀키로 암호화되어 있으며 CA의 공개키로 복호화 가능함 
   : 브라우저는 인증서의 도메인과 데이터를 제공하는 서버의 도메인을 비교할 수 있으므로 "중간자 공격" 을 감지하여 보안 위협으로부터 사용자 및 사용자의 데이터를 보호할 수 있음 
   : 또한 경고를 보여줌으로써 브라우저들은 인증된 CA가 발급한 인증서를 이용하여 데이터를 제공하는 안전한 서버를 사용자가 사용하도록 유도함 

서버가 클라이언트에게 CA에서 발급받은 인증서를 전달하면 클라이언트는 OS 또는 브라우저에 미리 내장되어 있던 CA 리스트를 통해 브라우저에서 인증된 CA에서 발급받은 인증서인지 먼저 확인하고 인증된 CA에서 발급한 인증서가 아니라면 화면에 경고창을 띄워 서버와 연결이 안전하지 않다는 화면을 보여줌 

만약 인증서가 확인되었다면 브라우저에 제공된 해당 CA 기관의 공개키로 서버 인증서를 복호화 

➡️ 서버와 클라이언트 간의 CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 아우른 프로토콜을 TLS 또는 SSL이라고 함 

 

 

 

💡 Hashing(해싱)

➡️ 가장 많이 쓰이는 암호화 방식 중 하나, 다른 암호화 방식과는 달리 해싱은 암호화만 가능함(복호화 불가) 

➡️ 해시 함수(Hash Function)를 사용하여 암호화를 진행하는데 해시 함수는 아래와 같은 특징 가짐 

• 항상 같은 길이의 문자열 리턴
• 서로 다른 문자열에 동일한 해시 함수를 사용하면 반드시 다른 결과값이 나옴
• 동일한 문자열에 동일한 해시 함수를 사용하면 항상 같은 결과값 나옴

 

🔎 레인보우 테이블과 솔트(salt)

➡️ 항상 같은 결과값이 나온다는 특성을 이용해 해시 함수를 거치기 이전의 값을 알아낼 수 있도록 기록해 놓은 레인보우 테이블이 존재함 
    레인보우 테이블에 기록된 값의 경우 유출이 되었을 때 해싱 이전의 값을 알아낼 수 있기 때문에 보안상 위협적임 

➡️ 위와 같은 상황에서 사용할 수 있는 것이 솔트(salt), 해싱 이전 값에 임의의 값을 더해 데이터가 유출되더라도 해싱 이전의 값을 알아내기 어렵게 만드는 방법 

 

🔎 목적 

➡️ 해싱의 목적은 데이터 그 자체를 사용하는 것이 아니라 동일한 값의 데이터를 사용하고 있는지 여부만 확인하는 것이 목적, 그렇기 때문에 복호화가 불가능한 암호화 방식을 사용함 

➡️ 민감한 데이터를 다루어야 하는 상황에서 데이터 유출의 위험성을 중이면서 데이터의 유효성을 검증하기 위해서 사용되는 단방향 암호화 방식 

 

 

💡 Cookie

➡️ 서버에서 클라이언트에 데이터를 저장하는 방법 중 하나,어떤 웹사이트에 들어갔을 때 서버가 일방적으로 클라이언트에 전달하는 작은 데이터

➡️ 해당 도메인에 대해 쿠키가 존재하면 웹 브라우저는 도메인에게 http 요청 시 쿠키를 함께 전달

➡️ 서버가 클라이언트에 데이터를 저장할 수 있으나 데이터를 저장한 이후 아무 때나 데이터를 가져올 수는 없음, 특정 조건들이 만족하는 경우에만 다시 가져올 수 있음

 

🔎 쿠키 옵션 

1. Domain
   : www.google.com과 같은 서버에 접속할 수 있는 이름 
   : 쿠키 옵션에서 도메인은 포트 및 서브 도메인 정보, 세부 경로를 포함하지 않음 
   : 쿠키 옵션에서 도메인 정보가 존재한다면 클라이언트에서는 쿠키의 도메인 옵션과 서버의 도메인이 일치해야만 쿠키 전송 가능 
2. Path
   : 세부 경로는 서버가 라우팅 할 떄 사용하는 경로 , 서버의 요청의 세부 경로가 일치하는 경우 쿠키 전송
   : http://www.localhost.com:3000/users/login 에서 세부 경로, Path는 /users/login
   : 명시하지 않으면 기본으로 / 설정
   : 설정된 Path를 전부 만족하는 경우 요청하는 Path가 추가로 더 존재하더라도 쿠키를 서버에 전송할 수 있음 
   
   
3. MaxAge or Expires
   : 쿠키가 유효한 기간을 정하는 옵션, 만약 쿠키가 영원히 남아있다면 그만큼 탈취도 쉬워지기 때문에 유효기간을 설정하는 것이 보안 측면에서 좋음
   : MaxAge는 앞으로 몇 초 동안 쿠키가 유효한지 설정하는 옵션
   : Expires는 MaxAge와 비슷하지만 언제까지 유효한지 Date를 지정함, 클라이언트의 시간을 기준으로 
   : 위 옵션 여부에 따라 두 가지로 나뉨 
   
   ▷ 세션 쿠키(Session Cookie)   
       : Max Age 또는 Expires 옵션이 없는 쿠키, 브라우저가 실행 중일 때 사용할 수 있는 임시 쿠키
       : 브라우저를 종료하면 해당 쿠키를 삭제함 
   ▷ 영속성 쿠키(Persistent Cookie) 
       : 브라우저의 종료 여부와 상관없이 MaxAge 또는 Expires에 지정된 유효 시간만큼 사용가능한 쿠키 
   
   
4. Secure
   : 쿠키를 전송해야 할 때 사용하는 프로토콜에 따른 쿠키 전송 여부를 결정함 
   : 만약 옵션이 true로 설정된 경우, HTTPS 프로토콜을 이용하여 통신하는 경우에만 쿠키 전송할 수 있음 
   : Secure 옵션이 없는 경우 프로토콜에 상관없이 모두 쿠키를 전송할 수 있음 
   
   
5. HttpOnly
   : 자바스크립트에서 브라우저의 쿠키에 접근 여부 결정 
   : 만약 옵션이 true로 설정된 경우 자바스크립트에서 쿠키에 접근 불가 
   : 명시되지 않는 경우 기본으로 false, 자바스크립트에서 쿠키에 접근이 가능하기 때문에 XSS 공격에 취약함 
   
   
6. SameSite
   : Cross-Site 요청을 받은 경우 요청에서 사용한 메서드와 해당 옵션의 조합을 기준으로 서버의 쿠키 전송 여부를 결정함
   
   ▷ Cross-Origin : 서버의 도메인, 프로토콜, 포트 중 하나라도 다른 경우 Cross-Origin으로 구분
   ▷ Cross-Site
       : eTLD+1이 다른 경우 Cross-Site로 구분 
       : eTLD란 .com, .org와 같이 도메인의 가장 마지막 부분 TLD(최상위 도메인, Top Level Domain)의 왼쪽의 하위 레벨 도메인을 합한 것을 말함 
   
   : 사용할 수 있는 속성에는 Lax, Strict, None 세 가지가 있음 

💡 Session(세션)

➡️ 사용자가 인증에 성공한 상태를 세션이라고 함 

➡️ 어떤 사이트에 로그인을 할 때 정확한 아이디와 비밀번호를 입력했다면 서버는 인증에 성공했다고 판단할 것이고 일종의 저장소에 세션을 저장함, 세션이 만들어지면서 각 세션을 구분할 수 있는 세션 아이가 만들어지고 클라이언트에서는 세션 성공을 증명할 수단으로 세션 아이디를 전달함 (이때 웹사이트에서 로그인을 유지하기 위한 수단으로 쿠키를 사용함, 쿠키에서 서버에서 발급한 세션 아이디 저장)

 

 

💡 웹 보안 공격

 

✔️ SQL Injection

➡️ 데이터베이스에서 임의의 SQL문을 실행할 수 있도록 명령어를 삽입하는 공격 유형
➡️ 응용 프로그램의 보안상의 허점을 이용해 데이터베이스를 비정상적으로 조작하며 기록이 삭제되거나 데이터가 유출될 수 있음 

🧑🏻‍💻 대응 방안

1. 입력(요청) 값 검증
2. Prepared Statement 구문 사용
3. Error Message 노출 금지