cookie vs localstorage

참고 : LocalStorage vs Cookies: All You Need To Know About Storing JWT Tokens Securely in The Front-End - DEV Community 

 

 

필요한 배경지식

1. CSRF(Cross-site request forgery) : 사이트간 요청 위조. 사용자가 의도하지 않은 요청을 수행하도록 강제하는 공격 

예시) 피싱 사이트로 이동하게 하고, 비슷한 페이지로 자기 계정의 이메일 정보를 수정하는 API 실행. 쿠키가 함께 전송되어 요청이 실행됨

 

 

2. XSS(Cross-Site Scripting) : 웹 서비스에 Javascript 등 스크립트를 실행할 수 있는 코드를 삽입하여 다른 사용자 등에게 공격자가 의도한 스크립트를 실행하게 하는 공격 방법 

 

실제 사례) 추천수 조작 사건. 게시물 이미지에 script를 삽입하여 해당 게시물을 본 사람들이 자기도 모르는 사이에 다른 게시물의 추천을 누른 것으로 되어있었던 사건

 

나무위키) 공격 방법에 따라 Stored XSS와 Reflected XSS로 나뉜다.
- Stored XSS는 사이트 게시판이나 댓글, 닉네임 등 스크립트가 서버에 저장되어 실행되는 방식이고,
- Reflected XSS는 보통 URL 파라미터(특히 GET 방식)에 스크립트를 넣어 서버에 저장하지 않고 그 즉시 스크립트를 만드는 방식이다.
- 대부분은 Stored XSS라고 생각하면 된다. Reflected XSS의 경우 브라우저 자체에서 차단하는 경우가 많아 상대적으로 공격을 성공시키기 어렵다.

 

주로 CSRF를 하기 위해서 사용되기 때문에 종종 CSRF와 혼동되는 경우가 있으나, XSS는 자바스크립트를 실행시키는 것이고, CSRF는 특정한 행동을 시키는 것이므로 다르다

 

Local storage vs Cookie

	local storage	cookie
장점	간편하다. 보통 변수에 저장 후 header에 포함시켜 API를 요청한다	1. httpOnly(javascriptX), secure(https만)sameSite=strict를 하면 javascript가 쿠키에 접근할수 없어서 XSS를 막을 수 있음. 쿠키는 모든 http API 호출 요청에 자동적으로 포함됨. - XSS로부터 완전히 안전하진 않다. 모든 http API 호출 요청에 자동적으로 포함되므로 사용자 브라우저에서 cookie의 내용을 직접 꺼낼 순 없어도 cookie가 포함된 http 요청을 보내도록 할 수 있다. - 공격자가 공격자의 컴퓨터를 사용하는 것보다 피해자의 브라우저를 사용하여 공격하는 것은 더 유리할 수도 있다.
단점	1. XSS 공격에 취약하다. - 해커가 실행한 javascript 코드가 local storeage에서 토큰을 빼갈 수 있다. - front에서 사용하는 library에 XSS 공격 코드가 심어져 있을 수도 있다.	1. 쿠키의 최대크기가 4KB로 큰 토큰을 보관할 수 없다. 2. 꺼내서 header에 포함한 요청을 할 수 없다. 3. CSRF 공격에 취약하다. - 쿠키가 자동으로 포함되어 요청이 실행됨 - anti CSRF 토큰 등 으로 보완가능 아래의 CSRF 보완 방법들 모두 원론적으로 요청이 정상적으로 사용자 웹에서 온 요청인지 확인하기 위한 방법들이다. 보완 방법들 1. referrer을 확인해서 domain이 일치하는지 검증 (XSS 공격의 경우 방어 불가, 쉽게 referrer조작 가능) 2. Security Token(CSRF Token) - 클라이언트에는 백엔드에서 받은 난수 값을 요청마다 함께 전송. 백엔드에서 난수를 비교 (XSS의 경우 뚫릴 수 있음) 3. Double Submit Cookie 검증 클라이언트 측에서 난수를 생성해 쿠키와 파라미터로 함께 보냅니다. 백엔드에서 검증합니다. (백엔드 세션을 사용할 수 없을 때) 4. ASP.NET 의 CSRF 토큰 예시 (1) 백엔드에서 클라이언트로 page와 함께 CSRF 토큰을 보낸다 (2) CSRF토큰을 세션 쿠키로 함께 백앤드에 보낸다 (3) page form에 특정 숨겨진 hidden tag값을 함께 백앤드에 보낸다 (4) 백엔드는 토큰과 값들을 확인한다. (5) 페이지 다시 요청하면 새로운 토큰을 생성해 (1)번 부터 반복한다

 

