Rest API 서버에서 CSRF 공격을 방어해야할까요?

안녕하세요.

 

이번 글은 spring security 설정 중 CSRF를 꺼놓았던 기억 때문에 작성하게 되었습니다.

 

우리는 왜 CSRF를 꺼놓게 되었을까요?

 

 

 

 

CSRF, XSS 공격

 

XSS : 공격자가 JS로 접근 가능한 곳의 정보를 꺼내 사용한다.

CSRF : 공격자가 서버에 사용자 몰래 요청을 보내는 것이다 ->이는 요청 정보가 cookie에 저장되어 있기에 가능한 공격이다.

 

가끔 글들을 보다 보면 XSS와 CSRF 등의 문제로 쿠키를 지양하는데, 저는 생각이 다릅니다.

XSS는 HttpOnly로 막고 CSRF는 서버단에서 referer를 검증 또는 csrf token을 사용하면 방어할 수 있다고 생각합니다.

 

다른 생각이었지만 SOP로도 막을 수 있을 것이라 생각했지만 이는 틀렸다. 브라우저가 아닌 공간에서 쓰기 요청은 가능하기 때문입니다.

 

 

 

우리는 왜 CSRF를 꺼놓게 되었을까요?

 

최근에는  API 서버만 두는 경우가 많습니다.

 

저 또한 서버와 프론트를 따로 분리하여 관리하고 있습니다.

 

그럴 경우 서버는 무상태성을 가지기에 CSRF는 방어하지 않아도 된다는 것입니다.

 

 

과연 그럴까요? 

Baeldung의 이야기를 들어보면 다릅니다.

CSRF With Stateless REST API | Baeldung

Cookie의 인증 토큰이 들어 있으면 csrf 공격은 가능하다는 것입니다.

 

Rest API는 무상태성을 지향하지만 로그인 등의 정보를 검사해야 할 수 있습니다.

 

이때 서버가 아닌 클라이언트에게 로그인 관련 정보를 할당하는 것입니다. ex. Token

 

 

 

그렇다면 Spring security의 CSRF 속성을 켜야 할까요?

해당 설정은 켜면 CSRF Token을 검증하게 됩니다.

 

서버에서 페이지를 내려주는 구조는 프론트에서 token을 가지고 서버에서 검증하기 쉽지만 

 

서버와 프론트가 따로 서버를 구축한 경우에는 쉽지 않은 구현입니다.

 

다르게 생각해 보면 서버는 무상태성을 지향하기에 꺼 놓아도 됩니다.

 

단 위에서도 말했듯이 로그인 등의 정보를 쿠키를 통해 사용하다면 방어책을 마련해야 합니다.

(Auth 헤더에 담을 경우는 CSRF로부터 안전합니다. Cookie는 자동으로 보내지기 때문에)

 

 

방어법

1. Same Site

Cookie는 사용하되 방어법으로는 cookie에 same site 속성을 걸어 csrf를 방지하는 것입니다.

 

Defending against CSRF with SameSite cookies | Web Security Academy

Same site를 Lax로 설정 시 몇 가지 규칙을 지켜줘야 합니다.

• 일부 응용 프로그램은 GET 요청을 사용하여 민감한 작업을 구현합니다.
• 많은 애플리케이션과 프레임워크는 다양한 HTTP 메서드를 허용합니다. 이 상황에서 응용 프로그램 자체가 의도적으로 POST 메서드를 사용하더라도 실제로 GET 메서드를 사용하도록 전환된 요청을 수락합니다.

Strict로 만드는 것이 구현에 편할 것 같습니다.

 

++

하지만 사용자의 브라우저에 따라, 버전에 따라 지원하지 않을 수 있으니 아직까지는 하위호환성을 지키는 완벽한 방어법은 X

Do I still need CSRF protection when SameSite is set to Lax?

 

2. Referer 검증

 

CSRF(Cross-Site Request Forgery) 공격과 방어

위의 글은 정통적인 방어 법인 referer를 통해 csrf를 방지하는 구현입니다.

 

 

 

 

 

결론

Should I use CSRF protection on Rest API endpoints?

 

Rest API에서 CSRF를 방어하지 않는 이유는..

 

(쿠키 없음 = CSRF 없음, REST = 상태 비저장, REST ≠ 쿠키 없음 -> Http only)

즉 Rest API는 state less이기 때문에 csrf를 방어하지 않는다는 것,

단 로그인 등의 정보를 cookie로 관리할 경우 cookie는 Http only(XSS 보호), same site(CSRF 보호)로 방어되어야 된다는 것.(브라우저 버전에 따라 상이)

 

즉 cookie가 안전할 경우에만 csrf를 방어하지 않아도 된다는 것입니다.

 

user정보가 필요하다면 token에서 정보를 얻는 것이 아닌 API콜을 한번 더 해서 얻을 수 있겠습니다.