CSRF (Cross Site Request Forgery)
Cross Site Request Forgery
CSRF는 이용자를 속여서 의도치 않은 요청에 동의하게 하는 공격을 말한다.
그럴듯한 웹 페이지를 만들어서 이용자의 입력을 유도하고, 이용자가 값을 입력하면 이를 은행이나 중요 포털 사이트 등으로 전송하여 마치 이용자가 동의한 것 같은 요청을 발생시킨다.
CSRF는 임의 이용자의 권한으로 임의 주소에 HTTP 요청을 보낼 수 있는 취약점이다.
공격자는 임의 이용자의 권한으로 서비스 기능을 사용해 이득을 취할 수 있다.
예를 들어, 이용자의 계정으로 임의 금액을 송금해 금전적인 이득을 취하거나 비밀번호를 변경해 계정을 탈취하고, 관리자 계정을 공격해 공지사항 작성 등으로 혼란을 야기할 수 있다.
CSRF 공격에 성공하기 위해서는 공격자가 작성한 악성 스크립트를 이용자가 실행해야 한다.
이는 공격자가 이용자에게 메일을 보내거나 게시판에 글을 작성해 이용자가 이를 조회하도록 유도하는 방법이 있다.
여기서 말하는 악성 스크립트는 HTTP 요청을 보내는 코드로 HTML, Javascript로 작성할 수 있다.
XSS와 CSRF 공통점은 클라이언트를 대상으로 하는 공격이며, 이용자가 악성 스크립트가 포함된 페이지에 접속하도록 유도해야 한다.
차이점은 두 공격은 목적이 다르다.
XSS는 사용자의 쿠키 값, 세션 값을 탈취하는 것이 목적인 반면, CSRF는 이용자의 권한을 통해 이용자가 임의 페이지에 HTTP 요청을 보내는 것이 목적이다.
CSRF Token
CSRF Token은 같은 오리진에서만(Same Origin) 접근 가능한 형태로 특정 Token을 저장해두고, HTTP 요청을 전송할 때 함께 전송한다.
웹 서버는 전송된 Token을 이용하여 제삼자가 아닌 이용자로부터 요청이 왔다는 것을 인증할 수 있다.
CSRF Token 값은 보통 HTML form 태그의 hidden 속성에 입력되거나, 동적 요청에서도 사용될 수 있다.
CSRF Token 방식은 캡챠나 암호화 방식과 달리 추가적인 사용자 상호작용이 불필요하다는 장점을 가지고 있다.
반면에 XMLHttpRequest나 Fetch API 등을 통해 Authorization과 같은 이용자 인증 헤더를 설정하여 통신하는 것에 비해 여러 가지 보안 문제의 원인이 된다고 한다.
CSRF Token 값의 길이가 짧거나 브루트포싱 공격이 가능할 정도로 길이가 짧으면 안되며 추측가능한 알고리즘으로 생성해서는 안된다.
Mitigation
방어 기법으로 세션 쿠키 대신에 커스텀 헤더를 사용하여 사용자를 검증을 하거나 위에서 설명한 CSRF Token, CAPCHA 등을 사용하여 방어하는 방식이 있다.
그러나 이 두 가지 방식은 서버 사이드에서 추가적인 검증을 통해 CSRF를 방어하는 기법으로 서버 코드에 검증 로직이 추가된다.
CSRF 공격이 가능한 이유를 다시 한번 생각해보면 웹 브라우저가 크로스 사이트, 즉 다른 사이트로부터 온 요청에 쿠키를 함께 전송한다는 것이다.
웹 브라우저는 다른 사이트로부터 온 요청에 쿠키를 삽입할지를 SameSite 쿠키 설정을 보고 판단한다.
쿠키에는 key=value 뿐만 아니라 Domain, Expire 등의 추가적인 값도 설정이 될 수 있는데, SameSite라는 설정이 추가가 되었다.
이 옵션은 크로스 사이트에서 출발한 요청에 제한적으로 쿠키를 포함시키게 하는 옵션이다.
총 세 가지(Strict, Lax, Normal) 값을 설정할 수 있다.
기본적으로 Strict는 모든 크로스 사이트에서 출발한 요청에 해당 쿠키를 삽입하지 않는다.
Lax는 Link, Prerender, Form GET을 제외한 요청에는 쿠키를 삽입하지 않는다.
Normal 옵션은 기존과 동일하게 모든 요청에 쿠키를 삽입한다.
기본 설정값으로는 Normal이 설정된다.
크롬 브라우저는 2020년부터 개발자가 강제로 SameSite=None; Secure; 을 넣지 않는 이상 웹 브라우저는 모든 쿠키에 SameSite=Lax를 강제로 적용하고 있다고 한다.