YOUNGMINKIM

3 분 소요

✔ 인증

완벽한 인증은 없으며, 비밀번호는 유출이되고, 신분증은 위조가 된다

  • 완벽한 인증은 존재하지 않는다, 거대한 인터넷 내에서의 보안(인증)은 필수적이다
  • HTTP 기본 인증 과정을 정리하며 인증에 대해 정리 해보자

✔ HTTP 인증요구

기본 인증

  • 기본 인증은 가장 잘 알려진 HTTP 인증 규약
  • 기본 인증의 경우 서버는 클라이언트의 요청을 거부하고 추가적인 데이터를 요구할 수 있다
  • 서버는 401 상태 코드와 클라이언트가 접근하려했던 부분을 WWW-Authenticate에 적어 반환
    • Authorization
      • 클라이언트 인증 정보
      • 비밀번호, 개인정보, 등을 서버에 전달
    • WWW-Authenticate
      • 리소스 접근시 필요한 인증 방법 정의
      • 서버에서 요청을 받은 후 응답을 내려줄 때 같이 반환

요청 과정

  • 클라이언트 측에서 서버에 GET 요청
  • 서버는 401 UnAuthorized와 함께 요청 반려
  • WWW-Authenticate 헤더에 내용을 적어 반환(Response)
  • 클라이언트 측에서는 Authorization 헤더에 정보를 담아 서버에 요청
    • (유저 개인 정보 등등..)
  • 서버는 클라이언트의 요청을 구분하여 성공/실패로 구분하여 응답

Base-64 유저 이름 및 비밀번호 인코딩

HTTP 기본 인증은 유저의 이름과 비밀번호를 :으로 이어서 합치고
Base-64 인코딩 메서드를 사용해 인코딩한다

Base-64

  • 8bit binary data를 문자코드에 영향을 받지 않는 ASCII 코드 문자들로 바꾸는 인코딩 방식
  • base-64 인코딩은 바이너리, 텍스트, 국제 문자 데이터를 문자열로 받아서 전송할 수 있도록,
    해당 문자열을 전송 가능한 문자인 알파벳으로 변환하기 위해 발명
  • base-64 인코딩은 국제 문자나 HTTP 헤더가 사용할 수 없는 문자(큰따옴표, 콜론, 캐리지 리턴)을 포함한 사용자 이름이나 비밀번호를 보내야할 때 유용

보안

기본 인증은 누군가가 의도치 않게 리소스에 접근하는 것을 막거나 SSL 같은 암호 기술과
혼용하여 사용한다

  • HTTP 트랜잭션을 SSL 암호화 채널을 통해 보내거나 보안이 더 강화된 다이제스트 인증 같은
    프로토콜을 사용하는 것이 좋다
  • 한번 뚫리면 추후에도 계속 뚫릴 가능성이 높아진다
  • 가짜 서버의 위장에는 취약하다

✔ 쿠키(Header)

  • Set-Cookie: 서버에서 클라이언트 측으로 쿠키 전달(Response)
  • Cookie
    • 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청 시 서버로 전달

✔ 쿠키를 사용하지 않는 경우

Welcome Page 반환

#요청
GET /welcome HTTP/1.1

#응답
HTTP/1.1 200 OK

<html>
 <div>Welcome</div>
</html>
  • 처음 Welcome 페이지를 접근한다 가정 해보자
  • GET 요청 후 Welcome 페이지를 반환 받는다
  • 동적 데이터를 받지 않기 때문에 큰 상관이 없다

로그인

#요청
POST /login HTTP/1.1
user=홍길동

#응답
HTTP/1.1 200 OK
홍길동님이 로그인했습니다.
  1. 유저 정보를 서버에 전달
  2. 서버에서는 메시지(홍길동님이 로그인..)를 반환
  3. 다시 한번 클라이언트 측에서 서버에 로그인을 요청한다 (Stateless에서 다시 한번 설명)
  4. 서버에서는 메시지(안녕하세요 손님..)을 반환

Stateless

  • HTTP는 무상태(Stateless) 프로토콜
  • 클라이언트와 서버가 요청과 응답을 주고 받으면 연결을 끊는다
  • 서버는 클라이언트의 이전 요청을 기억하지 못한다
  • 클라이언트와 서버는 서로 상태 유지를 하지 않는다

대안 1

모든 요청에 사용자 정보를 포함하여 전송?

  • GET /welcome?user=홍길동 HTTP/1.1
  • GET /board?user=홍길동 HTTP/1.1
  • GET /order?user=홍길동 HTTP/1.1
  • GET /xxx…?user=홍길동 HTTP/1.1

모든 요청에 정보를 넘기는 문제

  • 모든 요청에 사용자 정보를 달아서 전송하기에는 상당한 리소스 낭비를 가져옴
  • 모든 요청에 사용자 정보가 포함되도록 개발 해야함

쿠키

#응답
POST /login HTTP/1.1
user=홍길동

#요청
HTTP/1.1 200 OK
Set-Cookie: user=홍길동

홍길동님이 로그인했습니다.
  • 클라이언트가 서버에 요청을 보낸 경우 서버는 Set-Cookie에 정보를 저장 후 응답
  • 클라이언트는 쿠키 저장소에 해당 응답 정보를 받아 저장해둔다
  • 후에 서버에 요청을 보낼때마다 쿠키 저장소에서 해당 쿠키 정보를 포함하여 전송

쿠키 정리

- Set-Cookie:
    - sessionId=abcde1234;
    - expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/;
    - domain=.google.com;
    - Secure
  • 사용처
    • 사용자 로그인 세션 관리
    • ex) 클라이언트 정보를 서버에서 세션을 저장하여 관리
    • 광고 정보 트래킹
  • 쿠키 정보는 항상 서버에 전송
    • 네트워크 트래픽 추가 유발
    • 최소한의 정보만 사용(세션 id, 인증 토큰)
    • 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 사용
  • 주의
    • 보안에 민감한 데이터는 쿠키에 저장하면 안된다

쿠키 - 생명주기

Expires, max-age

  • Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
    • 만료일이 되면 쿠키 삭제
  • Set-Cookie: max-age=3600 (3600초)
    • 0이나 음수를 지정하면 쿠키 삭제
  • 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시까지만 유지
  • 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지

쿠키 - 도메인

Domain

  • domain=example.org
  • 명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
    • domain=example.org를 지정하여 쿠키 생성
    • dev.example.org도 쿠키 접근 가능
  • 생략: 현재 문서 기준 도메인만 적용
    • example.org 에서 쿠키를 생성하고 domain 지정을 생략
      • example.org 에서만 쿠키 접근
      • dev.example.org는 쿠키 접근 불가능

쿠키 - 경로

Path

  • path=/home
  • 위 경로를 포함한 하위 경로 페이지만 쿠키 접근
  • 일반적으로 path=/ 루트로 지정
    • path=/home 지정
    • /home -> ok (쿠키 전달)
    • /home/level1 -> ok (쿠키 전달)
    • /home/level1/level2 -> ok (쿠키 전달)
    • /hello -> no (쿠키 전달 안함)

쿠키 - 보안

Secure, HttpOnly, SameSite

  • Secure
    • 쿠키는 http, https를 구분하지 않고 전송
    • Secure를 적용하면 https인 경우메만 전송
  • HttpOnly
    • XXS 공격 방지
    • 자바스크립트에서 접근 불가(document.cookie)
    • HTTP 전송에만 사용
  • SameSite
    • XSRF 공격 방지
    • 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

참고자료

댓글남기기

참고