reference
CSRF (Cross-Site Request Forgery)
CSRF는 피해자가 자신의 의지와는 무관하게, 공격자가 원하는 웹 요청을 실행하게 만드는 공격입니다. 이 공격은 피해자가 공격자가 만든 악성 웹사이트나 이메일에 포함된 링크를 클릭하도록 유도하는 형태로 발생합니다. 예를 들어, evil.com 이라는 사이트에서 버튼을 클릭하면, 사용자의 지식 없이 example.com 의 특정 기능을 실행하는 요청이 보내질 수 있습니다. CSRF 공격은 피해자의 쿠키에 저장된 정보를 사용하여 example.com 에 요청을 보냅니다. 따라서, example.com 서버는 이를 정상적인 요청으로 간주합니다.
그렇다면 어떻게 해야지 공격을 예방할 수 있을까요? 쿠키 옵션관점에서 예방방법을 적어볼게요.
1. 쿠키 옵션의 HttpOnly 를 true 로 설정하기 - CSRF 공격 예방, XSS 공격 예방
이를 통해 HttpRequest를 통해서만 cookie 정보를 전달할 수 있습니다(document.cookie 명령어 제한을 통해 쿠키 접근을 제한합니다.) 하지만, 쿠키를 JS 로 열지 못하게 막을 뿐, 쿠키정보를 그대로 전달하는 것은 가능하기 때문에 원천적인 예방법은 아닙니다.
2. 쿠키 옵션의 Secure 를 true 로 설정하기 - CSRF 공격 예방
Secure 옵션은 HTTPS 에서만 쿠키정보가 전달되도록 설정하는 옵션입니다. 즉, 헤더포함 모든 부분을 암호화하여 전송한다는 것이죠. 하지만, 마찬가지로 HTTPS 에서 쿠키정보를 그대로 전달하는 것은 가능하기 때문에 원천적인 예방법은 아닙니다.
3. 쿠키 옵션의 SameSite 를 Lax 로 설정하기 - CSRF 공격 예방
SameSite=Lax 로 설정하게 된다면, Cross-Site(다른 도메인)에서 오는 POST, PUT, DELETE, PATCH 요청에 쿠키정보를 전달하지 않습니다. 예로 evil.com 에서 example.com 에 DELETE /user 요청을 보낸다고 가정해봅시다. 이 때, example.com 에서는 SameSite=Lax 옵션을 통해 쿠키정보를 전달하지 않습니다.
그럼 만약 SameSite=STRICT 라면 어떻게 될까요? SameSite=STRICT 라면, Cross-Site(다른 도메인)에서 오는 모든 요청에 쿠키정보를 전달하지 않습니다. 뭘 하든간에 쿠키정보를 전달하지 않는 것이죠. 만약 같은 도메인으로부터의 요청이 아니라면 말이죠! 다만 사용자들이 매우 불편해할 수 있어요.
정리해보았을 때, HttpOnly=true, Secure=true, SameSite=Lax 로 중요한 쿠키를 관리하게 된다면 CSRF 공격을 예방할 수 있습니다.
추가정보
- Refresh Token 발급의 목적
- 긴 수명의 인증: 액세스 토큰은 일반적으로 짧은 수명을 가집니다. 만약 액세스 토큰이 만료되면 사용자는 다시 로그인을 해야 합니다. 리프레시 토큰은 이런 불편함 없이 액세스 토큰을 새로 발급받을 수 있도록 해줍니다.
- 보안 강화: 액세스 토큰이 유출되더라도 해당 토큰의 수명이 짧다면 공격자가 그 토큰을 이용한 무한한 액세스를 가질 수 없습니다. 만약 토큰이 노출되면 그 토큰의 수명 동안만 유효하며, 리프레시 토큰을 통해 새로운 액세스 토큰을 발급받아야 합니다.
- 토큰 갱신: 사용자가 활동적으로 애플리케이션을 사용하는 동안에는 계속해서 액세스 토큰을 갱신받을 수 있습니다. 이를 통해 사용자는 끊김없이 서비스를 이용할 수 있고, 오랜 시간 동안 비활동적인 사용자는 자동으로 로그아웃됩니다.
- 토큰의 회수: 특정 상황에서는 사용자의 세션을 강제로 종료해야 할 필요가 있을 수 있습니다. 리프레시 토큰을 사용하면 서버 측에서 해당 리프레시 토큰을 무효화함으로써 사용자의 세션을 종료시킬 수 있습니다.
- 다중 디바이스 지원: 사용자가 여러 디바이스에서 동시에 로그인할 경우 각 디바이스에 대해 별도의 리프레시 토큰을 발급할 수 있습니다. 이를 통해 특정 디바이스의 로그인만을 무효화시킬 수 있습니다.