보안 허접의 끝판왕 쿠키로 보안 공격에 어느정도 대처해보려 노력한 고찰.
바로 본문으로 들어가자.
하지만 잘 모르고 들어온 사람들을 위해서, 빠르게 사전 지식을 훑고 넘어갈 예정이다.
쿠키는 서버가 사용자와 통신할 때 보내는 작은 데이터 조각이다. 이러한 쿠키는 도메인 당(정확히 말하면 해당 사이트의 최상위 도메인) 최대 4KB(이것도 브라우저마다 다르다. 크롬은 무제한으로 도메인 쿠키 용량을 허용하기도 한다.)까지 사용자에게 저장할 수 있다. 또한 해당 도메인에서 사용자에게 발급한 총 쿠키 사이즈가 4KB 미만이어도 사용자가 해당 도메인에 대해서 소유할 수 있는 최대 쿠키의 개수는 브라우저에 따라 달라질 수 있다.
관련 내용이 궁금하다면 다음 내용을 참조하면 좋을 거 같다.
기본적으로 프론트엔드가 백엔드로 API 요청을 보내면 (이때는 서버와 해당 서버로 요청을 보내는 프론트엔드가 같은 도메인에 있다고 가정한다. 즉, SOP 정책과 SameSite 정책에 위배되지 않는 경우를 말한다.) 프론트엔드에서는 사용자가 가지고 있던 쿠키를 자동으로 헤더에 담아서 백엔드로 전송한다.
그리고 백엔드는 이러한 쿠키를 보고 사용자를 인식하여 그에 맞는 조취를 취해 줄 수 있다.
그래서 프론트엔드에서 쿠키를 직접 만들어서 저장하는 것은 권장되지 않고, 백엔드가 쿠키를 헤더에 담아서(이 때 백엔드는 Set-Cookie라는 헤더에 쿠키 이름과 쿠키 값, 만료시간 등을 작성한다.) 프론트엔드에 전송을 해주면 프론트엔드는 신경 쓰지 않고 자동으로 쿠키를 저장하게 된다. (여기서 백엔드가 쿠키를 구워준다라는 이야기가 나왔다.)
이러한 쿠키는 현재까지도 많이 사용되며, 사용자에 따라 맞춤 광고를 보여주는 등 다양한 마케팅에 활용하기도 한다. 옛날 로그인 방식도 이러한 쿠키 방식을 통해서 구현되었으며, 지금도 JWT 구현을 할 때 쿠키를 사용하여 리프레시 토큰을 저장하기도 한다.
하지만 예전부터 쿠키에 관한 보안 문제가 정말 많이 일어났다. 그 대표적인 사례로는 XSS 공격과 CSRF 공격이 있다.
그 이유는 쿠키를 불러오는 과정이 정말 간단하기 때문이다.
document.cookie //사용자의 쿠키 정보를 확인
?? 이걸로 도대체 어떻게 쿠키를 탈취할 수 있는데? 어차피 우리가 치지 않는 이상 해커는 조회할 수 없잖아.
놀랍도록 미친 해커들이 그걸 가능케 했다.
XSS 공격에서 XSS는 Cross-Site Scraping의 약자다. 근데 왜 CSS가 아니라 XSS냐면, CSS 공격이라고 하면 우리가 스타일링 할 때 사용하는 CSS와 헷갈리기 때문에 해당 용어를 XSS로 바꾸어서 표기했다고 한다.