HTTP 완벽 가이드 (11) : 클라이언트 식별과 쿠키

draw io 링크

https://drive.google.com/file/d/1NZfjJ4QznXf5kasNnzXIFe3CnFZOHWG9/view?usp=sharing

11장.drawio

 

클라이언트 식별과 쿠키

HTTP 특징

• 무상태
• 요청과 응답으로 통신

개인화된 서비스를 제공하고 싶은 웹 사이트들

• 개별 인사
• 사용자 맞춤 추천
• 저장된 사용자 정보
• 세션 추적
  • 무상태, 독립적으로 일어나는 각 요청 및 응답
  • 사용자와 사이트의 상호작용 → 상태를 남김(쇼핑몰 장바구니 기능)

사용자 식별 기술

• 사용자 식별 관련 정보를 전달하는 HTTP 헤더
• 클라이언트 IP 주소 추적
• 사용자 로그인 인증
• Fat URL - URL + 식별자
• 식별 정보 유지 지속 쿠키

HTTP 헤더

헤더 이름 헤더 타입 설명

From	요청	사용자의 이메일 주소
User-Agent	요청	사용자의 브라우저
Referer	요청	사용자가 현재 링크를 타고 온 근원 페이지
Authorization	요청	사용자 이름과 비밀번호
Client-ip	확장(요청)	클라이언트의 IP 주소
X-Forwarded-For	확장(요청)	클라이언트의 IP 주소
Cookie	확장(요청)	서버가 생성한 ID 라벨

• From - 악의적 서버의 스팸 메일 발송 문제 있음. 로봇/스파이더는 웹 마스터 항의를 받은 이메일 주소를 기술함
• User-Agent - 사용자가 쓰고있는 브라우저의 이름과 버전정보, 운영체제 정보까지 포함하기도 함.
  • 특정 브라우저에서 잘 동작하도록 콘텐츠 최적화에 유용함.
  • 특정 사용자를 식별하는 데는 큰 도움이 되지 않음
• Referer - 사용자가 현재 페이지로 유입하게 한 웹페이지의 URL
  • 사용자가 이전에 어떤 페이지를 방문했었는지는 알려줌.

⇒ 특정 사용자를 확실히 식별하기에는 부족함

클라이언트 IP 주소

사용자 식별에 IP 주소 사용

• 사용자가 아닌, 사용자가 사용하는 컴퓨터를 가리킴
  • 여러 사용자가 같은 컴퓨터를 사용하면 특정 사용자 식별 불가능
• 사용자 로그인시 ISP 동적 IP 주소 할당
  • 로그인한 시간에 따라 사용자는 매번 다른 주소를 받음
• NAT 방화벽 - 실제 IP 주소를 방화벽 뒤로 숨김.
  • 내부에서 사용하는 하나의 방화벽 IP 주소로 변환
• 프락시와 게이트웨이는 원 서버에 새로운 TCP 연결을 함.
  • 웹 서버는 클라이언트 대신 프락시의 IP 주소를 봄
  • Client-ip, X-Forwarded-For-HTTP : 프락시가 원본 IP 주소를 보존하려고 추가하는 확장 헤더
    • 모든 프락시가 이런 식으로 동작하진 않음.

사용자 로그인

로그인 요구 → 사용자에게 명시적으로 식별 요청 가능

웹 사이트에 사용자 이름을 전달하는 자체적 체계 존재

• WWW-Authenticate, Authorization 헤더
• 사이트 접근 전 로그인 요구 → 401 Login Required 응답 코드 전송
  • 사용자가 요청마다 로그인하지 않게 브라우저 대부분은 사이트에 대한 로그인 정보를 기억하여 사이트로 보내는 각 요청에 로그인 정보를 전달하게 됨

• 서버는 사이트 접근 전 로그인을 요구한다.
  • 401 상태코드와 WWW-authenticate 헤더를 전송한다.
• 사용자가 이름과 비밀번호를 입력하고 브라우저는 기존 요청을 다시 보내서 사용자 식별을 시도한다.
• 이제 서버는 사용자의 식별정보를 안다
• 이후 요청에 대해, 브라우저는 서버로부터 사용자 식별 정보를 요청받으면, 서버에서 오는 요청에 대해 자동으로 사용자 이름과 비밀번호를 포함한다.
  • 요청하지 않았을 때에도 전달
