프로그래밍/개발 팁

CSRF 공격과 강력한 방어 전략 🛡️

다다면체 2025. 6. 23. 09:07
728x90
반응형

안녕하세요! 오늘은 웹 보안의 중요한 주제 중 하나인 CSRF (Cross-Site Request Forgery) 공격에 대해 알아보고, 이를 효과적으로 방어할 수 있는 전략들을 자세히 살펴보겠습니다. 웹 서비스를 운영하거나 이용하는 분들이라면 반드시 알아두어야 할 내용이니, 집중해서 읽어주세요! 😊

CSRF 공격이란?

CSRF는 사이트 간 요청 위조라고도 불리며, 사용자가 의도하지 않은 요청을 강제로 실행하도록 만드는 공격 기법입니다. 공격자는 사용자가 로그인된 상태를 악용하여, 사용자의 세션을 가로채지 않고도 사용자의 권한으로 특정 행위를 수행하게 만듭니다.

🔍 CSRF 공격 시나리오 예시

좀 더 쉽게 이해할 수 있도록 실제 공격 시나리오를 통해 설명해 드릴게요.

상황 설정:

  • 은행 웹사이트 (정상 사이트): bank.com
  • 공격자 웹사이트 (악성 사이트): attacker.com
  • 피해자: bank.com에 로그인하여 정상적으로 이용 중인 사용자

공격 과정:

  1. 사용자 로그인: 피해자가 bank.com에 로그인하여 계좌 이체, 비밀번호 변경 등의 작업을 수행합니다. 이때, 피해자의 브라우저에는 bank.com의 인증 쿠키가 저장됩니다.
  2. 악성 웹사이트 방문 유도: 공격자는 attacker.com에 다음과 같은 악성 코드를 포함한 페이지를 만듭니다. 이 코드는 피해자가 bank.com에 특정 요청을 보내도록 유도합니다. 예를 들어, 100만 원을 공격자의 계좌로 이체하는 요청이라고 가정해 봅시다.이 예시에서는 <img> 태그의 src 속성을 이용해 bank.com으로 위조된 요청을 보냅니다. <img> 태그는 페이지 로딩 시 자동으로 src에 지정된 URL로 요청을 보내기 때문에, 사용자는 아무것도 클릭하지 않아도 공격이 실행될 수 있습니다. 
    <html>
<body>
    <img src="http://bank.com/transfer?account=attacker_account&amount=1000000" style="display:none;">
    <script>
        // 또는 AJAX 요청을 이용할 수도 있습니다.
        // window.onload = function() {
        //    fetch('http://bank.com/transfer?account=attacker_account&amount=1000000', { method: 'GET' });
        // };
    </script>
    <p>무료 영화 다시보기!</p>
</body>
</html>
  3. 공격 실행: 피해자가 bank.com에 로그인된 상태에서 attacker.com에 접속합니다. 피해자의 브라우저는 attacker.com 페이지를 로드하면서, <img src="..."> 태그에 의해 bank.com으로 위조된 이체 요청을 보냅니다. 이때, bank.com에 저장되어 있던 인증 쿠키도 함께 전송됩니다.
  4. 은행 서버의 오인: bank.com 서버는 이 요청이 피해자의 브라우저에서 합법적으로 보낸 것으로 판단하여, 100만 원을 공격자의 계좌로 이체하는 작업을 수행합니다. 피해자는 자신이 의도하지 않은 금융 거래가 발생했음을 알지 못할 수 있습니다. 😱

이처럼 CSRF 공격은 사용자의 세션을 직접 탈취하지 않고도, 사용자의 권한으로 악의적인 행위를 가능하게 하여 심각한 피해를 초래할 수 있습니다.

🛡️ CSRF 공격 방어 전략

그렇다면 이러한 CSRF 공격으로부터 우리의 웹 서비스를 어떻게 보호할 수 있을까요? 다음은 효과적인 방어 전략들입니다.

1. CSRF 토큰 (CSRF Token) 🔑

가장 널리 사용되고 효과적인 CSRF 방어 전략 중 하나가 바로 CSRF 토큰입니다.

