코더의 보안 정복: 공유 및 학습 시리즈 - 사이트 간 요청 위조(CSRF)

웹사이트나 애플리케이션 운영자를 직접 겨냥하는 공격과 달리, 많은 사이트 간 요청 위조(CSRF) 공격의 목표는 사용자로부터 직접 돈, 상품 또는 자격 증명을 탈취하는 것입니다. 그렇다고 사이트 운영자가 CSRF 코드 취약점을 무시해도 된다는 뜻은 아닙니다. 금전적 피해가 발생할 경우, 탈취된 자금을 보상해야 하는 책임이 보안이 취약한 코드를 운영한 호스팅 사이트에 있을 수 있기 때문입니다. 또한 사용자가 자격 증명을 탈취당하거나 비밀번호가 자신도 모르게 변경되면, 공격자는 훔친 신원을 이용해 큰 피해를 입힐 수 있으며, 특히 피해자가 높은 권한을 가진 경우 그 위험성은 더욱 커집니다.

CSRF 공격은 상당히 복잡하며 성공하기 위해 여러 단계의 조건이 충족되어야 합니다. 다시 말해, 공격자가 의도한 대로 상황이 흘러가려면 많은 요소가 맞아떨어져야 합니다. 그럼에도 불구하고, CSRF는 매우 대중적인 공격 방식입니다. 공격에 성공하면 돈을 해커의 계좌로 직접 이체하거나, 사이트 내에서 자유롭게 활동할 수 있는 권한을 얻을 수 있기 때문입니다. 모든 과정이 해커의 계획대로 진행되면, 피해자는 자신이 공격을 당했다는 사실조차 모를 수 있습니다.

다행인 점은 CSRF 공격이 성공하기 위해 충족되어야 할 조건이 많기 때문에, 이를 효과적으로 차단할 수 있는 훌륭한 방어 기술들이 존재한다는 것입니다.

이를 위해 CSRF 공격의 세 가지 핵심 측면을 살펴보겠습니다.

• 작동 원리
• 위험한 이유
• 공격을 완벽하게 차단하는 방어 방법

CSRF 공격은 어떻게 작동할까요?

CSRF 공격은 성공 시 사용자로부터 돈, 상품, 자격 증명을 직접 탈취할 수 있기 때문에, 공격을 준비하는 데 많은 노력이 필요함에도 불구하고 널리 사용됩니다. 또한 다양한 플랫폼에서 시도되기 때문에 수년에 걸쳐 여러 이름으로 불려 왔습니다. CSRF 공격은 XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery 또는 Hostile Linking 등으로 불리기도 합니다. 마이크로소프트는 대부분의 문서에서 이를 '원클릭(One-Click) 공격'이라고 지칭합니다. 하지만 이들은 모두 CSRF 공격이며, 이를 방어하는 기술은 동일합니다.

CSRF 공격은 사용자가 업무를 보거나 사이트를 이용하기 위해 로그인한 상태에서 발생할 수 있습니다. 핵심은 사용자가 웹사이트나 애플리케이션에 로그인하여 활성 인증 상태여야 한다는 점입니다. 공격은 일반적으로 다른 웹사이트나 이메일을 통해 시작됩니다. 공격자들은 종종 사회 공학적 기법을 사용하여 사용자가 이메일의 링크를 클릭하도록 유도하고, 공격 스크립트가 포함된 악성 웹사이트로 접속하게 만듭니다.

악성 웹사이트에는 활성 브라우저에 명령을 실행하도록 지시하는 스크립트가 포함되어 있습니다. 보통 비밀번호 변경이나 공격자가 제어하는 계좌로의 자금 이체와 같은 악의적인 명령이 실행됩니다. 사용자가 인증된 상태라면, 사이트는 해당 명령이 권한 있는 사용자에 의해 내려진 것으로 간주합니다. 당연히 그럴 수밖에 없습니다. 사용자는 이미 인증을 마쳤고 사이트 접속에 필요한 비밀번호를 제공했기 때문입니다. 심지어 사용자가 지오펜싱(geofencing) 내에 있거나 사무실 단말기 앞에 제대로 앉아 있을 수도 있습니다. 사용자가 비밀번호를 변경하거나 자금을 이체하려 한다면, 사이트 입장에서는 이를 본인의 요청으로 믿지 않을 이유가 없습니다.