결론

• 쿠키와 쿠키는 모두 XSS 공격에 취약하지만 httpOnly 쿠키를 사용하는 경우 공격자가 공격을 수행하기가 더 어렵다. (javascript 에서 쿠키값을 빼갈 수 없다)
• 쿠키는 CSRF 공격에 취약하지만 플래그 및 안티 CSRF 토큰 등을 사용하여 완화 할 수 있다.
• 헤더를 사용해야 하거나 JWT가 4KB보다 큰 경우에도 보안목적으로 쿠키는 함께 사용될 수 있다. (의역했음) 

 

 

추가적으로 알아본 것

 

Cookie의 sameSite 설정

1. sameSite 에서 같은 사이트란?

참고 : SameSite 쿠키 설명 (web.dev)

- 일반적인 사이트에서 www.web.dev 와 web.dev 는 동일한 사이트로 취급한다.( www.web.dev == web.dev )

- 공개 접미사에 등록된 도메인의 경우 뒷부분이 같더라도 다른 사이트로 간주한다  ( a.github.io ≠ b.github.io )

  공개 접미사 목록, https://publicsuffix.org/list/public_suffix_list.dat

 

2. sameSite 설정 값 (Strict, Lax, None)

1. Strict
   SameSite를 Strict으로 설정하면 쿠키가 자사 서버로 가는 요청에서만 쿠키가 전송된다. 사용자 측면에서 쿠키는 해당 사이트가 현재 브라우저의 URL 표시줄에 표시된 사이트와 일치하는 경우에만 전송된다
2. Lax
   SameSite가 Lax인 경우 아래 이미지에 나와 있듯이 "안전한" HTTP 방법을 사용하는 사이트간 최상위탐색(top-level navigation)에서만 쿠키를 전송한다고 한다. "안전한" HTTP method는 GET을 의미하며, 사용자가 직접 주소창에 입력하는 top-level navigation에서만 서드파티 쿠키를 허용합니다.(href, redirect 같은 완전한 사이트 이동에서만 쿠키전송이 허락되며<iframe> 안에서의 페이지 이동일 경우 전송되지 않습니다.)

3. None
마지막으로, 이전에 모든 컨텍스트에서 쿠키가 전송되기를 원한다는 사실을 암시적으로 명시하는 방식으로서, 값을 지 정하지 않는 방법이 있다. RFC6265bis 의 최신 초안에서는 SameSite=None 의 새 값을 도입하여 이 부분을 명시적으로 나타냅니다. 즉, None 을 사용하여 의도적으로 타자 컨텍스트에서 쿠키가 전송되기를 원한다는 사실을 명확하게 전달할 수 있습니다.

 

• SameSite 특성이 없는 쿠키는 SameSite=Lax로 처리된다.
• SameSite=None을 포함한 쿠키는 Secure=true도 지정해야 한다. 즉, 보안 컨텍스트가 필요하다. https에서만 none으로 할 수 있다.

 

Local storage vs Session storage

참고 : https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html

대부분 비슷하지만 세션 스토리지는 탭이 닫힐 때 사라지기 때문에 라이프 사이클이 좀 더 짧다. 그래서 안전한다.

가능하다면 local storage 보다는 session storage를 쓰는 것이 좋다