CSRF 란

CSRF(Cross-Site Request Forgery, 사이트 간 요청 위조)는 사용자가 의도치 않은 요청을 특정 웹 애플리케이션에 보내게 함으로써 악의적인 행위를 수행하는 웹 보안 취약점이다. CSRF는 사용자가 이미 인증된 상태라는 점을 악용하며, 사용자가 모르게 서버에 요청을 보내도록 만들어 공격자가 원하는 행동을 수행하게 만든다.

동작원리

CSRF는 피해자가 특정 웹 애플리케이션에 로그인한 상태라는 것을 악용한다. 공격자는 피해자가 이 인증된 상태에서 의도치 않은 요청을 보내도록 유도하며, 서버는 이 요청을 피해자의 인증 정보로 신뢰하고 수행하게 된다.

  1. 피해자가 특정 웹사이트(예: 은행 사이트)에 로그인하여 세션이 유지되는 상태가 된다.
  2. 공격자는 악의적인 웹사이트를 피해자에게 클릭하도록 유도하거나 이메일, 메신저 등을 통해 피해자가 특정 URL에 접근하게 만든다.
  3. 피해자가 해당 악성 URL을 클릭할 때, 기존 세션을 이용하여 서버에 요청이 전달되며 서버는 이를 정상적인 요청으로 인식하고 수행하게 된다.
  4. 결과적으로 피해자는 자신도 모르게 공격자가 의도한 행동(송금, 정보 수정 등)을 수행하게 된다.

특징

  • 사용자의 인증 상태를 악용: CSRF는 피해자가 이미 로그인 상태임을 전제로 한다. 서버는 피해자의 인증 정보를 기반으로 요청을 수행한다.
  • 클라이언트 측 조작 필요 없음: 사용자는 단순히 링크 클릭이나 페이지 접근만으로 공격에 노출될 수 있다.
  • 브라우저의 Same-Origin Policy와 상관 없음: CSRF는 사용자의 브라우저가 요청을 보낼 때 자동으로 인증 정보를 첨부한다는 점을 악용하여 서버에서의 출처 검사를 우회한다.

예시

예를 들어, 은행 웹사이트에서 피해자가 로그인 상태로 있는 동안 악의적인 사이트에 접근할 경우, 다음과 같은 악성 요청을 유도할 수 있다:

<img src="https://bank-website.com/transfer?account=attacker&amount=1000" style="display:none;">

위의 img 태그는 공격자의 계좌로 1000원의 금액을 송금하는 요청을 포함하고 있다. 피해자가 이 HTML을 포함한 페이지에 접근할 때 은행 사이트는 피해자가 이미 인증된 사용자임을 인식하고 해당 요청을 처리한다.

방지방법

CSRF 방지는 주로 요청의 출처 확인과 CSRF 토큰 사용을 통해 이루어진다.

1. CSRF 토큰 (Anti-CSRF Token) 사용

CSRF 토큰은 각 요청마다 유일한 값이 포함되도록 하여 이를 서버에서 검증함으로써 CSRF 공격을 방지한다.

  • 생성: 서버는 각 사용자 세션에 대해 유일한 토큰을 생성하고, 이를 사용자에게 전달한다.
  • 검증: 서버는 요청 시 전달받은 CSRF 토큰을 검증하여 유효한 경우에만 요청을 처리한다.
  • 폐기: 특정 작업이 완료되거나 세션이 만료되면 토큰을 폐기한다.

예시:

  1. 사용자가 폼을 요청하면, 서버는 CSRF 토큰을 생성해 폼에 숨김 필드로 추가하여 제공한다.
  2. 사용자가 폼을 제출할 때, CSRF 토큰도 함께 전송된다.
  3. 서버는 전달받은 CSRF 토큰을 세션에 저장된 토큰과 비교하고 일치하는 경우에만 요청을 처리한다.

2. Referer 헤더 확인 서버는 HTTP 요청의 Referer 헤더를 검사하여 요청이 신뢰할 수 있는 출처(예: 자사 도메인)에서 발생한 것인지를 확인할 수 있다. 그러나 일부 클라이언트나 네트워크 환경에서 Referer 헤더가 차단될 수 있기 때문에 완벽한 방법은 아니다.

3 SameSite 쿠키 속성 설정 SameSite 쿠키 속성을 Strict 또는 Lax로 설정하여, 외부 출처에서 쿠키를 전송할 수 없도록 제한한다.

  • Strict: 오직 동일한 사이트의 요청에만 쿠키가 포함된다.
  • Lax: 일부 안전한 요청(GET 요청)에는 쿠키가 포함될 수 있으나 POST 요청에는 제한된다.

CSRF 방어의 한계와 주의점

  • 사용자 경험: CSRF 방어는 사용자가 특정 작업을 수행하기 전 추가 인증 과정을 거쳐야 하는 경우 사용자 경험에 영향을 줄 수 있다.
  • Referer 헤더 차단 가능성: 일부 네트워크 환경에서는 Referer 헤더가 차단되어 유효성을 검사하기 어렵다.
  • 추가 인증 필요: 보안이 중요한 요청(예: 송금, 비밀번호 변경 등)에는 이중 인증(2FA) 또는 추가 인증이 필요할 수 있다.

CSRF와 관련된 오해

  • XSS와 CSRF의 혼동: XSS는 악성 스크립트가 웹사이트에 삽입되는 공격이며, CSRF는 피해자의 인증 정보를 이용해 서버에 요청을 보내는 공격이다.
  • 쿠키가 없는 상태에서의 CSRF 가능성: CSRF는 보통 사용자가 인증된 상태에서만 작동한다. 쿠키가 없거나 로그아웃된 상태라면 대부분의 CSRF 공격은 실행되지 않는다.

결론

CSRF는 피해자의 인증 정보를 악용하여 서버에 악의적인 요청을 전달하는 웹 보안 취약점이다. 서버에서는 이를 방지하기 위해 CSRF 토큰, SameSite 쿠키, Referer 검사와 같은 다양한 보안 조치를 구현해야 하며, 중요한 요청에 대해서는 추가 인증을 도입하는 것이 보안성을 높이는 데 유리하다. CSRF 방지는 서버의 정책 설정과 클라이언트의 요청 검증을 통해 이루어져야 하며, XSS와 혼동되지 않도록 각 보안 취약점의 특성을 이해하는 것이 중요하다.