CSRF - CSRF token, SameSite Cookie

 

우리는 SOP 가 cross-origin writes 허용한다는 사실을 알게 되었습니다. 이를 통해서 CSRF 공격에 유용하다는 사실을 배울 수 있습니다.

 

CSRF란? 

 

Cross Site Request Forgery (CSRF)는 임의 이용자의 권한으로 임의 주소에 HTTP 요청을 보낼 수 있는 취약점입니다. 이것이 가능한 이유는 다음과 같습니다. http 요청을 보낼 때, 브라우저에 저장된 쿠키를 함께 보냅니다. 브라우저의 SOP는 cross-origin wirtes(요청 보내기)를 허용합니다. 

 

웹 사이트는 쿠키 혹은 세션의 값을 보고 계정 주인 보낸 요청이라고 착각합니다. 이에 비밀번호 변경 및 다양한 업무를 세션 혹은 쿠키의 값으로 진행합니다. 이러한 CSRF 공격은 XSS와 달리 해커의 사이트를 클릭만 해도 공격 당할 수 있습니다. 

 

CSRF 공격은 form 태그, img 태그 등의 html로 가능합니다. 물론, JS 코드를 통해서 URL 를 변경시키는 방법도 있습니다. 요청만 보내면 됩니다.

 

그렇기에 일반적으로 CSRF 취약점을 방어하기 위해 CSRF Token을 사용합니다  

 

CSRF Token 이란?

 

CSRF Token은 같은 오리진에서만 접근 가능한 형태로 특정 Token을 저장해두고, HTTP 요청을 전송할 때 함께 전송합니다. 웹 서버는 전송된 Token을 이용하여 제삼자가 아닌 이용자로부터 요청이 왔다는 것을 인증할 수 있습니다. CSRF Token 값은 보통 HTML form 태그의 hidden 속성에 입력되거나, 동적 요청에서도 사용될 수 있습니다.

 

CSRF가 문제가 되는 이유가 바로 SOP 정책이 허용하기 때문입니다. CSRF 토큰을 사용하면 외부 오리진에서의 요청을 막을 수 있어서 해커가 유도한 사이트를 클릭하여도 임의 동작을 취하지 않습니다.

 

물론 xss 처럼 html를 입력받고 있다면, 필터링을 우회한 뒤 CSRF 공격을 시도할 수 있습니다.

 

하지만 문제점이 있습니다. CSRF Token은 웹 개발자에 의존하는 구조입니다. 그렇기에 사용자의 안전을 위해서 브라우저에 SameSite Cookie의 기본값을 LAX로 변경하였습니다. LAX는 strict의 몇가지 예외가 있는 기본값입니다. 

 

Samesite cookie란?

 

원래 도메인 당 하나의 쿠키 db를 가지고 있고 자신에 해당되는 쿠키의 db를 사용할 수 있습니다.

 

www.naver.com  -> www.google.com 

 

이동되는 경우를 많이 볼 수 있습니다. 이 경우 Samesite cookie가 none일 경우 쿠키를 붙여서 http 요청을 보냅니다 .하지만 lax가 된 경우 쿠키를 붙여서 보내지 않습니다. get 요청일 경우 쿠키가 붙음, post 요청일 경우 쿠키 붙지 않습니다.

get 요청일 때 쿠키가 붙는 다는 것을 이용하여 공격하는 xs-search 공격이 존재합니다.

 

추가적인 내용이 궁금하다면 : https://www.hahwul.com/2020/01/18/samesite-lax/

Cookie and SameSite

 

결국 samesite cookie 값이 lax가 기본값으로 된 브라우저에서는 악성 웹사이트를 만들어서 CSRF 공격을 할 수 없게 되었다. 실질적으로 CSRF 공격은 owasp Top 10에서 제외되었습니다.