[Normaltic 웹해킹 입문] 12주차 CSRF-내용정리

🔐 CSRF(Cross-Site Request Forgery) 개념 완벽 정리

오늘은 노말틱 선생님이 '정확히 아는 사람이 의외로 적다'며 강조하셨던 CSRF에 대해 정리해보고자 한다. XSS와 비슷해 보이지만 목적과 방식이 완전히 다른 이 공격의 정체를 파헤쳐보자.

---

1. CSRF란 무엇인가?

CSRF(사이트 간 요청 위조)는 한마디로 "피해자가 자신의 의지와 상관없이 공격자가 원하는 요청을 서버에 보내게 만드는 것"이다.

• 핵심 목적: 피해자의 권한(세션/쿠키)을 이용해 비밀번호 변경, 게시글 작성, 송금 등의 '동작'을 수행하게 함.
• XSS와의 차이점:

  구분	XSS (Cross-Site Scripting)	CSRF (Cross-Site Request Forgery)
  실행 위치	피해자의 브라우저 (스크립트 실행)	웹 서버 (위조된 요청 처리)
  주요 목표	쿠키 탈취, 스크립트 실행	특정 동작 수행 (비번 변경 등)

---

2. CSRF의 근본 원인과 공격 방식

공격자가 요청 파라미터를 완벽하게 예측하고 위조할 수 있을 때 발생한다. 예를 들어 비밀번호 변경 시 '현재 비밀번호'를 묻지 않는다면, 공격자는 new_pw=1234라는 파라미터만 담아 요청을 위조하면 끝이다.

💡 GET vs POST 방식의 위조

• GET 방식: <a href="..."> 링크나 <img src="..."> 태그를 이용한다. 이미지를 불러오기만 해도 요청이 전송되므로 매우 위험하다.
• POST 방식: 폼(Form) 태그를 전송해야 하므로 반드시 XSS 취약점이 동반되어야 한다. 게시글 등에 폼 태그를 심어두고 자바스크립트로 자동 제출(submit)시키는 방식을 사용한다.

---

3. 심화: POST 데이터 전달과 스텔스(Stealth) 공격

공격 시 "수정이 완료되었습니다" 같은 알림창이 뜨면 피해자가 눈치챌 수 있다. 이를 방지하기 위해 iframe과 sandbox를 활용한다.

✅ 정석적인 POST 위조 페이로드

<iframe width="0" height="0" border="0" name="stealthFrame" id="stealthFrame" style="display:none;" sandbox="allow-forms"></iframe>

<form method="POST" action="/update_pw" id="myForm" target="stealthFrame">
    <input type="hidden" name="pw" value="1234" />
</form>

<script>
    document.getElementById('myForm').submit();
</script>

❓ 궁금증 해결: sandbox="allow-forms"를 쓰면 왜 alert이 안 뜨나요?
원래 폼을 제출하면 서버의 응답 페이지로 이동하면서 "성공!" 알림이 뜹니다. 하지만 sandbox 속성은 해당 iframe 내부에서 일어나는 동작을 매우 엄격하게 제한합니다. allow-forms는 폼 제출만 허용할 뿐, 자바스크립트 실행(allow-scripts)이나 모달창 띄우기(allow-modals)를 허용하지 않으면 서버가 보내는 알림창 코드가 실행되지 못하고 차단됩니다. 즉, 공격은 성공하되 알림은 무시되는 스텔스 상태가 되는 것이죠!

✅ Fetch API를 이용한 방식

최신 브라우저에서는 스크립트 하나로 더 깔끔하게 처리가 가능하다.

fetch("/update_pw", {
    method: "POST",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "pw=1234",
    credentials: "include" // 이 옵션이 있어야 피해자의 세션 쿠키가 같이 전송됨!
});

---

4. 방어 수단: CSRF Token의 한계

가장 대중적인 방어법은 CSRF Token이다. 서버가 페이지를 줄 때 예측 불가능한 토큰을 숨겨두고, 요청 시 제출된 토큰이 세션에 저장된 값과 일치하는지 검증하는 방식이다.

⚠️ 하지만 XSS가 뚫리면 무용지물?

XSS 취약점이 있다면 공격자는 스크립트를 통해 iframe으로 토큰이 있는 페이지를 로드하고, 그 안의 토큰값을 읽어와서 공격 폼에 채워 넣을 수 있다. 그래서 노말틱 선생님도 "CSRF 토큰이 만능은 아니며, XSS부터 막는 것이 우선"이라고 강조하신 것이다.

---

💡 결론 및 요약

CSRF는 결국 "요청의 진위 여부"를 가리는 싸움이다. 완벽한 방어를 위해서는 CSRF 토큰뿐만 아니라 중요한 동작(비밀번호 변경 등)에는 반드시 현재 비밀번호를 재입력하게 하거나, CAPTCHA를 도입하는 등의 추가 검증 절차가 필수적이다.

이제 개념은 확실히 잡았으니, 다음은 실전 문제를 통해 직접 요청을 위조해보자! 😎