CSRF란 무엇인가? CSRF를 어떻게 방지할 수 있는가?

디지털 시대에 인터넷은 우리 일상생활의 일부가 되었습니다. 우리는 쇼핑부터 다양한 플랫폼에서의 소셜 활동, 은행 거래까지 많은 활동을 온라인으로 옮겼습니다. 금융 상호작용이 더욱 보편화되면서, 네트워크 보안의 영향력도 더욱 두드러지게 되었습니다. 인터넷에서 가장 흔한 사이버 위협 중 하나는 CSRF(Cross-site request forgery)이며, 이에 대한 세부 사항을 깊이 이해하는 것이 중요합니다.

CSRF란 무엇인가?

CSRF 공격은 대상 웹사이트의 요청 검증 메커니즘의 취약점을 이용합니다. 특정 상황에서 사용자는 대상 웹사이트에 로그인한 상태에서 악의적인 요청을 무의식적으로 실행하게 됩니다. 공격자는 일반적으로 대상 웹사이트의 도메인과 유사한 주소를 사용하여 사용자를 유인합니다. 그들은 이미지 로드나 숨겨진 폼으로 위장하여 악성 코드를 삽입하고, 대상 웹사이트에 요청을 보내어 은밀한 무단 행동을 실행합니다. 사용자 비밀번호 변경이나 무단 은행 이체와 같은 목표는 사용자에게 큰 손실을 초래할 수 있습니다.

실제 사례

e-bank.com이라는 전자 은행 서비스를 제공하는 웹사이트를 상상해 보세요. 이 웹사이트에는 이체 요청을 제출하는 /transfer 페이지가 있습니다. 사용자가 e-bank.com/transfer 페이지에 접근하면, 사용자가 입력한 세부 정보를 표시하는 폼이 나타납니다. 폼을 작성하고 제출하면, 사용자가 입력한 수신자와 금액과 같은 매개변수를 포함한 HTTP POST 요청이 페이지 주소로 전송됩니다.

이 시점에서 공격자는 e-bank.com/transfer로 제출 주소를 지정하는 보이지 않는 폼이 있는 악성 페이지를 구성할 수 있습니다. 공격자는 특정 수신자와 금액 매개변수를 미리 채웁니다. 사용자가 이 악성 페이지를 클릭하도록 속이면, 브라우저는 JavaScript 코드를 실행하여 폼을 제출합니다.

사용자가 e-bank.com에 등록되어 있지 않거나 로그인하지 않은 상태라면, 이체 요청은 실행될 수 없습니다. 그러나 사용자가 최근에 서비스를 사용했고 로그인 상태가 유지된다면, 이체 요청이 성공적으로 실행될 수 있습니다.

이것이 CSRF 공격의 핵심입니다. 원리는 간단하지만 엄청난 잠재적 피해를 초래할 수 있습니다. 다행히도, 이러한 공격을 방지할 수 있는 여러 가지 성숙한 방법이 있습니다. 아래에서 이를 살펴보겠습니다.

CSRF를 어떻게 방지할 수 있는가?

이 문제를 해결하기 위해서는 적극적이고 수동적인 조치가 필요합니다.

HTTP 메서드 제한 및 Referer 제한

개발자로서, 우리는 서비스 내의 민감한 주소에 대해 더 엄격한 제한을 적용할 수 있습니다. 예를 들어:

데이터 제출이 필요한 주소의 경우, HTTP GET 요청을 금지하고 POST 요청을 사용하도록 강제할 수 있습니다. 이는 공격자가 악성 페이지를 구성하려는 시도를 더 복잡하게 만듭니다.
또한, HTTP 요청 헤더의 Referer 필드(Referer)를 제한하여 알려진 합법적인 주소에서만 허용하고 악성 요청을 차단할 수 있습니다.

이것은 간단하고 적극적인 보호 조치로, 비용은 낮지만 여전히 공격에 취약할 수 있습니다.

CSRF 토큰

CSRF 토큰은 서버 측 세션 메커니즘과 결합하여 CSRF 공격을 방지하는 널리 사용되는 솔루션입니다. 구체적으로, 서버 측 프로그램은 보호가 필요한 페이지의 출력 폼에 무작위로 생성된 CSRF 토큰을 포함하는 숨겨진 입력 필드를 삽입합니다. 동시에, 서버 측에 세션을 생성하여 이 무작위 문자열을 만료 시간과 함께 저장합니다.

사용자가 페이지를 요청하면, 서버는 세션을 초기화하고 서버 측에 데이터를 저장하며, 클라이언트 측 브라우저에 세션 ID를 포함한 쿠키를 설정하여 연관성을 유지합니다. CSRF 토큰은 세션에 저장됩니다. 폼이 제출되면, CSRF 토큰이 전송됩니다. 서버 측 프로그램은 이 토큰을 세션에 저장된 부분과 비교합니다. 검증이 성공하면 후속 로직이 실행되고, 그렇지 않으면 오류가 반환됩니다. 동시에, 다음 제출을 위해 새로운 CSRF 토큰이 폼에 삽입됩니다.

이것은 적극적인 보호 조치로, 약간의 노력이 필요하지만 강력한 보호를 제공합니다.

교차 출처 보호

우리는 종종 CORS(Cross-Origin Resource Sharing)라는 기술을 접합니다. 이는 브라우저가 교차 출처 요청을 허용하는지 여부를 나타내는 사양입니다. 현대 브라우저는 이 사양을 지원합니다. 기존 페이지에서 Fetch/XHR 요청을 시작할 때, 브라우저는 HTTP OPTIONS 요청을 보내어 대상 서비스가 현재 출처 주소에서의 요청을 허용하는지 사전 확인합니다. 서버는 허용된 출처, 요청 메서드 및 헤더를 지정하는 응답 헤더 목록을 제공합니다. 브라우저는 이러한 지시를 따르며, 클라이언트 측에서 금지된 요청을 방지합니다.

이것은 서버 측에서 구성할 수 있는 또 다른 적극적인 보호 조치입니다. 그러나 일반 사용자가 이 기능을 비활성화할 가능성은 낮지만, 클라이언트 측에서는 여전히 가능합니다.

제3자 쿠키 차단

우리가 개발한 서비스는 때때로 사용자 세션 ID를 쿠키에 저장하여 로그인 상태를 유지합니다. 쿠키는 SameSite 설정을 지원하여 브라우저가 교차 출처 사이트에 쿠키를 보내지 못하도록 합니다. CSRF 공격을 시도하면 대상 사이트에서 인증되지 않은 상태가 됩니다.

또한, HTTP 쿠키 메커니즘의 오용으로 인해 브라우저 개발자들은 점차적으로 제3자 쿠키(Cookie Countdown)를 제한하고 차단하기로 결정했습니다. 도메인 A의 페이지가 도메인 B에 대한 호출을 시도할 때, CORS 규칙 검사를 통과하더라도 브라우저는 해당 교차 출처 사이트에 쿠키를 보내지 않습니다.

Chrome Timeline Example

요약

API 게이트웨이로서, Apache APISIX와 API7 Enterprise는 CSRF 토큰과 CORS라는 두 가지 보호 조치를 지원하여 CSRF 공격을 방지합니다.

결론적으로, CSRF 공격을 방지하기 위해서는 서버 측, 브라우저, HTTP 프로토콜 등 다양한 기술을 통합한 다각적인 접근 방식이 필요합니다. 이를 통해 포괄적인 보호를 달성할 수 있습니다.