• 요청마다 해당 사용자의 식별정보 토큰을 Authorization 헤더에 담아 서버로 전송, 한 세션이 진행되는 내내 그 사용자에 대한 식별을 유지한다.

단점 : 사이트를 옮겨다닐 때마다 각 사이트에 로그인 해야함.

• 이름 선점, 비밀번호 규칙 차이 등

뚱뚱한 URL

사용자의 URL마다 버전을 기술하여 사용자를 식별하고 추적하는 웹 사이트

• URL의 처음이나 끝에 어떤 상태정보를 추가해 확장
• 사용자의 상태정보를 포함하고 있는 URL
• 온라인 쇼핑몰을 돌아다니는 사용자에게 식별번호를 할당, 각 URL 뒤에 붙여서 사용자 추적

HTTP 트랜잭션을 하나의 ‘세션’ or ‘방문’으로 묶는 용도

1. 처음 방문한 사용자에 대한 유일한 ID 생성
2. 서버가 인식 → 클라이언트를 fat url로 리다이렉트 시킴
3. fat url을 포함한 요청을 받으면, 사용자 아이디와 관련된 추가적인 정보(쇼핑카트,프로필 등)를 찾아서 밖으로 향하는 모든 하이퍼링크를 fat url로 바꿈

단점

1. 못생긴 url - 사용자들에게 혼란을 줌
2. 공유하지 못하는 url : 특정 사용자와 세션에 대한 상태정보 포함 → 개인정보를 공개하게됨
3. 캐시를 사용할 수 없음 : URL이 달라지기 때문에 기존 캐시에 접근 불가능
4. 서버 부하 가중 : fat url에 해당하는 html 페이지를 다시 그려야 함.
5. 이탈 : 링크를 타고 다른 사이트로 이동하거나 특정 URL을 요청 → 의도치않게 해당 세션에서 ‘이탈’하게 됨
   1. 사전에 세션 정보가 추가된 링크만을 사용해야 fat url이 문제없이 동작함
   2. 이탈 시 초기화 후 처음부터 시작 ← 쇼핑 장바구니 등
6. 세션 간 지속성의 부재 : 특정 Fat URL을 북마크하지 않는 이상, 로그아웃하면 모든 정보 유실

쿠키

• 넷스케이프 최초 개발
• 캐시 충돌 가능성 → 쿠키에 있는 내용물 캐싱하지 않음

타입

• 세션 쿠키
  • 임시 쿠키
  • 사용자가 브라우저를 닫으면 삭제됨
• 지속 쿠키
  • 디스크 저장 → 재시작 해도 남아있음.

사이트마다 다른 쿠키

쿠키가 수백, 수천 개 가능 but 두세개만 전송함.

• 쿠키를 모두 전달하면 성능 저하
• 대부분의 쿠키는 서버에 특화된 이름/값 쌍 포함, 대부분 사이트에서는 인식하지 않는 무의미한 값

광고 쿠키

• 웹사이트와 협력업체의 광고계약
• 광고들은 웹 사이트 자체의 일부인 것처럼 제작되고, 지속 쿠키를 만들어냄
• 같은 광고사에서 제공하는 서로 다른 웹 사이트에 사용자가 방문하면, 브라우저는 앞서 만든 지속 쿠키를 다시 광고사 서버로 전송한다.
  • 지속 쿠키의 도메인이 같기 때문
• Referer 헤더를 접목하여 사용자의 프로필과 웹 사이트를 사용하는 습관에 대한 방대한 데이터를 구축할 수 있음.
• 최신 브라우저 개인정보 설정 기능 → 쿠키 사용 방식에 제약

쿠키 Domain 속성

서버는 응답 헤더에 Set-cookie 헤더의 domain 속성을 사용해 어떤 사이트가 그 쿠키를 읽을 수 있는지 제어할 수 있음

Set-cookie: user="mary17"; domain="example.com"

• example.com으로 끝나는 사이트를 방문하면 Cookie: user=”mary17” 헤더가 항상 적용됨

path 속성

웹 사이트 일부에만 쿠키 적용

각각 쿠키를 별도로 갖는 두 개의 조직이 한 개의 웹 서버를 공유할 경우

