CSRF와 django의 csrf middleware에 대하여

CSRF

CSRF(Cross Site Request Forgery), 사이트 간 요청 위조

사용자의 의지와 무관하게

공격자가 사용자로 하여금

특정 웹사이트에 공격자가 의도한 행위를 요청하게 하는 공격.

CSRF가 요청을 위조하는 방법

참여자들

일반 사용자/ 공격자 / 타겟 서버

전제 상태

1. 사용자는 서버에 성공적으로 로그인을 하여

서버는 사용자를 확인할 수 있는 문자열을 포함하여 사용자에게 응답한 상태이고

2. 서버 영역에서는 세션 정보가 생성된 상태.

3. 사용자는 정상적인 응답을 받았으므로

session ID가 사용자의 브라우저 쿠키 영역에 저장됨.

이 때, 공격자가 서버를 공격하기 위한 요청 패턴에 대해 미리 알고 있다면

필요한 정보는 사용자 브라우저의 쿠키 영역에 저장된 session ID 뿐임.

이것을 헤더에 실어서 임의를 패킷을 만드는 것은 쉬운 일.

공격자는 어떻게 쿠키 영역의 정보를 탈취할까?

쿠키 영역 정보 탈취

1. 공격자는 악성 스크립트 페이지를 누르도록 유도한다.

서버가 직접적으로 해킹당하지 않았더라도

정상적인 게시글에 악성 스크립트를 실행시키는 클릭 유도 낚시 링크를 달면

유저가 클릭하게 되고

유저의 정보가 악성 스크립트가 의도대로 행동하게된다.

2. 서버는 쿠키에 담긴 session ID를 해석해서

정상적인 요청이라고 인지한다.(사용자의 session ID는 훼손된 것이 아니므로)

3. 서버는 인가된 사용자임을 인지하고 요청을 처리한다.
   (하지만 정상 사용자는 이 요청을 의도하고 보내지 않았다.)

CSRF 방어법

사용자
의심되는 URL,
신뢰할 수 없는 사이트의 URL,
출처가 명확하지 않은 곳으로부터 온 메일의 URL

등을 클릭하지 않도록 한다.

서버 개발자/운영자

- CSRF토큰 검사
  세션에 임의의 값을 저장한 뒤 사용자에게 return하여,
  모든 요청마다 해당 값이 있는지 검사함.

- Header의 referer 필드 값 검사
  referer 필드는 현재 요청을 보낸 페이지의 절대 주소 or 부분 주소인데,
  이 값을 검사하여 요청의 출처를 거를 수 있다.
  구체적인 request 통제를 위해 referrer policy를 활용할 수 있다.

- CAPTCHA 같은 플러그인으로 CAPTCHA 인증 코드 검사.

Django의 CSRF Middleware

복습 겸 간단 정리

- django에는 request를 후킹하여 처리하는 다양한 middleware가 있는데,
   csrf middleware가 그 중 하나다.

- csrf header 필드를 처리하고 validation 하는 역할을 한다.

- 기본적으로 settings.py에 활성화 되어있다.

- 버전별로 분리된 setting을 사용한다면 기본 setting을 override하여 사용하기 때문에
  csrf 공격을 방어하려면 view middleware보다 먼저 선언돼야함.

- csrf가 필요하지 않은 페이지를 위해 middleware를 비활성화하기보다.
  middleware는 활성화한 채 놔두고,  csrf_exempt를 사용할 것을 권장.

- middleware 대신 csrf_protect() 데코레이터를 사용하는 것은 지양됨.