HTTP에 대해 최대한 조사해보자 - 2 (인증 simple)

이전 장에서 예고한것처럼 쿠키랑 세션에 대해 알아봅시다. HTTP에서 TLS이 추가되어서 보안이 증가된 형태인거는 이제 이해했는데 그렇다면, 인증쪽은 어떻게 처리를 해야 할까요? 아니 애초에 이게 왜 필요한건지 이해할 필요가 있을거 같습니다. 웹이나 앱등등 사용자를 등록하게 되어집니다. 등록을 하게 되면 로그인이라는걸 하게 되는데 그런 다음 어떻게 해야 할까? 쿠키나 세션 하물며 JWT토큰 조차 없다고 생각해보자 이거는 그냥 데이터에 불과할겁니다.. 그걸 통해 뭔가 액션을 취할 수 는 있겠는데 그걸 계속 유지를 시킬 수는 없습니다. 왜냐하면 HTTP는 알다시피 Stateless 비연결성 프로토콜입니다. 즉, 한 번 요청하고 응답이 끝나면 그 연결에 대한 기억은 완전히 사라집니다. 여기서 어라? HTTP는 지속 연결을 지원한다고 하지 않았나...??? 그건 사실 TCP입니다. TCP의 연결을 계속 유지를 하는거지 HTTP의 연결을 계속 유지하지는 않습니다. 그러니까 결국 소멸이 되는 거죠. 이래서 필요한 기술이 쿠키와 세션입니다.

쿠키

쿠키는 맛있습니다. 답니다. 웹에서 쿠키는 무엇을 말하는 걸까요? 일단 쿠키는 서버가 클라이언트(브라우저)에게 전달하는 작은 데이터 조각이라고 합니다. 이 데이터는 클라이언트의 로컬 저장소에 저장되며, 이후 요청마다 자동으로 서버로 전송이 되어집니다. 그러니까 최초는 서버 -> 클라이언트로 전송이 되어지고 클라이언트는 로컬 레파지토리에 저장하고, 그걸 통해서 아이디나 패스워드등 정보들을 클라이언트가 서버쪽에 물어보면서 해결하는 형태로 가는 느낌인거 같습니다. 

하지만 쿠키는 다음과 같은 한계가 있다고 합니다. 1. 보안 위험 2. 저장 용량 한계 3. 전송 오버 헤드 4. 도메인 종속성가 있다고 합니다.
하나씩 살펴봅시다.

1. 보안 위험: 뭐가 위험하다는 걸까? 쿠키는 클라이언트(브라우저) 에 저장이 되어집니다.
즉, 이 데이터는 서버가 직접 관리하지 못합니다.이 말은 곧 “누구나 조작할 수 있다”는 뜻입니다.
이게 쿠키의 본질적인 보안 리스크입니다.

간략하게 어떤 보안 이슈와 방어방법에 대해 알아봅시다.

위험	원인 방어	방법
위·변조	클라이언트 조작 가능	서버 서명 or 세션 식별자만 저장
탈취	평문 전송	HTTPS + Secure 속성
XSS	JS 접근 가능	HttpOnly
CSRF	자동 전송	SameSite

2. 저장 용량 제한: 이거 또한 브라우저에 저장하기 때문에 서버 보다는 한계가 있을거라 예상합니다. 브라우저가 저장할 수 있는 용량 자체가 최소한으로 잡혀 있는데 이유는 용량 자체가 커지게 되면 쿠키도 커지게 될거고 스니핑 위험 노출 구간이 커지고 전송 속도 및 암호화 오버헤드가 증가하며, CSRF, XSS의 공격면이 넓어진다고 합니다. 그래서 보안적으로도 쿠키는 작고 명확해야 한다고 합니다. 보통은 세션 ID나 JWT토큰 정도만 넣는다고 합니다.

3. 전송 오버헤드: 매 요청마다 자동 전송되기 때문에 불필요한 트래픽 유발을 하게 됩니다. 아무래도 클라이언트에 저장되어있기 때문에 그걸 통해 서버로 계속 요청을 할 수 밖에 없습니다. 

