질문과 답변

Q. 광고 회사들이 어떻게 쿠키를 활용하고, 브라우저는 어떻게 이것을 막을까?

  • host domain 이 아닌 domain 을 가지는 쿠키를 third-party 쿠키로 관리한다. (host 값이 host domain과 일치하는 쿠키 first-party 쿠키로 관리됨)

  • 따라서 동일한 광고가 여러 웹 사이트의 배너에서 광고되고 있을 경우, 이 광고에 대한 요청/응답 과정에서 third-party 쿠키가 생성될 수 있는데 이 쿠키로 사용자를 특정할 수 있다.

  • 최신 browser 에서는 third-party 쿠키를 생성하지 않는 설정이 default 이며, SOP(Same Origin Policy) 에 의해 다른 domain 의 cookie 사용을 제한함으로써 이를 방지하고 있다고 한다.

What is third-party cookie

First-Party & Third-Party cookie

Q. 해커들은 쿠키를 어떻게 얻고 이를 방지하기 위한 방법은 무엇이 있을까?

XSS, 중간자 공격 등.

기본적으로 쿠키(클라이언트 측)에 민감한 데이터를 저장하지 않는 것이 좋다. 웬만하면 세션 쿠키를 사용하고, 그렇지 않더라도 만료 기간을 엄격하게 명시하는 것이 좋다.

추가적으로,

  1. HTTPS 연결을 통해서만 쿠키가 보내지도록 Secure 플래그를 사용하기

  2. HSTS (HTTPS 강제) 를 설정한 경우에도 브라우저에 따라 HTTPS 강제 연결이 안 될 수 있으므로 언제나 Secure 플래그를 사용하는 것이 좋다. (HTTPS 를 사용 중이라면)

  3. XSS를 방지하기 위해 스크립트 접근이 필요하지 않은 경우 HTTPOnly 플래그를 사용하기

    • 단, 악의적인 이용자가 TRACE 메서드를 통해 쿠키를 포함하여 echo 받을 수 있으므로 TRACE 메서드를 ignore (구현 하지 말 것) 해야 효과를 볼 수 있음

  4. 그 외, HTTP 요청을 echo 하는 어떤 것이라도 프로덕션 환경에서 활성화 되어있으면 안 됨 (예를 들면, Docker echo container)

  5. SameSite 플래그 사용하기

  6. 다른 도메인에서 요청하는 경우 쿠키를 포함하여 전달하지 않는 방법.

  7. CSRF (사이트 간 요청 위조) 등과 같은 공격을 방지

  8. 다른 사이트에서 링크할 필요가 없다면 SameSite strict 로 설정할 것.

  9. 도메인 속성 없이 쿠키를 설정하기 (HostOnly)

  10. 만약 쿠키의 내용을 하위 도메인과 공유할 이유가 없다면 도메인 속성 없이 정확한 호스트와 일치할 때만 쿠키를 보내도록 설정하는 것이 좋다.

가장 중요한 것은 중요한 데이터를 쿠키에 넣지 않는 것.

https://techblog.topdesk.com/security/cookie-security/http://doc.cenzic.com/sadoc9x14ba847/CPL0001404.htm hsts : https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security csrf : https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9D%B4%ED%8A%B8_%EA%B0%84_%EC%9A%94%EC%B2%AD_%EC%9C%84%EC%A1%B0

Q. 지속 쿠키와 web storage(local storage, session storage)는 무엇이 다른가?

  • 쿠키는 유저에 저장된 작은 파일.

  • 각 쿠키는 lookup table이 있다.

  • 쿠키가 없이는, 매 요청마다 조그만 데이터가 필요해도 로그인이 필요할 것.

Localstorage

  • Key value를 기반으로 저장.

  • Expiration date가 따로 없음.

  • Javascript를 통해서만 저장 가능.

  • 그러나 유저는 local storage를 비울 수 있음.

  • Cookie의 진보된 버전이라고 볼 수 있음.

  • 쿠키는 최대 4kb인데 비해 5mb 까지 저장 가능.

  • 쿠키와 다르게, 데이터가 모든 요청마다 보내지지는 않음. 따라서 트래픽이 작다.

  • Same origin policy 가 적용됨.

differences

  • 쿠키는 서버에서 읽는 것을 목표로 하는 반면, local storage는 클라에서 읽는 것이 목표다.

Session storage

  • Session 을 위해서만 저장. 브라우저나 탭이 닫히면 데이터는 삭제됨.

  • 데이터는 서버로 전달되지 않음.

  • 5mb 정도까지 저장 가능.

https://medium.com/datadriveninvestor/cookies-vs-local-storage-2f3732c7d977

https://scotch.io/@PratyushB/local-storage-vs-session-storage-vs-cookie

Q. fat URL 의 현재 사용 용도는 어떤 것들이 있을까?

  • 추천인 가입

  • 이메일 verification

  • Session 은 서버와 클라 모두에 저장되나, cookie는 클라에만 저장됨.

  • Session은 짧은 일정 시간(30분 정도) 안에서만 저장되고 삭제됨.

Q. oauth는 어떤 문제를 해결하는 기술일까?

  • 어떤 서비스의 인증을 신뢰할 수 없거나, 여러 사이트의 수많은 인증이 귀찮고 힘든 문제를 해결.

  • 제 3의 provider에게 인증을 맡겨 신뢰할 수 있고 통합된 인증 체계를 구축함.

https://aaronparecki.com/oauth-2-simplified/

Q. httpOnly는 어떤 명세?

https://tools.ietf.org/html/rfc6265

Q. client-ip 헤더는 어디에 쓰이는 것일까? 현재도 쓰이고 있을까?

Last updated