공격 요소를 분석해 보면, 왜 이 공격이 실행하기 어려운지 명확해집니다. 우선, 공격이 발생하는 사이트에 사용자가 활성 인증 상태여야 합니다. 사용자가 브라우저 세션을 종료하거나 로그아웃한 후에 공격 스크립트가 포함된 이메일을 확인한다면 공격은 실패합니다.

또한 공격자는 대상 사이트가 어떤 스크립트를 허용하는지 파악하기 위해 많은 정찰을 수행해야 합니다. 공격자는 피해자의 화면을 볼 수 없으며, 웹사이트로부터의 모든 피드백은 공격자가 아닌 피해자에게 전달됩니다. 공격자가 자신의 계좌로 돈이 입금되는 것과 같이 공격 성공의 증거를 직접 확인하지 못하는 한, 공격이 성공했는지조차 즉시 알 수 없습니다.

사용자가 공격 시점에 로그인되어 있어야 하고 대상 사이트가 허용하는 스크립트를 알아야 한다는 까다로운 조건 속에서도, CSRF 공격을 실행하는 코드는 매우 간단할 수 있습니다. 물론 이는 사이트마다 다릅니다.

은행이나 금융 애플리케이션이 자금 이체를 위해 다음과 같은 GET 요청을 사용한다고 가정해 보겠습니다.

GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1

이 코드는 NancySmith12라는 사용자에게 100달러를 이체하라는 요청을 보냅니다.

하지만 만약 대상 사용자가 동료가 보낸 것처럼 위장된 이메일을 받는다면, 클릭 동작에 CSRF 공격 스크립트가 다음과 같이 삽입될 수 있습니다.

<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">분기별 보고서 내용을 빠르게 확인해 주시겠어요?<a></a></a>

만약 대상 사용자가 사회 공학적 링크에 속아 금융 애플리케이션의 브라우저 세션이 열려 있는 상태에서 해당 링크를 클릭하면, 브라우저는 애플리케이션에 ShadyLady15의 계좌로 100,000달러를 이체하라는 요청을 보내게 됩니다.

스크립트는 사용자가 볼 수 없는 보이지 않는 이미지 안에 숨겨질 수도 있습니다. 하지만 브라우저가 이를 요청하도록 유도할 수 있으며, 그 예는 다음과 같습니다.

<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">

결과는 동일합니다. 아무도 공격을 감지하지 못하는 사이에 ShadyLady15 는 10만 달러를 가로챕니다.

CSRF가 위험한 이유는 무엇일까요?

CSRF 공격이 오늘날 성행하는 이유는 랜섬웨어 공격이 계속해서 기승을 부리는 이유와 같습니다. 공격자와 피해자의 자금 사이의 거리가 매우 가깝기 때문입니다. 랜섬웨어 공격은 시스템을 암호화하고 데이터를 복구하는 대가로 금전을 요구하지만, CSRF 공격은 단계가 훨씬 더 간소합니다. 공격이 성공하면 피해자는 자신도 모르는 사이에 공격자에게 돈을 보내게 됩니다.

피해자의 자금이나 기업의 재정을 직접 노리는 것 외에도, 성공적인 CSRF 공격은 유효한 사용자를 이용해 네트워크를 침해하는 데 사용될 수 있습니다. 공격자가 CSRF 취약점을 이용해 관리자의 비밀번호를 변경한다고 상상해 보십시오. 그들은 즉시 해당 비밀번호를 사용하여 데이터를 훔치거나, 네트워크 방어망에 구멍을 뚫거나, 백도어를 설치할 수 있습니다.

