CSRF 가 필요한 이유
CSRF 보호가 작동하는 방식을 잘못 이해하면 활성화 해야 하는 시나리오에서 비활성화 하거나 그 반대의 상황이 많이 발생한다.
다음과 같은 시나리오로 예를 들 수 있다.
사용자가 파일을 관리할수 있기 인증/인가를받고 애플리케이션에 로그인한 상태에서 파일을 관리하기위해 서버에 엔드포인트를 호출하고 이메일의 알 수 없는 링크를 클릭했는데 빈화면이 나오는 페이지로 리디렉션되고 자동으로 외부 페이지가 열렸다 이때 이 페이지가 서버를 호출하고 사용자 대신 작업을 실행한다(악의적인 이유로 파일을 수정/삭제한다)
이를 가능하게 하는 이유는 애플리케이션 입장에선 해당사용자는 인증/인가를 받은(로그인한) 신뢰하는 사용자 이기 때문이다.
대부분의 앱 사용자는 자신의 보안위협을 인지하지 못하기때문에 앱이 사용자를 보호하는 형태로 설계되어야 한다.
하지만 최근에는 클라이언트사이드 렌더링이 늘어나면서 API서버에서 JWT기반의 인증/인가를 많이 이용하고 JWT가 CSRF에 대한 역할을 대신 해줘서 security에서 해당 설정을 사용하지 않는 경우가 많은것 같습니다.
CSRF 보호가 작동하는 방식
한가지 확실한 것은 데이터를 변경하는 작업을 위해서는 get을 최소한 한번은 수행해야 한다. 이때 애플리케이션은 고유한 토큰을 생성한다. 그때부터 애플리케이션은 헤더에 이 고유한 값이 들어있는 요청에 대해서면 변경작업(POST,PUT,DELETE)을 할 수 있도록 해주는것이다.
애플리케이션은 토큰의 값을 안다는 것은 다른 시스템이 아닌 애플리케이션 자체가 변경요청을 보낸 증거로 보는 것입니다.
보호의 시작점
CSRF 보호의 시작점은 필터체인의 CsrfFilter입니다. CsrfFilter는 요청을 가로채고 GET, HEAD, TRACE, OPTIONS를 포함하는 HTTP 방식의 요청을 모두 허용하고 다른 모든 요청에는 토큰이 포함된 헤더가 있는지 확인한다. 토큰값이 잘못 됀 겨웅 403리턴.
- CsrfTokenRepository : 구성요소를 이용해 새 토큰을 생성, 토큰저장, 토큰 검증에 필요한 CSRF토큰 값을 관리한다. 랜덤 UUID로 토큰 생성,
