Spring Security CSRF 설정 disabled 해도 될까?
CSRF (Cross-Site Request Forgery) 는 웹사이트 취약점 공격방법중 하나로 공격자가 의도한 수정 삭제 등록 행위 의 요청을강제하는 공격이다. 유명 경매사이트인 옥션에서 발생한 개인정보 유출 사건에서 사용된 공격 방식 중 하나이기도 하다.
CSRF 전제 조건과 공격과정
- 사용자는 서버로부터 쿠키 기반의 서버 세션 정보기반으로 인증을 받은 상태여아한다.
- 공격자는 서버를 공격하기 위한 요청 방법에 대해 미리 파악을 하고 있으며 서버가 요구하는 파라미터 정보또한 알고 있어야한다.
공격자는 사용자의 세션 정보에 대한 세션정보를 이용하여 공격을 감행하기 때문에 사용자 권한을 사용하여 그에 해당하는 공격을 한다.
시큐리티에 대하여
스프링 시큐리티는 csrf 에 대한 설정이 기본으로 Enabled 상태로 되어있으며 csrf 에 대한 토큰을 받도록 명시되어있고 토큰이 서버 헤더로 부터 전송되지 않을경우 403 에러를 리턴한다.
스프링 사용 가이드 에 따르면 session 을 저장하지 않는 REST 서버는 csrf 와같은 공격에 대해 영향을 받지 않는다 라고 나와있다. 서버에 탈취할 수 있는 session 이 없기때문이다.
- 인증서를 영속하지 않는 서버 구조인 경우
유저가 로그인했을경우 서버에서는 인증정보로 JESSIONID 또는 JWT 와 같은 토큰을 클라이언트에게 헤더에 담아서 전송하게 된다.
이를 받은 브라우저는 인증토큰을 브라우저 메모리에 저장하게 되며 이는 현재 페이지에서만 유효한 인증이된다.
하지만 CSRF 와 XSS 와 같은 공격은 항상 클라이언트에게 새로운 페이지를 열도록 유도하게 되며 이는 로그인시 브라우저 메모리에 저장되어있는 인증에 접근을 할 수 없다는것을 의미한다.
하지만 이 방법을 사용하게 될경우 페이지를 이동 , 새로고침 할때마다 로그인을 해서 토큰을 받아 다시 서버로 넘겨줘야 하는 불편함이 있어 이러한 방법은 거의 쓰지 않는다.
- 인증서를 브라우저 저장소에 영속시기는 경우
로그인시 토큰을 브라우저 스토리지에 유지시키며 모든 REST 요청시에 이 토큰과 함께 인증 헤더를 보낼 수 있다. 가장 일반적으로 사용하는 JWT 인증방식이며 실제 쿠키와 달리 브라우저 저장 변수는 자동으로 서버로 전송되지 않기 때문에
다른 하이제킹 사이트로 클라이언트를 유도하여 요청을 강제해도 토큰이 서버로 날릴 수 없기 때문에 CSRF 공격으로 부터 안전하다.
결론: Spring Security 사용시 서버가 사용자 인증정보 즉 로그인시 Session 을 생성하여 상태 유지속성을 갖고있을경우 CSRF 공격에 대한 대비를 해야하며 인증정보 JWT 토큰과 같은 인증서 정보를 모든 Request 마다 담아서 보내줄 경우 CSRF 공격에 대해 대비가 되기때문에 http.csrf().disabled() 처리를 하여도 무관하다