Set-cookie: pref=compact; domain="example.com"; path=/autos/

사용자가 /autos/ 경로에 접근하면 쿠키를 두 가지 받게됨.

Cookie: user="mary17"
Cookie: pref=compact

쿠키 구성요소

Version 0 쿠키(넷스케이프)

• Version 1 쿠키 → Version 0 쿠키의 확장, 널리 쓰이진 않음
• 최초의 쿠키 명세

Set-Cookie: name=value [; expires=date] [; path=path] [; domain=domain] [; secure]

• expires : 쿠키의 생명주기를 가리킴.
  • 요일, DD-MM-YY HH:MM:SS GMT
  • GMT만 사용가능
  • 쿠키에 Expires를 명시하지 않으면 사용자의 세션이 끝날 때 파기됨
• domain
• path
• secure : HTTP가 SSL 보안 연결을 사용할 때만 쿠키 전송
  • client가 쿠키값을 변경할 수도 있음. → 쿠키 정보 변경 case
  • 클라이언트 개발할 때마다 기존 서버 쿠키를 받아서 행위등의 정보를 싣어서 서버에게 보낼 수 있음
  • secure 쿠키는 클라이언트에서 정보 변경 불가능
  • 개발할 땐 풀어놨다가, 운영 시에는 바꾸는 방식

버전 1 쿠키(RFC2965) 는 폐기되어 더 이상 지원되지 않음

• 쿠키마다 그 목적을 설명하는 설명문이 있음
• 파기 주기에 상관없이 브라우저가 닫히면 쿠키를 강제로 삭제할 수 있다.
• Max-Age: 절대 날짜 값 대신에 초 단위 상대값으로 생명 주기를 결정할 수 있음
• URL의 포트번호로도 쿠키를 제어할 수 있음.
• 도메인, 포트, 경로 필터가 있으면 Cookie 헤더에 담겨 되돌려보냄
• cookie2 = “Cookie2:” cookie-version : 호환되는 버전 번호

세션 추적

캐시

개인정보 유출, 이전 사용자의 쿠키를 다른 사용자에게 할당 등 문제로 쿠키는 캐시하지 않는 게 좋음

Cache-Control: no-cache="Set-Cookie"

• 문서의 본문은 캐시하더라도 Set-Cookie 헤더는 제외해야함
  • 여러 사용자에게 보내게 되면, 사용자 추적에 실패함.
  • → 캐시는 공용인 경우가 많으니까 쿠키 헤더가 여러명에게 보내질 수 있다는건가?
• 어떤 캐시는 응답을 저장하기 전에 Set-Cookie 헤더를 제거함 → 해당 헤더 정보가 없는 데이터를 받게 됨 → 문제 발생
  • 개선 방안 : 모든 요청마다 원 서버와 재검사해서 Set-Cookie 헤더 추가

Cache-Control: **must-revalidate, max-age=0**

• 보수적인 캐시는 콘텐츠가 캐시 가능한 데이터여도 set-cookie 헤더가 있는 응답은 캐시하지않을 수 있음
• 어떤 캐시는 쿠키헤더가 있는 이미지는 캐시하고, 텍스트는 캐시하지 않기도 함.

Cookie 헤더를 갖고 있는 요청을 주의해라

• 요청 + 쿠키 = 결과 콘텐츠가 개인정보를 담고있을 수도 있다.
• 위에서 말한 Set-Cookie 헤더가 포함된 이미지는 해도, 텍스트는 캐시하지 않는 경우에 속함.
• 더 효율적인 방식 = 캐시 이미지에 파기 시간이 0인 cookie 헤더를 설정해서 매번 재검사하도록 강제함.

<aside> 💡

max-age : 문서의 최대 나이 정의 문서가 처음 생성된 이후~제공하기엔 더 이상 신선하지 않다고 간주될 때까지 경과한 시간의 합법적인 최댓값(초 단위)

</aside>

쿠키가 보안상으로 엄청나게 위험한 것은 아니다.

• 쿠키 사용 비활성화, 로그 파일 분석으로 대체도 가능
• 원격 DB에 개인 정보를 저장하고, 쿠키에 해당 데이터의 키 값을 저장하는 방식을 사용하면, 클라이언트와 서버 사이에 예민한 데이터가 오가는 것을 줄일 수 있다.

