CSRF 취약점 A to Z

본 블로그는 학습용입니다. 명시적 동의 없는 시스템 접근·정보수집은 불법이며 형사·민사 책임이 따릅니다.
실습은 격리된 테스트 환경에서만 허용됩니다. (형법·정보통신망법·정보통신기반보호법 등)

1. 주제: 내 의지와 상관없이 요청이 위조된다?

주제: OWASP Top 10에 항상 언급되는 주요 웹 취약점: CSRF (Cross-Site Request Forgery)

 

핵심 요약: CSRF는 공격자가 사용자의 권한을 도용하여 사용자가 의도하지 않은 비밀번호 변경, 글 삭제, 송금  등의 요청을 서버에 전송하도록 만드는 공격 기법입니다. 서버가 사용자의 브라우저를 신뢰한다는 점을 악용하기 때문에, 로그인된 사용자라면 누구나 공격 대상이 될 수 있는 매우 심각한 보안 취약점입니다. 

---

2. CSRF 정의 및 작동 원리

2.1. 상세 정의

CSRF는 Cross-Site Request Forgery의 약자로 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위를 특정 웹사이트에 요청하게 하는 공격을 의미합니다. 이 공격의 핵심은 인증된 사용자의 세션 쿠키를 이용한다는 점입니다.

사용자가 특정 사이트(예: 은행, 쇼핑몰)에 로그인하면, 브라우저는 해당 사이트의 세션 쿠키를 저장합니다. 이후 사용자가 같은 사이트에 요청을 보낼 때마다 브라우저는 이 쿠키를 자동으로 첨부하여 서버에 보냅니다. 서버는 이 쿠키를 보고 '아, 인증된 사용자의 요청이구나'라고 판단하고 요청을 신뢰하게 됩니다. CSRF는 바로 이 신뢰 관계를 악용하는 것입니다.

 

2.2. 공격 흐름 

CSRF 공격은 일반적으로 다음과 같은 순서로 진행됩니다.

1. 사용자 로그인: 사용자는 보안이 취약한 웹사이트(예: bank.com)에 정상적으로 로그인합니다. 브라우저에는 bank.com의 인증 정보가 담긴 쿠키가 저장됩니다.
   악성 링크 전달: 공격자는 비밀번호 변경과 같은 특정 기능을 실행시키는 악성 URL을 만들고, 이를 이메일이나 게시판의 링크, 이미지 등을 통해 사용자에게 전달합니다.
2. 사용자 유인: 사용자는 '무료 이벤트', '긴급 공지' 등과 같은 문구에 속아 해당 링크를 클릭하거나 악성 이미지가 포함된 페이지를 열람합니다.
3. 요청 위조 및 전송: 링크를 클릭하면, 사용자의 브라우저는 자신도 모르게 악성 URL에 해당하는 요청을 bank.com 서버로 전송합니다. 이때 브라우저는 자동으로 1번 단계에서 저장했던 인증 쿠키를 함께 보냅니다.
4. 서버의 오인 및 실행: bank.com 서버는 요청과 함께 전달된 쿠키를 보고 정상적인 사용자의 요청이라고 착각하여, 공격자가 의도한 작업(비밀번호 변경 등)을 그대로 수행합니다.
   

---

3. 시나리오 및 실습 환경 

3.1. 목표 

로그인된 사용자가 공격자가 만든 악성 링크를 클릭했을 때, 자신도 모르게 비밀번호가 변경되도록 하는 CSRF 공격을 재현합니다.

 

3.2. 실습 환경

Target: DVWA 

Tool(s): Burp Suite, Web Browser

Account: admin / password

---

4. 분석 및 공격 절차

4.1. [1단계: 기능 분석 및 정보 수집]

먼저 공격 대상인 '비밀번호 변경' 기능이 어떻게 동작하는지 분석합니다. DVWA에 로그인한 후, 'CSRF' 메뉴로 이동하여 임의의 비밀번호로 변경을 시도합니다. 이때 Burp Suite를 이용해 어떤 HTTP 요청이 서버로 전송되는지 패킷을 가로챕니다.

비밀번호 변경 요청이 GET 메소드를 사용하며, URL의 파라미터를 통해 새 비밀번호(password_new, password_conf)가 서버로 전달되는 것을 확인할 수 있습니다.

 

4.2. [2단계: 취약점 발견 및 공격 코드 작성]