작동 방식:

  1. 토큰 생성: 사용자가 웹 페이지를 요청할 때, 서버는 고유하고 예측 불가능한 CSRF 토큰을 생성합니다.
  2. 토큰 삽입: 이 토큰은 HTML 폼의 숨겨진 필드나 HTTP 헤더에 삽입되어 클라이언트로 전송됩니다. 
    <form action="/transfer" method="POST">
    <input type="hidden" name="_csrf" value="[서버에서 생성된 CSRF 토큰]">
    <input type="text" name="amount" placeholder="이체 금액">
    <button type="submit">이체</button>
</form>
  3. 토큰 검증: 클라이언트가 폼을 제출하거나 특정 요청을 보낼 때, 서버는 전송된 토큰과 서버에 저장된 (또는 세션에 연결된) 토큰을 비교하여 일치하는지 확인합니다.
  4. 요청 처리: 두 토큰이 일치하면 정상적인 요청으로 간주하여 처리하고, 일치하지 않으면 위조된 요청으로 판단하여 거부합니다.

CSRF 토큰의 장점:

  • 공격자는 사용자의 세션 정보 없이 CSRF 토큰을 알 수 없으므로, 위조된 요청에 유효한 토큰을 포함시킬 수 없습니다.
  • 세션마다 고유한 토큰을 사용하여 재사용 공격을 방지할 수 있습니다.

2. SameSite 쿠키 설정 🍪

최신 브라우저에서 지원하는 강력한 방어 메커니즘 중 하나는 SameSite 쿠키 속성입니다. 이 속성은 브라우저가 서드파티 컨텍스트에서 쿠키를 어떻게 전송할지 제어합니다.

주요 SameSite 속성 값:

  • SameSite=Lax (기본값): 대부분의 브라우저에서 기본값으로 설정되어 있습니다. GET 요청 시에는 다른 도메인에서 요청이 발생해도 쿠키를 전송하지만, POST 요청이나 다른 위험한 요청(PUT, DELETE 등) 시에는 같은 도메인에서만 쿠키를 전송합니다. CSRF 공격 방어에 효과적입니다.
  • SameSite=Strict: 가장 강력한 설정입니다. 브라우저가 다른 도메인에서 요청이 발생하면 절대로 쿠키를 전송하지 않습니다. 이는 보안을 강화하지만, 다른 웹사이트에서 링크를 통해 들어올 때 로그인 상태가 유지되지 않는 등 사용자 경험에 영향을 줄 수 있습니다.
  • SameSite=None: Secure 속성과 함께 사용해야 하며, 다른 도메인에서도 쿠키가 전송되도록 허용합니다. 이 설정은 CSRF 방어에는 도움이 되지 않으며, 주로 교차 도메인 요청이 필요한 경우 (예: 서드파티 위젯, 광고 등)에 사용됩니다.

SameSite 쿠키의 장점:

  • 개발자가 추가적인 코드 변경 없이 서버 설정만으로 CSRF 공격을 방어할 수 있습니다.
  • 클라이언트 측에서 공격을 차단하므로 서버 부하를 줄일 수 있습니다.

3. Referer 검증 🌐

Referer 헤더는 HTTP 요청이 어디에서 시작되었는지 알려주는 정보를 담고 있습니다. 서버는 이 Referer 헤더를 확인하여 요청이 신뢰할 수 있는 출처에서 왔는지 검증할 수 있습니다.

작동 방식:

  1. 서버는 요청의 Referer 헤더 값을 확인합니다.
  2. Referer 헤더의 도메인이 자신의 도메인과 일치하는 경우에만 요청을 허용합니다.

Referer 검증의 한계:

  • 일부 브라우저나 프록시 설정에 따라 Referer 헤더가 전송되지 않거나 조작될 수 있습니다.
  • HTTPS에서 HTTP로의 요청 시 Referer 정보가 누락될 수 있습니다.
  • 따라서 단독으로 사용하기보다는 CSRF 토큰 등 다른 방어 전략과 함께 보조적인 수단으로 활용하는 것이 좋습니다.

맺음말 ✨

CSRF 공격은 사용자에게 심각한 피해를 줄 수 있는 위협이지만, CSRF 토큰, SameSite 쿠키 설정과 같은 적절한 방어 전략을 통해 충분히 막아낼 수 있습니다. 웹 서비스를 개발하고 운영하시는 분들은 오늘 소개해 드린 내용들을 꼭 적용하셔서 안전한 웹 환경을 구축하시길 바랍니다. 궁금한 점이 있다면 언제든지 댓글로 문의해주세요! 😉

728x90
반응형
저작자표시 비영리 변경금지 (새창열림)