많은 노력과 어느 정도의 운이 필요하지만, 성공적인 CSRF 공격은 해커에게 최종 목표가 무엇이든 상관없이 복권에 당첨되는 것과 같습니다. 네트워크를 공격할 때 다른 대부분의 공격은 SIEM과 보안 담당자의 감시망을 피하기 위해 수개월에 걸친 은밀한 정찰이 필요합니다. 반면, 단 한 번의 CSRF 공격으로 사이버 킬 체인의 여러 단계를 건너뛰어 최종 목표에 매우 근접한 상태에서 시작할 수 있습니다.

CSRF 공격을 어떻게 막을 수 있을까요?

대부분의 취약점과 달리 CSRF 공격의 근본 원인은 코드 자체의 결함이라기보다, 사용자가 원하지 않거나 인지하지 못하는 요청을 브라우저가 수행하도록 강제하는 공격자의 기법에 있습니다. 하지만 이를 막을 방법은 분명히 존재합니다.

가장 좋은 방법 중 하나는 개발자가 새로운 세션이 생성될 때마다 사용자의 신원에 CSRF 토큰을 추가하는 것입니다. 이 토큰은 고유하고 무작위적인 문자열로 구성되어야 하며 사용자에게는 보이지 않아야 합니다. 다음으로, 서버가 새로운 요청을 제출받을 때마다 확인하는 폼에 CSRF 토큰 요청을 숨겨진 필드로 추가하십시오. 사용자의 브라우저를 통해 요청을 제출하는 공격자는 숨겨진 토큰 필드에 대해 알지 못할 뿐만 아니라 그 값을 알아낼 수도 없으므로, 공격자가 보낸 모든 요청은 실패하게 됩니다.

더 쉬운 방법으로는 프로그래밍 작업이 거의 필요 없는 캡차(Captcha) 인증을 비밀번호 변경 요청이나 송금 주문과 같은 민감한 작업에 추가하는 것입니다. 요청자가 로봇이 아닌지, 혹은 이 경우에는 CSRF 스크립트가 아닌지 확인하는 버튼을 클릭하게 하는 것만으로도 충분합니다. 공격자는 이 챌린지에 대한 응답을 스크립트로 작성할 수 없으며, 사용자는 송금 요청과 같은 작업을 수행하지 않았는데도 갑자기 캡차 인증이 나타나면 무언가 잘못되었음을 즉시 알 수 있습니다. 또는 보안을 위해 업무 효율을 다소 희생할 의향이 있다면 스마트폰과 같은 타사 토큰을 사용하는 일회용 비밀번호 생성 방식을 도입할 수도 있습니다.

마지막으로, 완벽하지는 않지만 Microsoft Edge나 Google Chrome과 같은 많은 브라우저에는 현재 동일 출처 정책(same-origin policy) 제한이 적용되어 로컬 사용자가 아닌 외부의 요청을 차단합니다. 사용자가 최신 버전의 브라우저를 사용하도록 유도하면 개발 팀의 부담을 늘리지 않고도 CSRF 보안 계층을 추가로 구축할 수 있습니다.

CSRF의 문을 닫아걸다

높은 수익 잠재력 때문에 CSRF 공격이 완전히 사라지지는 않겠지만, 이번 내용을 통해 CSRF가 왜 그토록 끈질긴지, 그리고 네트워크에서 이를 어떻게 영구적으로 차단할 수 있는지 이해하셨기를 바랍니다.

더 자세한 내용은 OWASP의 Cross-Site Request Forgery Prevention Cheat Sheet를 참고하십시오. 이 문서는 취약점이 진화함에 따라 지속적으로 업데이트되는 살아있는 문서입니다. 보안 지식을 더욱 강화하고 싶다면 Secure Code Warrior 블로그를 방문하여 이 위협을 비롯한 다양한 공격을 방어하는 방법을 배워보십시오.

새로 배운 방어 지식을 테스트해 볼 준비가 되셨나요? 지금 바로 무료 데모를 통해 Secure Code Warrior 플랫폼을 체험해 보세요.