CSRF는 Cross-Site Request Forgery의 약자입니다. 사용자가 어떤 서비스에 로그인해 있고 쿠키 인증을 사용한다면, 브라우저는 해당 사이트로 요청을 보낼 때 쿠키를 자동으로 포함할 수 있습니다. 공격자는 이를 이용해 사용자가 의도하지 않은 송금, 설정 변경 같은 요청을 보내게 만들 수 있습니다.
서버 입장에서는 쿠키가 붙어 있으니 정상 사용자 요청처럼 보일 수 있습니다. 방어하려면 서버가 예측 불가능한 CSRF token을 확인하거나, SameSite cookie를 설정하고, 중요한 작업에는 추가 확인을 요구할 수 있습니다.
꼬리질문
조금 더 깊게 물어본다면
답변 뒤에 이어질 수 있는 질문들을 하나씩 열어볼 수 있어요.
CSRF token은 어떻게 도움이 되나요?
서버가 사용자 session과 연결된 예측 불가능한 token을 발급하고, 중요한 요청에 그 token이 함께 오는지 확인합니다. 공격자는 다른 사이트에서 피해자의 token을 알기 어렵습니다.
쿠키만으로 인증하지 않고 요청 의도를 한 번 더 확인하는 방식입니다.
SameSite cookie는 어떤 역할을 하나요?
SameSite는 cross-site 요청에 cookie를 보낼지 제한하는 옵션입니다. Lax, Strict, None 같은 값이 있고, CSRF 위험을 줄이는 데 도움이 됩니다.
다만 서비스 요구사항과 OAuth redirect 같은 흐름 때문에 값을 신중히 정해야 합니다.
GET 요청도 CSRF 위험이 있나요?
상태를 바꾸는 작업을 GET으로 만들면 위험할 수 있습니다. GET은 안전하고 멱등적인 조회에 가깝게 설계하는 것이 좋습니다.
상태 변경은 POST/PUT/DELETE와 추가 검증을 사용하는 편이 안전합니다.
XSS가 있으면 CSRF 방어가 무력화될 수 있나요?
많은 경우 그렇습니다. XSS로 페이지 안의 CSRF token을 읽거나 정상 요청을 직접 만들 수 있기 때문입니다.