4. 도메인 종송성: 다른 출처간 공유가 불가한다는 문제가 발생한다고 합니다. 이걸 CORS문제라고 하는데 자세하게 알아봅시다.
일단 쿠키는 도메인 기반이라고 합니다. 쿠키는 특정 도메인에 종속되어 동작합니다. 예를 들어 example.com에서 발급한 쿠키는 기본적으로 api.example.com 이나 another.com에서는 자동으로 전송되지 않습니다. 즉, 출처가 다르면 쿠키는 공유할 수 없다는 것을 알 수 있습니다.

그런데 요즘은 프론트와 백엔드가 분리되어 있는 형태가 많습니다. 이렇게 되면 백엔드로 요청을 보낼 때, 브라우저는 "출처가 다르다"며 쿠키를 자동으로 전송하지 않습니다. 이때 이걸 허락 하는 프로토콜이 CORS입니다.

결국 쿠키는 “자동 전송 편의성”을 얻는 대신, "트래픽 오버헤드”라는 대가를 치릅니다.
브라우저 성능이 아무리 좋아져도, 이 구조가 바뀌지 않는 이상 불필요한 전송 비용은 남습니다.
일단 간략하게 알아봤습니다. 

 

세션

세션은 쿠키와 정 반대가 아닙니다. 그렇다고 완벽하게 100%반대는 아닌듯 싶습니다. 아무튼 쿠키가 서버에서 데이터를 받아서 클라이언트에 저장하는 방식인것처럼 세션은 서버에서 보내는 걸까? 아쉽게도 아닙니다. 애초에 방향자체가 클라이언트에서 서버로 방향이 되어야 하는데 서버에서 어찌알고 데이터를 저장할 수 있겠냐 말일까요?. 서버에서 배포하고 서버에서 저장할 수는 있겠지만, 서버 -> 서버으로 데이터를 보내지는 않습니다. 생각해보니 계속 잘못 말하고 있었네요 클라어인트에서 데이터를 보내면 서버로 데이터를 보내게 되어집니다.

제가 생각할때 세션은 HTTP기술 보다는 방법론에 좀더 가깝다고 생각이 듭니다. 왜냐하면 세션을 저장할때 서버에 저장을 하게 되어지는데 그것을 메모리에 저장하든, db에 저장하든, 레디스에 저장하든 상관이 없었습니다. 또한 외부에서는 세션 ID라는 것을 쿠키에 저장이 되어집니다. 세션 ID를 통해 상태값을 확인할 수 있기 때문에 기술보다는 방법론에 가깝다고 생각했습니다. 

마무리

일단 이 정도만 하고 마무리를 짓겠습니다. 많은 내용을 담기보다는 세션이 어떤것인지 쿠키가 어떤것인지에 초첨을 맞춰 설명을 하였습니다. 쿠키는 브라우저에 저장하고 세션은 서버에 저장하는 기술입니다. 제 생각엔 쿠키는 HTTP기술이 맞으나 세션은 HTTP기술 보다는 방법론에 가깝다고 생각이 듭니다. 그리고 세션과 쿠키는 각각 동작하지는 않습니다. 이 다음은 세션을 가지고 어떻게 HTTP를 사용할 수 있는지 조금더 생각해보면 좋을거 같습니다. 또 보안쪽으로 강화할 수 있는 방안들을 계속 생각하는게 좋을거 같습니다.

공부하면서 느낀건 쿠키,세션,토큰이 각각 동작하지 않는다는 것을 조금더 느낀거 같습니다. 쿠키는 단독으로 사용할 수 있지만 어찌 되었든
세션과 함께 사용하는거 같고 토큰도 리프레쉬가 들어가는 순간 세션처럼 사용하게 되어지는 거 같습니다.

저장방식에 메모리를 말했었는데 nginx같은 웹 서버에 저장을 할 수 있을거 같습니다. 느낌상요. 공부할 기회가 생기면 하루종일 쿠키,세션,토큰 각각 하나씩만 공부해도 부족할거 같습니다. 시간이 없어서 이정도까지만 작성합니다.