로그 파일을 분석해도 사용자의 브라우징 습관을 추적할 수 있다. 쿠키는 그것을 좀 더 편리하게 해주는 방식

---

jwt 토큰도 쿠키에 저장해서 많이 사용함.

• 불변으로 만들어놓기도 하고
• 쿠키에 저장하는건 굉장히 위험 → 세션 스토리지
  • 세션 스토리지 - 요청을 하면 세션이 하나 만들어짐(커넥션처럼)
    • 서블릿 → jsession-id
    • 브라우저가 닫히기 전까지 정보가 디스크에 유지됨
    • 세션 id마다 할당된 스토리지
    • 중요 정보는 넣지 않는다.
    • mid(my id) - 클라이언트에 세팅 ← 이것과 뭔가 더 조합
      • 쿠키를 탈취하더라도 안전하도록
  • 로컬 스토리지 - 쿠키와 비슷한 애. 로컬 디스크에 저장, 아무나 볼 수 있음.
    • 브라우저 내 파일에 저장

인증과 인가

• 인증(Authentication)은 이 사람이 그 사람이 맞냐
• 인가(Authorization)는 이 사람이 적법한 권한을 갖고 있는 유저인가.
  • 이 url에 보낼 수 있는가

프록시 서버나 api gateway ip가 서버로 올라감

• 진짜 클라이언트 ip는 X-Forward-For로 알아냄
• 특정 ip나 대역만 서버를 사용할 수 있도록
  • ex) 가맹점 외 ip 대역은 통과 시키지 못하도록 사전 차단
  • 중간에 프록시가 껴있으면 검사가 안됨

User-Agent

• pc용 api, 모바일용 api 등 구분 가능

Referer

• 어떤 화면으로부터 api가 호출되었는지

브라우저를 오픈할 때 세션이 만들어짐. → 세션 쿠키

• user의 로그인한 키 세팅
• 인증값, 보안적으로 필요, 일시적으로 저장해야하는 것들
• 나 아닌 다른 유저가 세션 쿠키를 볼 수 없음.

지속 쿠키에는 사용자의 로그인 키 세팅 안함

• 처리상태, user의 상태 정보 등을 저장

회원 탈퇴 정보는 서버. 클라이언트x

매번 재검사 → 서버에서 매번 다시 들고내려옴

쿠키를 http-response에 내려보는 테스트 해보기

• secure 속성 설정

샌드박스

• 안팎으로 제한된

회사에서 A.naver.com, B.naver.com 사용

