Replies: 6 comments
0. Stateful과 Stateless이란?둘의 차이의 핵심은 서버가 이전 요청의 상태를 기억하고 있느냐 이다. [ Stateful ] : 서버가 클라이언트의 이전 상태를 기억하는 방식 즉, 서버가 상태(State)를 가지고 있다.
[ Stateless ] : 서버가 이전 요청의 상태를 저장하지 않는 방식 예를 들어 JWT 인증에서는: 서버가 "이 사용자가 이전에 로그인했었다"라는 상태를 별도로 저장하지 않아도 된다.
1. 쿠키와 세션의 차이점을 설명해주세요.쿠키는 클라이언트에 데이터를 저장하고, 세션은 서버에 사용자 상태를 저장한다는 점이 가장 큰 차이이다.
세션의 동작 과정에서 예를 들어 로그인한다고 하면: 즉, 브라우저가 실제 사용자 정보를 가지고 있는 것이 아니라 Session ID를 가지고 있고, 실제 세션 데이터는 서버에 있다. [ 꼬리질문: 세션 방식에서도 쿠키를 사용하는 이유는? ] Session ID를 클라이언트가 계속 유지하고 서버에 전달하기 위해서이다. HTTP는 기본적으로 Stateless하기 때문에 서버는 각각의 요청이 같은 사용자의 요청인지 자동으로 알 수 없다. 따라서: 하는 방식으로 HTTP의 Stateless한 특성을 보완한다.
2. 쿠키와 세션 중 보안성이 더 높은 것은 무엇인가요?일반적으로 민감한 인증 상태를 직접 저장한다면 세션 방식이 더 안전하게 설계하기 쉽다. 하지만 쿠키와 세션 자체를 단순히 비교해서 어느 하나가 무조건 더 안전하다고 할 수는 없다. 실제 보안성은 보안 요소 별 방어하는 대표적인 위협
[ HttpOnly ] JavaScript에서 해당 쿠키에 접근할 수 없도록 한다. 따라서 공격자가 XSS를 통해 실행한 JavaScript로 인증 쿠키를 직접 탈취하는 것을 어렵게 만든다. 로 HttpOnly 쿠키를 읽을 수 있다. [ Secure ] HTTPS 연결에서만 쿠키를 전송하도록 한다. 따라서 HTTP와 같은 암호화되지 않은 통신 구간에서 쿠키가 노출되는 위험을 줄인다. [ SameSite ] 다른 사이트에서 발생한 요청에 쿠키를 얼마나 전송할지를 제한한다. 특히 CSRF(Cross-Site Request Forgery) 공격을 방어하는 데 중요한 역할을 한다. [ 꼬리질문: 쿠키에 HttpOnly와 Secure 속성을 설정하면 어떤 공격을 방어할 수 있나요? ] HttpOnly는 JavaScript의 쿠키 접근을 막아 XSS를 통한 세션 쿠키 탈취를 어렵게 하고, Secure는 HTTPS에서만 쿠키가 전송되도록 해서 네트워크 상에서 쿠키가 평문으로 노출되는 것을 방지한다. 다만 HttpOnly가 XSS 자체를 막는 것은 아니고, Secure 역시 HTTPS 자체를 활성화하는 것은 아니다. 그리고 3. JWT(JSON Web Token)와 세션 기반 인증은 어떻게 다른가요?가장 중요한 차이는 인증 상태를 서버에서 관리하느냐이다.
[ 세션 기반 인증 ] 서버가 상태를 가지고 있기 때문에 로그아웃할 때: [ JWT 기반 인증 ] JWT에는 일반적으로 다음과 같은 정보들이 들어간다. 예를 들어 Payload에: 같은 정보가 들어갈 수 있다. 서버는 JWT의 서명과 만료 시간 등을 검증하여 유효성을 판단한다. 즉, 처럼 동작할 수 있다. 세션 방식에서는 서버가 세션 상태를 관리해야 한다. 서버가 여러 대라면: 처럼 세션 공유 문제를 고려해야 한다. 반면 JWT는 서버가 별도의 세션 상태를 저장하지 않는 구조라면: 각 서버가 JWT를 독립적으로 검증할 수 있다. 따라서 Stateless한 JWT 인증은 수평 확장에 유리하다. [ 꼬리질문: JWT를 사용하면 서버에서 로그아웃을 즉시 처리하기 어려운 이유는 무엇인가요? ] 이 부분이 JWT의 핵심적인 단점이다. JWT를 발급한 후 서버가 JWT 자체를 저장하지 않는다면: 예를 들어 JWT의 만료 시간이 1시간이라면, 사용자가 로그아웃하더라도 서버 입장에서는 그 JWT가 아직 유효한 토큰인지 구분하기 어렵다. 즉시 폐기가 필요하다면? 대표적으로 다음과 같은 방법이 있다.
다만 이렇게 서버가 JWT의 상태를 관리하기 시작하면 JWT의 Stateless라는 장점이 일부 감소하게 된다. |
1. 쿠키와 세션의 차이점을 설명해 주세요.핵심 키워드: 클라이언트 저장, 서버 저장, 세션 ID, 만료 시간
서버에서 다음과 같이 응답하면,
Set-Cookie: SESSION_ID=a8f12...; HttpOnly; Secure; SameSite=Lax
브라우저는 이후 요청에 세션 ID를 자동으로 첨부한다.
Cookie: SESSION_ID=a8f12...
서버는 이 ID를 이용해 메모리, 데이터베이스 또는 Redis에서 사용자 정보를 찾는다.
1-1. 세션 방식에서도 쿠키를 사용하는 이유는 무엇인가요?HTTP는 각각의 요청을 독립적으로 처리하기 때문에 서버가 이전 요청의 사용자를 자동으로 기억하지 않습니다. 따라서 클라이언트가 요청할때마다 자신을 식별할 값을 전달해야합니다. 이 식별할 값(세션ID)를 전달하는 방법에는 쿠키, URL 파라미터, 요청 헤더 등이 있지만 일반적인 웹 애플리케이션에서는 쿠키를 사용합니다.
2. 쿠키와 세션 중 보안성이 더 높은 것은 무엇인가요?핵심 키워드: XSS, 세션 하이재킹, HttpOnly, Secure, SameSite
따라서 보통 세션 쿠키에는 다음과 같이 보안 속성을 설정합니다.
2-1. 쿠키에 HttpOnly와 Secure 속성을 설정하면 어떤 공격을 방어할 수 있나요?HttpOnly는 JavaScript가 쿠키를 읽지 못하게 하므로, XSS를 이용한 세션 쿠키 탈취 위험을 줄입니다. 쿠키에 document.cookie //JavaScript가 해당 쿠키를 읽으려 하는 코드Secure은 쿠키가 암호화되지 않은 HTTP 연결로 전송되지 않고 HTTPS에서만 전송되게 합니다. 따라서 네트워크 도청이나 중간자 공격을 통한 쿠키 노출 위험을 줄입니다. 하지만 Secure은 XSS를 통한 악성 요청 실행, 서버 내부의 쿠키 유출, 예측 가능한 세션ID, 잘못된 세션 만료 정책 등의 문제를 방어 하지 못합니다. 따라서 HttpOnly와 Secure은 함께 적용하고 CSRF 방어를 위해 SameSite또는 CSRF토큰도 같이 사용하면 방어력이 더욱 올라갑니다. 3. JWT(JSON Web Token)와 세션 기반 인증은 어떻게 다른가요?핵심 키워드: Stateful, Stateless, 서버 저장 공간, 확장성, 토큰 폐기
기타)
3-1. JWT를 사용하면 서버에서 로그아웃을 즉시 처리하기 어려운 이유는 무엇인가요?JWT는 발급된 토큰 목록을 서버가 가지고 있지 않아 세션 상태를 관리하지 않기 때문에(Stateless), 클라이언트가 로그아웃하면서 토큰을 삭제해도, 공격자가 복사해 둔 토큰으로 만료시간까지 로그인 가능합니다. JWT는 서버에서 폐기할 상태가 없으므로 다음과 같은 보완 방법을 사용합니다.
다만 블랙리스트나 토큰 버전을 조회하면 서버 상태를 다시 관리하게 되므로 JWT의 Stateless 장점이 줄어듭니다. 실무에서는 보통 수명이 짧은 Access Token과 서버에서 통제 가능한 Refresh Token을 함께 사용합니다. |
1. 쿠키 vs 세션서버는 한 번 응답을 보내고 나면 그 클라이언트가 누구였는지 기억을 못한다. 이 문제를 해결하기 위해 나온 게 웹 브라우저에 저장되는 작은 텍스트 데이터인 쿠키이다. 서버가 클라이언트 요청에 응답할 때 Set-Cookie헤더에 데이터를 담아 보내면, 클라이언트는 이 데이터를 쿠키로 저장한다. 이후에 같은 서버로 요청을 보낼 때마다 브라우저가 자동으로 그 쿠키를 전송한다. 세션은 쿠키와 마찬가지로 사용자를 기억하기 위해 서버 쪽에 저장되는 사용자 정보이다. 클라이언트가 로그인하면 서버가 데이터를 서버 메모리에 저장한다. 서버는 이 정보를 찾을 수 있는 세션ID를 발급해주고 이 세션 ID를 쿠키에 담아 클라이언트에게 전달하면 클라이언트가 자동으로 세션ID가 담긴 쿠키를 서버에 매번 보내준다. 이렇게 세션은 쿠키를 사용해서 클라이언트가 세션 ID를 저장하고 진짜 데이터는 서버에 저장하는 이중 구조이다. 2. 쿠키와 세션 중 보안성이 더 높은 것은?쿠키는 클라이언트에 정보가 그대로 저장된다. 심지어 F12를 누르면 누구나 쿠키값을 볼 수 있다. 그래서 보안이 강할 수 없다. 그에 비해 세션은 실제 민감 데이터는 서버에 있기 때문에 상대적으로 안전하다. XSS란 공격자가 웹사이트에 악성 자바스크립트를 몰래 삽입해서 다른 사용자의 브라우저에서 실행시키는 공격이다. 다른 사용자가 이 웹사이트에 접근하는 순간, 이 사용자의 쿠키가 통째로 공격자 서버로 전송된다. 공격자는 이 세션 id를 그대로 써서 세션 하이재킹을 하게 된다. 이걸 방어하는 것이 HttpOnly로 쿠키에 이 속성을 설정하면 자바스크립트로 절대 접근할 수 없게 된다. 쿠키 방식에서 일어나는 문제가 하나 더 있는데 만약 쿠키가 암호화 안 된 HTTP통신으로 전송된다면, 같은 공용 와이파이를 쓰는 공격자가 도청(패킷 스니핑)툴로 네트워크를 지나가는 데이터를 가로채서 쿠키 값을 그대로 훔쳐갈 수 있다. Secure속성을 쿠키에 설정하면 암호화된 연결인 HTPPS에서만 쿠키가 전송되고, 일반 HTTP에서는 실려 나가지 않게 된다. 이 두 속성은 서로 다른 공격을 막는 것이라 반드시 같이 설정해야 한다. 3. JWT(JSON Web Token)와 세션 기반 인증은 어떻게 다른가요?JWT 기반 인증은 서버가 아무것도 기억하지 않고, 토큰 자체에 정보와 서명을 담아 클라이언트에게 넘겨주는 방식이다. 로그인에 성공하면 서버가 사용자 정보를 담은 토큰을 생성하고, 서버의 비밀키로 서명한다. 이 토큰을 통째로 클라이언트에게 전달하면 클라이언트는 이후 요청마다 이 토큰을 헤더에 담아 전송한다. 서버는 저장소를 조회할 필요 없이 토큰의 서명만 검증하여 위조되지 않았는지 확인하고 바로 사용자 정보를 꺼내 쓰는 방식이다. 즉, 로그인 성공 시점에 이 사람은 인증된 사람이다! 하고 서명을 토큰에 찍어서 넘겨준다. 그래서 그 서명이 진짜 인지만 확인하면 서버가 기억할 필요도 조회할 필요도 없게 되는거다. 이 방식은 로그아웃을 하더라도 토큰을 삭제할 수 없기 때문에 토큰이 만료될 때 까지 해커가 탈취했는지 아님 내가 가지고 있는지 알 수 없는 단점이 있다. |
1. 쿠키와 세션의 차이점을 설명해 주세요.→ HTTP 프로토콜에는 비연결성과 비상태성이라는 특징이 있고 그 서버의 자원을 절약하기 위해 사용자의 요청에서 연결과 해제의 과정을 거쳐 연결이 유지되지 않고 연결 해제 후 상태의 정보가 저장되지 않습니다. 쿠키는 웹 서버가 브라우저에게 지시해 사용자의 로컬 컴퓨터에 파일 또는 메모리에 저장하는 작은 기록 정보 파일을 의미합니다 세션은 쿠키의 트래픽 문제와 쿠키를 변경하는 보안적 이슈를 해결하기 위해 등장했고 방문자가 웹 서버에 접속해있는 상태를 하나의 단위로 봅니다 쿠키와 세션의 차이는 사용자의 편의를 위하고 지워져도 큰일이 없는 데이터만 저장해도되지만 세션에는 서버안에서 다루어지기에 노출되면 안되는 정보를 저장하고 관리할 수 있습니다. 1-1) 세션방식에서도 쿠키를 사용하는 이유?→ HTTP 의 비상태성때문에 서버가 여러 요청을 보낸 사용자가 누구인지 식별할 수단이 필요하기 때문에 쿠키를 세션의 ID로 사용합니다 서버가 사용자의 세션 ID를 만들고 서버 메모리나 DB에 저장하고 서버는 세션 ID를 쿠키에 담아 클라이언트에게 보냅니다 2. 쿠키와 세션 중 보안성이 더 높은 것은 무엇인가요?→ 쿠키와 세션중 보안이 더 높은 것은 세션입니다 그 이유는 쿠키가 클라이언트 측에 저장이 되면 세션 하이재킹으로 보안 위협에 노출이 됩니다
방어
3. JWT(JSON Web Token)와 세션 기반 인증은 어떻게 다른가요?→ JWT는 클라이언트가 로그인을 위해 인증 정보를 생성, 클라이언트에게 전달 세션 기반 인증은 서버에 세션 데이터를 저장 JWT방식
세션기반 방식
|
1. 쿠키와 세션의 차이점을 설명해 주세요.전제부터 정리하면, http 는 stateless 프로토콜이라 요청 하나하나가 서로를 모른다. 로그인 요청과 그다음 요청이 같은 사람인지 서버가 알 방법이 없다. 이 문제를 해결하려고 나온 게 쿠키와 세션이다. 쿠키는 서버가 응답할 때 세션은 실제 데이터를 서버에 두는 방식이다. 서버가 사용자마다 저장 공간을 만들고 거기에 식별자(세션 ID)를 붙인 다음, 클라이언트에게는 이 ID 만 준다. 클라이언트는 ID 만 들고 다니고, 서버는 그 ID 로 자기 저장소에서 실제 정보를 찾는다.
꼬리질문 : 세션 방식에서도 쿠키를 사용하는 이유는? 세션 ID 를 어떻게든 클라이언트에게 들려 보내야 하는데, 그 운반 수단으로 쿠키가 제일 편해서이다. 쿠키는 브라우저가 요청마다 자동으로 붙여주니까 개발자가 신경 쓸 게 없다. 쿠키를 안 쓰려면 URL 에 세션 ID 를 붙이거나( 그러니까 세션과 쿠키는 대립하는 개념이 아니라, 세션이 쿠키를 운반 수단으로 쓰는 관계라고 이해했다. 흔히 "쿠키 vs 세션" 으로 비교하는데, 정확히는 "쿠키에 값을 직접 저장 vs 쿠키에 세션 ID 만 저장" 의 비교인 것 같다. 2. 쿠키와 세션 중 보안성이 더 높은 것은 무엇인가요?세션이 더 높다. 이유는 단순한데, 중요한 정보가 클라이언트에 아예 없기 때문이다. 쿠키에 값을 직접 넣으면 사용자가 개발자 도구로 열어볼 수도 있고 고칠 수도 있다. 다만 세션이 안전한 것이지 세션 ID 가 안전한 건 아니다. 결국 그 ID 는 쿠키에 담겨서 돌아다니고, 누가 그걸 훔치면 그 사람이 곧 나다. 비밀번호를 몰라도 로그인된 상태를 가져갈 수 있는데 이게 세션 하이재킹이다. 주요 공격:
꼬리질문 : HttpOnly 와 Secure 를 설정하면 어떤 공격을 막을 수 있나?
세 개가 막는 대상이 각각 다르다는 게 핵심인 것 같다. 3. JWT(JSON Web Token)와 세션 기반 인증은 어떻게 다른가요?세션 기반은 서버가 상태를 들고 있다(Stateful). 클라이언트는 ID 만 들고 다니고 진짜 정보는 서버에 있다. JWT 는 토큰 안에 정보 자체가 들어있다(Stateless). 구조가
세션의 약점이 확장성이다. 서버를 여러 대로 늘리면 1번 서버에서 로그인한 사람이 2번 서버로 가면 세션이 없다. 그래서 sticky session 을 쓰거나 Redis 같은 걸 세션 저장소로 따로 두게 되는데(#32 발제랑 이어지는 지점인 듯), 어쨌든 추가 구성이 필요하다. JWT 는 서버가 아무것도 안 들고 있으니 이런 문제가 없다. 한 가지 주의할 점. JWT 의 페이로드는 암호화가 아니라 그냥 Base64 인코딩이다. 아무나 디코딩해서 읽을 수 있다. 서명은 "위변조를 못 한다" 를 보장하는 것이지 "못 읽는다" 를 보장하지 않는다. 그래서 개인정보를 페이로드에 넣으면 안 된다. 꼬리질문 : JWT 는 왜 서버에서 로그아웃을 즉시 처리하기 어려운가? 서버가 발급한 토큰을 기억하지 않기 때문이다. 세션이면 서버 저장소에서 해당 세션을 지우면 그 순간 끝인데, JWT 는 서버에 지울 것이 없다. 이미 발급된 토큰은 만료 시간( 그래서 실무에서는 이렇게 우회한다고 한다.
근데 블랙리스트를 쓰는 순간 서버가 상태를 들고 있게 되는 거라, JWT 를 쓰는 이유였던 Stateless 를 스스로 깨는 셈이다. 이 지점이 좀 아이러니하다고 느꼈다. 결국 완전한 Stateless 인증이라는 건 없고, 어디까지 타협할 것이냐의 문제인 것 같다. 리프레시 토큰 로테이션이나 토큰 재사용 감지 쪽은 이름만 보고 넘어갔는데 따로 봐야겠다. |
기본 질문1. 쿠키와 세션의 차이점을 설명해 주세요.쿠키와 세션은 웹 통신에서 무상태성과 비연결성이라는 한계를 극복하기 위해 사용되는 상태 관리 기술입니다. 쿠키는 클라이언트에 저장되는 작은 텍스트 데이터 파일로 서버가 응답에 쿠키를 실어 전송하면 클라이언트가 그 쿠키를 클라이언트에 저장하여 다음 요청 시 함께 실어 보내 인증된 사용자임을 증명하고 세션은 사용자의 정보를 서버에 저장해두는 것으로 사용자가 로그인을 하면 서버에서 난수 형태의 세션 ID를 발급하여 DB 혹은 메모리에 저장해두고 이 세션 ID만 쿠키처럼 응답에 실어보내 사용합니다. 2. 쿠키와 세션 중 보안성이 더 높은 것은 무엇인가요?쿠키와 세션 중 보안성이 높은것은 세션입니다. 이유는 세션은 인증정보를 서버에서 관리하기 때문입니다. 쿠키는 클라이언트 브라우저에 인증정보가 있기 때문에 만약 그것만을 탈취한다면 서버 입장에서는 이상 징후를 발견하더라도 서버에 상태를 저장하지 않은 쿠키의 특징 때문에 인증정보가 유효한지만 검사 후 승인하게 되는데에 반해 세션의 경우 서버에서 상태를 관리하기 때문에 요청에 이상 징후가 발견된다면 상태를 블랙리스트에 등록한다던지 아예 인증정보를 폐기해 인증되지 않은 사용자로 만든다든지의 대응이 가능합니다. 3. JWT(JSON Web Token)와 세션 기반 인증은 어떻게 다른가요?JWT는 인증에 필요한 정보를 json 객체에 담고 이를 암호화한 뒤 클라이언트에게 발급하는 토큰 기반 인증 방식입니다. JWT는 .(점)으로 구역을 Header, Payload, Signature로 나눠 헤더와 페이로드에 정보를 담고 이를 서버의 비밀키로 암호화하여 시그니처에 등록해 사용자에게 발급해줍니다. 그럼 요청이 올때 서버에서 발급할때와 같은 방식으로 비밀키로 헤더와 페이로드를 암호화하여 시그니쳐와 비교해 위조 정보인지 판단합니다. 세션 기반 인증과 다른 점은 상태 저장 위치, 전송 데이터, 인증 검증 방식, 서버의 부담 정도, 확장성이 있습니다. 먼저 JWT는 쿠키와 같이 클라이언트에 저장되며 전송 데이터는 무의미한 세션 ID와 달리 실제 인증정보를 암호화된 상태로 전송됩니다. 그리고 인증을 검증하는 방식으로는 세션은 서버에 세션 ID를 조회하고 JWT는 서버의 비밀키로 토큰 Signature를 검증합니다. 그래서 세션은 서버에서 모든 인증정보를 가지고 있어야하지만 JWT는 비밀키만을 서버가 가지고 있기에 서버에 부담이 적고 세션은 서버가 늘어날때마다 세션 공유 설정을 해야하지만 JWT는 단지 비밀키만을 가지면 되기에 확장에 용이합니다. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
🗓️ 2026년 8월 17일 월요일
💡오늘의 질문?
1. 쿠키와 세션의 차이점을 설명해 주세요.
핵심 키워드와 꼬리 질문
핵심 키워드: 클라이언트 저장, 서버 저장, 세션 ID, 만료 시간꼬리 질문: 세션 방식에서도 쿠키를 사용하는 이유는 무엇인가요?
2. 쿠키와 세션 중 보안성이 더 높은 것은 무엇인가요?
핵심 키워드와 꼬리 질문
핵심 키워드: XSS, 세션 하이재킹, HttpOnly, Secure, SameSite꼬리 질문: 쿠키에 HttpOnly와 Secure 속성을 설정하면 어떤 공격을 방어할 수 있나요?
3. JWT(JSON Web Token)와 세션 기반 인증은 어떻게 다른가요?
핵심 키워드와 꼬리 질문
핵심 키워드: Stateful, Stateless, 서버 저장 공간, 확장성, 토큰 폐기꼬리 질문: JWT를 사용하면 서버에서 로그아웃을 즉시 처리하기 어려운 이유는 무엇인가요?
참고해도 좋을 듯한 블로그 : https://velog.io/@gloom/%EC%BF%A0%ED%82%A4-%EC%99%80-%EC%84%B8%EC%85%98%EA%B7%B8%EB%A6%AC%EA%B3%A0%ED%86%A0%ED%81%B0JWT
All reactions