[Authentication/Security] HTTPS, Hashing, Cookie, CSRF

HTTPS Protocol

Hyper Text Transfer Protocol Secure socket layer

HTTPS 는 SSL 혹은 TLS 라는 알고리즘을 통해 HTTP 통신의 데이터를 암호화하여 전송하는 방법이다. Packet(네트워크 상에서 오가는 모든 data)을 암호화하여 중간자 공격을 방어한다.

SSL - Secure Socket Layer
TLS - Transport Layer Security - 더 발전되고 안전한 버전의 SSL

HTTPS는 certificate, certificate authority, asymmetric key 암호화를 사용한다.

1. Certificate

• 데이터를 제공한 서버가 정말로 데이터를 보내준 서버인지 인증/확인함.
• Domian 에 종속됨.

1. 클라가 서버에 요청을 보내면 서버는 인증서와 함께 응답을 전송.
2. 클라가 응답을 받으면 인증서에 있는 domain 과 응답 객체에 있는 domain을 비교.

2. CA

Certificate Authority
인증서를 발급하는 공인된 기관

1. 브라우저는 CA 리스트를 가지고 있음
2. 서버는 CA 기관을 통해 발급받는 SSL 인증서(public key 로 암호화) 를 사용자에게 전달
3. 브라우저는 SSL 인증서가 CA 리스트에 포함되어 있는지 확임
4. 브라우저는 SSL 인증서를 decode(복호화)
5. decode에 성공했으면 신뢰가능

fun fact: 네이버 웨일 브라우저는 네이버에서 발급한 인증서를 신뢰함.

사설 인증서 발급

• mkcert 프로그램 사용

mkcert -key-file key.pem -cert-file cert.pem localhost 127.0.0.1 ::1

// 127.0.0.1(IPv4)
// ::1(IPv6)

key.pem - 개인 키
cert.pem - 인증서

• ngrok
  HTTP로 만들어진 서버를 HTTPS 프로토콜로 터널링 해주는 프로그램
  프로토타입을 만들거나 빠르게 구현해야 할 때 사용.

3. 비대칭 키 암호화

• 전혀 다른 키 한 쌍으로 암호화 및 복호화.
• 어느 하나의 키로 암호화를 했다면 복호화할 때는 다른 키가 필요.
• HTTPS 프로토콜을 이용하는 서버는 한 쌍의 키 중에서 하나는 비밀로 숨겨두고 다른 하나는 클라이언트에 공개를 해서 데이터를 안전하게 전송할 수 있도록 듦.

Hashing

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

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

암호화(Encryption)

• 일련의 정보를 임의의 방식을 사용하여 다른 형태로 변환, 해당 방식에 대한 정보를 소유한 사람을 제외하고 이해할 수 없도록 '알고리즘'을 이용해 정보를 관리하는 과정
• DB 에 비밀번호를 암호화 해서 저장.
• SHA256 등

SHA256 같은 알고리즘은 공개된 알고리즘이나 decryption 이 매우 오래 걸리므로 상관없음.

비트코인 채굴은 hash 암호를 푸는 과정.

더더욱 안전하게 변형하는 법

1. hashing 을 여러번 적용
   해시된 값을 다시 한번 해시하는 것.

2. salt
   여러 문자열의 hash 된 값을 정리한 table 을 rainbow table 이라고 한다. 따라서 공개된 알고리즘 특성상 raindow table 을 통해 decrypt 할 수 있으므로, 문자를 추가해서 hashing 하는 것을 salt 라고 한다.

• 예) abc123 에 d2ef 를 추가하여 hash 하는 식.

Salt 사용 시 주의점

1. 유저와 패스워드 별로 유일한 salt 를 가저야 한다.
2. 사용자 계정을 생성할 때와 비밀번호를 변경할 때마다 새로운 임의의 salt 를 사용해서 hashing 해야 한다.
3. salf 는 절대 재사용하지 말아야 한다.
4. salt 는 DB 의 유저 테이블에 같이 저장되어야 한다.

Cookie

쿠키는 서버가 클라이언트에 저장하는 데이터이다. 서버 -> 클라

개발자도구 -> application 에서 쿠키 볼 수 있음.

서버는 쿠키를 이용하여 데이터를 저장하고 원할 때 데이터를 다시 불러와 사용할 수 있다. 하지만 데이터를 저장한 이후 아무 때나 데이터를 가져올 수 없다. 데이터를 저장한 이후 특정 조건들을 만족한 경우에만 다시 가져올 수 있다.

Cookie attributes

• Domain - 도메인 일치 여부 확인
• Path - 세부 URI 일치 여부 확인 (앞에만 같으면 뒤는 상관없음)
• MaxAge(초), Expires(date) - 쿠키 유효기간. 기간 지나면 삭제됨.
  • 요즘 브라우저는 쿠키를 자신이 삭제하지 않기 때문에 기간을 정하지 않으면 영원히 지워지지 않을 수 있음.
• Secure - True 일 경우 'HTTPS' 에서만 쿠키 사용가능
• HttpOnly - 자바스크립트 접근 가능 여부 (기본 false - 접근가능)
• SameSite - 같은 사이트끼리만 쿠키 사용 가능하도록. "CSRF killer"
  • Lax - Cross-Origin 요청일 때 'GET' 메소드에 대해서만 쿠키 전송
  • Strict - same-site 인 경우에만 쿠키 전송
  • None - 항상 쿠키를 보낼 수 있으나 Secure 옵션이 true 일 때만

---

서버가 클라이언트에 쿠키 생성 시: headers 에 Set-Cookie라는 프로퍼티에 쿠키를 담음

클라가 서버로 쿠키 보낼 시: headers 에 Cookie라는 프로퍼티에 쿠키를 담음

쿠키를 이용한 상태 유지

서버는 클라이언트에 인증정보를 담은 쿠키를 전송하고, 클라이언트는 전달받은 쿠키를 요청과 같이 전송하여 Stateless 한 인터넷 연결을 Stateful 하게 유지할 수 있다.

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

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

CSRF

Cross Site Request Forgery

다른 오리진에서 유저가 보내는 요청을 조작하는 것. 서버가 클라이언트를 너무 믿어서 생기는 빈틈.

조건

• 쿠키를 사용한 로그인. 유저가 로그인했을 때 쿠키로 어떤 유저인지 알 수 있어야 함
• 예측할 수 있는 request/parameter 를 가지고 있어야 함 - request 에 해커가 모를 수 있는 정보가 담겨있으면 안됨.

방어

• CSRF 토큰 사용
• Same-site cookie 사용

---

Public key, private key???

https://www.websecurity.digicert.com/security-topics/what-is-ssl-tls-https
https://www.ssl.com/faqs/what-is-a-certificate-authority/