• CORS(Cross Origin Resource Sharing) : 어떤 도메인끼리는 CORS로 묶여있는 서버
  • 무상태
  • 요청과 응답으로 통신
  개인화된 서비스를 제공하고 싶은 웹 사이트들
  • 개별 인사
  • 사용자 맞춤 추천
  • 저장된 사용자 정보
  • 세션 추적
    • 무상태, 독립적으로 일어나는 각 요청 및 응답
    • 사용자와 사이트의 상호작용 → 상태를 남김(쇼핑몰 장바구니 기능)
  사용자 식별 기술
  • 사용자 식별 관련 정보를 전달하는 HTTP 헤더
  • 클라이언트 IP 주소 추적
  • 사용자 로그인 인증
  • Fat URL - URL + 식별자
  • 식별 정보 유지 지속 쿠키
  HTTP 헤더헤더 이름 헤더 타입 설명

  From	요청	사용자의 이메일 주소
  User-Agent	요청	사용자의 브라우저
  Referer	요청	사용자가 현재 링크를 타고 온 근원 페이지
  Authorization	요청	사용자 이름과 비밀번호
  Client-ip	확장(요청)	클라이언트의 IP 주소
  X-Forwarded-For	확장(요청)	클라이언트의 IP 주소
  Cookie	확장(요청)	서버가 생성한 ID 라벨

  • From - 악의적 서버의 스팸 메일 발송 문제 있음. 로봇/스파이더는 웹 마스터 항의를 받은 이메일 주소를 기술함
  • User-Agent - 사용자가 쓰고있는 브라우저의 이름과 버전정보, 운영체제 정보까지 포함하기도 함.
    • 특정 브라우저에서 잘 동작하도록 콘텐츠 최적화에 유용함.
    • 특정 사용자를 식별하는 데는 큰 도움이 되지 않음
  • Referer - 사용자가 현재 페이지로 유입하게 한 웹페이지의 URL
    • 사용자가 이전에 어떤 페이지를 방문했었는지는 알려줌.
  ⇒ 특정 사용자를 확실히 식별하기에는 부족함사용자 식별에 IP 주소 사용
  • 사용자가 아닌, 사용자가 사용하는 컴퓨터를 가리킴
    • 여러 사용자가 같은 컴퓨터를 사용하면 특정 사용자 식별 불가능
  • 사용자 로그인시 ISP 동적 IP 주소 할당
    • 로그인한 시간에 따라 사용자는 매번 다른 주소를 받음
  • NAT 방화벽 - 실제 IP 주소를 방화벽 뒤로 숨김.
    • 내부에서 사용하는 하나의 방화벽 IP 주소로 변환
  • 프락시와 게이트웨이는 원 서버에 새로운 TCP 연결을 함.
    • 웹 서버는 클라이언트 대신 프락시의 IP 주소를 봄
    • Client-ip, X-Forwarded-For-HTTP : 프락시가 원본 IP 주소를 보존하려고 추가하는 확장 헤더
      • 모든 프락시가 이런 식으로 동작하진 않음.
  사용자 로그인웹 사이트에 사용자 이름을 전달하는 자체적 체계 존재
  • WWW-Authenticate, Authorization 헤더
  • 사이트 접근 전 로그인 요구 → 401 Login Required 응답 코드 전송
    • 사용자가 요청마다 로그인하지 않게 브라우저 대부분은 사이트에 대한 로그인 정보를 기억하여 사이트로 보내는 각 요청에 로그인 정보를 전달하게 됨
  
  • 서버는 사이트 접근 전 로그인을 요구한다.
    • 401 상태코드와 WWW-authenticate 헤더를 전송한다.
  • 사용자가 이름과 비밀번호를 입력하고 브라우저는 기존 요청을 다시 보내서 사용자 식별을 시도한다.
  • 이제 서버는 사용자의 식별정보를 안다
  • 이후 요청에 대해, 브라우저는 서버로부터 사용자 식별 정보를 요청받으면, 서버에서 오는 요청에 대해 자동으로 사용자 이름과 비밀번호를 포함한다.
    • 요청하지 않았을 때에도 전달
  • 요청마다 해당 사용자의 식별정보 토큰을 Authorization 헤더에 담아 서버로 전송, 한 세션이 진행되는 내내 그 사용자에 대한 식별을 유지한다.
  단점 : 사이트를 옮겨다닐 때마다 각 사이트에 로그인 해야함.
  • 이름 선점, 비밀번호 규칙 차이 등
  뚱뚱한 URL
  • URL의 처음이나 끝에 어떤 상태정보를 추가해 확장
  • 사용자의 상태정보를 포함하고 있는 URL
  • 온라인 쇼핑몰을 돌아다니는 사용자에게 식별번호를 할당, 각 URL 뒤에 붙여서 사용자 추적
  HTTP 트랜잭션을 하나의 ‘세션’ or ‘방문’으로 묶는 용도
  1. 처음 방문한 사용자에 대한 유일한 ID 생성
  2. 서버가 인식 → 클라이언트를 fat url로 리다이렉트 시킴
  3. fat url을 포함한 요청을 받으면, 사용자 아이디와 관련된 추가적인 정보(쇼핑카트,프로필 등)를 찾아서 밖으로 향하는 모든 하이퍼링크를 fat url로 바꿈
  단점
  1. 못생긴 url - 사용자들에게 혼란을 줌
  2. 공유하지 못하는 url : 특정 사용자와 세션에 대한 상태정보 포함 → 개인정보를 공개하게됨
  3. 캐시를 사용할 수 없음 : URL이 달라지기 때문에 기존 캐시에 접근 불가능
  4. 서버 부하 가중 : fat url에 해당하는 html 페이지를 다시 그려야 함.
  5. 이탈 : 링크를 타고 다른 사이트로 이동하거나 특정 URL을 요청 → 의도치않게 해당 세션에서 ‘이탈’하게 됨
     1. 사전에 세션 정보가 추가된 링크만을 사용해야 fat url이 문제없이 동작함
     2. 이탈 시 초기화 후 처음부터 시작 ← 쇼핑 장바구니 등
  6. 세션 간 지속성의 부재 : 특정 Fat URL을 북마크하지 않는 이상, 로그아웃하면 모든 정보 유실
  쿠키
  • 넷스케이프 최초 개발
  • 캐시 충돌 가능성 → 쿠키에 있는 내용물 캐싱하지 않음
  타입
  • 세션 쿠키
    • 임시 쿠키
    • 사용자가 브라우저를 닫으면 삭제됨
  • 지속 쿠키
    • 디스크 저장 → 재시작 해도 남아있음.
  사이트마다 다른 쿠키
  • 쿠키를 모두 전달하면 성능 저하
  • 대부분의 쿠키는 서버에 특화된 이름/값 쌍 포함, 대부분 사이트에서는 인식하지 않는 무의미한 값
  광고 쿠키
  • 웹사이트와 협력업체의 광고계약
  • 광고들은 웹 사이트 자체의 일부인 것처럼 제작되고, 지속 쿠키를 만들어냄
  • 같은 광고사에서 제공하는 서로 다른 웹 사이트에 사용자가 방문하면, 브라우저는 앞서 만든 지속 쿠키를 다시 광고사 서버로 전송한다.
    • 지속 쿠키의 도메인이 같기 때문
  • Referer 헤더를 접목하여 사용자의 프로필과 웹 사이트를 사용하는 습관에 대한 방대한 데이터를 구축할 수 있음.
  • 최신 브라우저 개인정보 설정 기능 → 쿠키 사용 방식에 제약
  쿠키 Domain 속성

  Set-cookie: user="mary17"; domain="example.com"
  

  • example.com으로 끝나는 사이트를 방문하면 Cookie: user=”mary17” 헤더가 항상 적용됨
  path 속성각각 쿠키를 별도로 갖는 두 개의 조직이 한 개의 웹 서버를 공유할 경우사용자가 /autos/ 경로에 접근하면 쿠키를 두 가지 받게됨.쿠키 구성요소
  • Version 1 쿠키 → Version 0 쿠키의 확장, 널리 쓰이진 않음
  • 최초의 쿠키 명세

  Set-Cookie: name=value [; expires=date] [; path=path] [; domain=domain] [; secure]
  

  • expires : 쿠키의 생명주기를 가리킴.
    • 요일, DD-MM-YY HH:MM:SS GMT
    • GMT만 사용가능
    • 쿠키에 Expires를 명시하지 않으면 사용자의 세션이 끝날 때 파기됨
  • domain
  • path
  • secure : HTTP가 SSL 보안 연결을 사용할 때만 쿠키 전송
    • client가 쿠키값을 변경할 수도 있음. → 쿠키 정보 변경 case
    • 클라이언트 개발할 때마다 기존 서버 쿠키를 받아서 행위등의 정보를 싣어서 서버에게 보낼 수 있음
    • secure 쿠키는 클라이언트에서 정보 변경 불가능
    • 개발할 땐 풀어놨다가, 운영 시에는 바꾸는 방식
  버전 1 쿠키(RFC2965) 는 폐기되어 더 이상 지원되지 않음
  • 쿠키마다 그 목적을 설명하는 설명문이 있음
  • 파기 주기에 상관없이 브라우저가 닫히면 쿠키를 강제로 삭제할 수 있다.
  • Max-Age: 절대 날짜 값 대신에 초 단위 상대값으로 생명 주기를 결정할 수 있음
  • URL의 포트번호로도 쿠키를 제어할 수 있음.
  • 도메인, 포트, 경로 필터가 있으면 Cookie 헤더에 담겨 되돌려보냄
  • cookie2 = “Cookie2:” cookie-version : 호환되는 버전 번호
  세션 추적개인정보 유출, 이전 사용자의 쿠키를 다른 사용자에게 할당 등 문제로 쿠키는 캐시하지 않는 게 좋음
  • 문서의 본문은 캐시하더라도 Set-Cookie 헤더는 제외해야함
    • 여러 사용자에게 보내게 되면, 사용자 추적에 실패함.
    • → 캐시는 공용인 경우가 많으니까 쿠키 헤더가 여러명에게 보내질 수 있다는건가?
  • 어떤 캐시는 응답을 저장하기 전에 Set-Cookie 헤더를 제거함 → 해당 헤더 정보가 없는 데이터를 받게 됨 → 문제 발생
    • 개선 방안 : 모든 요청마다 원 서버와 재검사해서 Set-Cookie 헤더 추가

  Cache-Control: **must-revalidate, max-age=0**
  

  • 보수적인 캐시는 콘텐츠가 캐시 가능한 데이터여도 set-cookie 헤더가 있는 응답은 캐시하지않을 수 있음
  • 어떤 캐시는 쿠키헤더가 있는 이미지는 캐시하고, 텍스트는 캐시하지 않기도 함.
  Cookie 헤더를 갖고 있는 요청을 주의해라
  • 요청 + 쿠키 = 결과 콘텐츠가 개인정보를 담고있을 수도 있다.
  • 위에서 말한 Set-Cookie 헤더가 포함된 이미지는 해도, 텍스트는 캐시하지 않는 경우에 속함.
  • 더 효율적인 방식 = 캐시 이미지에 파기 시간이 0인 cookie 헤더를 설정해서 매번 재검사하도록 강제함.
  <aside> 💡</aside>
  • 쿠키 사용 비활성화, 로그 파일 분석으로 대체도 가능
  • 원격 DB에 개인 정보를 저장하고, 쿠키에 해당 데이터의 키 값을 저장하는 방식을 사용하면, 클라이언트와 서버 사이에 예민한 데이터가 오가는 것을 줄일 수 있다.
  로그 파일을 분석해도 사용자의 브라우징 습관을 추적할 수 있다. 쿠키는 그것을 좀 더 편리하게 해주는 방식

  ---

  jwt 토큰도 쿠키에 저장해서 많이 사용함.
  • 불변으로 만들어놓기도 하고
  • 쿠키에 저장하는건 굉장히 위험 → 세션 스토리지
    • 세션 스토리지 - 요청을 하면 세션이 하나 만들어짐(커넥션처럼)
      • 서블릿 → jsession-id
      • 브라우저가 닫히기 전까지 정보가 디스크에 유지됨
      • 세션 id마다 할당된 스토리지
      • 중요 정보는 넣지 않는다.
      • mid(my id) - 클라이언트에 세팅 ← 이것과 뭔가 더 조합
        • 쿠키를 탈취하더라도 안전하도록
    • 로컬 스토리지 - 쿠키와 비슷한 애. 로컬 디스크에 저장, 아무나 볼 수 있음.
      • 브라우저 내 파일에 저장
  인증과 인가
  • 인증(Authentication)은 이 사람이 그 사람이 맞냐
  • 인가(Authorization)는 이 사람이 적법한 권한을 갖고 있는 유저인가.
    • 이 url에 보낼 수 있는가
  프록시 서버나 api gateway ip가 서버로 올라감
  • 진짜 클라이언트 ip는 X-Forward-For로 알아냄
  • 특정 ip나 대역만 서버를 사용할 수 있도록
    • ex) 가맹점 외 ip 대역은 통과 시키지 못하도록 사전 차단
    • 중간에 프록시가 껴있으면 검사가 안됨
  User-Agent
  • pc용 api, 모바일용 api 등 구분 가능
  Referer
  • 어떤 화면으로부터 api가 호출되었는지
  브라우저를 오픈할 때 세션이 만들어짐. → 세션 쿠키
  • user의 로그인한 키 세팅
  • 인증값, 보안적으로 필요, 일시적으로 저장해야하는 것들
  • 나 아닌 다른 유저가 세션 쿠키를 볼 수 없음.
  지속 쿠키에는 사용자의 로그인 키 세팅 안함
  • 처리상태, user의 상태 정보 등을 저장
  회원 탈퇴 정보는 서버. 클라이언트x쿠키를 http-response에 내려보는 테스트 해보기
  • secure 속성 설정
  샌드박스
  • 안팎으로 제한된
  회사에서 A.naver.com, B.naver.com 사용
  • CORS(Cross Origin Resource Sharing) : 어떤 도메인끼리는 CORS로 묶여있는