위 요청 구조에서 중요한 보안 취약점을 발견할 수 있습니다. 요청에 사용자의 세션을 검증할 수 있는 임의의 토큰 값(난수)이 존재하지 않고, 오직 예측 가능한 파라미터로만 구성되어 있다는 점입니다. 이는 공격자가 원하는 비밀번호로 변경하는 URL을 손쉽게 만들어낼 수 있다는 의미입니다.

다음과 같이 비밀번호를 'security'로 변경하는 악성 URL을 작성합니다

http://localhost/vulnerabilities/csrf/?password_new=security&password_conf=security&Change=Change

 

 

4.3. [3단계: 공격 수행 및 목표 달성]

작성한 악성 URL을 사용자에게 전달해야 합니다. 이메일에 링크를 삽입하거나, 웹사이트 게시판에 다음과 같이 이미지 태그를 이용해 숨길 수 있습니다. 저는 이메일 전송으로 공격자 겸 피해자로 진행하였습니다.

DVWA에 로그인된 상태의 사용자가 위 링크가 포함된 페이지에 접근하면 브라우저는 즉시 해당 URL로 요청을 보내고 비밀번호가 'security'로 변경되는 것을 확인하였습니다

---

5. 최종 결과

공격 성공: DVWA에 로그인된 사용자가 악성 링크가 포함된 페이지에 접근하는 순간, 사용자의 의도와 무관하게 비밀번호가 'security'로 성공적으로 변경되었습니다. 서버가 요청의 출처를 검증하지 않고 단지 세션 쿠키의 유효성만으로 요청을 신뢰했기 때문에 발생한 결과입니다

---

6. 대응 방안 및 결론

6.1. 보안 대책 

CSRF 공격을 방어하기 위한 해결책은 서버가 받은 요청이 정말로 사용자의 의도에 의해 발생한 것인지 검증하는 것입니다

• Anti-CSRF 토큰 사용 서버는 사용자에게 중요한 정보를 변경하는 폼(Form) 페이지를 보낼 때, 예측 불가능하고 세션마다 다른 임의의 토큰(Token)을 함께 생성하여 보냅니다. 사용자가 해당 폼을 통해 요청을 보낼 때, 이 토큰 값을 요청에 포함시켜야만 합니다. 서버는 요청에 포함된 토큰 값이 서버가 발급한 값과 일치하는지 검증하여, 일치하지 않으면 비정상적인 요청으로 판단하고 차단합니다. 공격자는 이 토큰 값을 알 수 없으므로 공격은 실패하게 됩니다.
• Referer 헤더 검증 HTTP 요청의 Referer 헤더 값을 확인하여, 요청이 어디서부터 시작되었는지 확인하는 방법입니다. 서버는 이 값을 보고 정상적인 내부 도메인에서 온 요청만 허용하고, 외부 사이트에서 온 요청은 차단할 수 있습니다. 하지만 Referer 헤더는 조작이 가능하고, 개인정보 보호를 위해 브라우저에서 전송하지 않는 경우도 있어 우회될 가능성이 존재합니다.
• SameSite Cookie Attribute 설정 최신 브라우저에서 지원하는 보안 기능으로, 쿠키의 SameSite 속성을 Strict 또는 Lax로 설정하여 외부 도메인에서 시작된 요청에는 쿠키 전송을 제한하는 방식입니다. CSRF 공격을 효과적으로 완화할 수 있는 강력한 방어책 중 하나입니다.

6.2. 결론

이번 실습을 통해 우리는 서버가 사용자의 브라우저를 신뢰한다는 점을 악용하는 CSRF 공격의 위험성을 확인했습니다. 요청의 출처를 검증하는 절차(Anti-CSRF 토큰 등)의 부재가 취약점의 핵심 원인이었습니다. 사용자의 인증 정보가 담긴 쿠키가 자동으로 전송된다는 편리함이 어떻게 보안 위협으로 이어질 수 있는지 명확히 알 수 있었습니다.

 

웹 애플리케이션 개발자는 사용자의 상태를 변경하는 모든 요청(글쓰기, 수정, 삭제, 송금 등)에 대해, 이것이 정말로 사용자의 의도에 의한 정상적인 요청인지 서버 측에서 반드시 검증하는 로직을 구현해야 합니다. 특히 Anti-CSRF 토큰을 적용하는 것은 안전한 웹 서비스를 구축하기 위한 필수적인 보안 대책이라고 할 수 있습니다.

참고 자료 

OWASP: Cross-Site Request Forgery (CSRF)

Mozilla Developer Network: SameSite cookies