🔐 CSRF 공격이란?
CSRF(Cross-Site Request Forgery, 사이트 간 요청 위조)는 사용자가 원하지 않는 요청을 자신의 계정으로 보내게 만드는 공격입니다.
조금 어렵게 들리지만, 한 문장으로 정리하면 이렇습니다:
“내 로그인 상태를 악용해서, 공격자가 시킨 행동을 내가 한 것처럼 서버에 보내는 공격”
예를 들어, 내가 은행 사이트에 로그인한 상태라면, 공격자는 나를 속여 내 계정으로 돈을 보내거나, 비밀번호를 바꾸는 요청을 자동으로 실행시킬 수 있습니다.
💥 실제로 어떻게 공격이 일어날까? (간단 예시)
📌 상황 설정
- 당신은 A 은행 사이트에 로그인한 상태
- 새 탭에서 뉴스 사이트를 열어 기사 하나를 클릭
- 하지만 그 뉴스 사이트 안에는 공격자가 몰래 심어놓은 HTML 코드가 들어 있음
📌 공격자가 심어 놓은 악성 코드 (예시)
겉보기엔 평범한 <img> 태그인데, 이미지 파일이 아니라 은행 송금 URL을 호출해버립니다.
사용자는 이미 은행에 로그인한 상태라 쿠키도 함께 전송되고,
서버는 이것을 “정상적인 사용자의 요청”이라고 착각합니다.
💳 현실적인 예시: 공격 흐름
1) 공격자가 준비한 악성 페이지
공격자는 아래 같은 숨겨진 폼을 준비해 둘 수 있습니다:
2) 사용자가 이메일 링크를 클릭
“인기 드라마 촬영지 공개!” 라는 제목의 어그로 메일을 받고 클릭.
3) 자동으로 송금 요청 발생
사용자는 아무것도 하지 않았지만,
해당 페이지에서 폼이 자동 제출되며 송금 요청이 실행됨.
📌 CSRF가 성공하려면 필요한 조건
✔ 사용자가 로그인한 상태이어야 함
✔ 서버가 쿠키를 자동으로 전송하는 구조여야 함
✔ 공격자가 요청 URL/파라미터를 알고 있어야 함
✔ 사용자가 공격자의 사이트를 방문해야 함
즉, 사용자가 ‘무언가를 잘못 클릭’해야 성립하는 사회공학적 공격이기도 합니다.
🛡 CSRF는 어떻게 막을까?
✅ 1) CSRF 토큰 사용 (가장 확실한 방법)
서버는 요청마다 난수 토큰을 포함시키고 이를 확인합니다.
공격자는 이 값을 예측할 수 없기 때문에 요청을 위조할 수 없습니다.
✅ 2) SameSite 쿠키
쿠키를 타 도메인에서 자동으로 전송하지 않도록 제한하는 속성입니다.
최근 서비스들은 대부분 SameSite=Lax 또는 Strict를 적용합니다.
✅ 3) Origin / Referer 검사
요청이 어디서 왔는지 확인해
자기 도메인 도 아닌 곳에서 온 요청은 거절합니다.
✅ 4) 중요한 기능에는 추가 인증
- 비밀번호 재입력
- OTP
- 2FA
- 보안문자 입력 등
CSRF로는 자동 요청만 가능하므로, 이런 추가 절차가 있으면 방어 가능.
✅ 5) GET 요청으로 데이터 변경 금지
GET은 단순 조회용이므로,
삭제/수정/송금 같은 기능을 GET으로 구현하면 절대 안 됩니다.
📚 마무리
CSRF 공격은 보기에 대단히 어려워 보이지만, 본질은 단순합니다.
“내 로그인 쿠키를 이용해, 공격자가 대신 요청을 보내는 것”
사용자 입장에서는 “링크 한 번 잘못 눌렀을 뿐인데” 자산이 빠져나갈 수도 있습니다.
웹 개발자라면 CSRF 토큰, Origin 검사, SameSite 쿠키 등 필수 보호 장치를 반드시 적용해야 합니다.
'Web Security' 카테고리의 다른 글
| XSS 방지책 (Express.js) (0) | 2025.12.02 |
|---|---|
| XSS 방지책 (Flask) (0) | 2025.12.02 |
| XSS 방지책 (ReactJS) (0) | 2025.12.02 |
| 크로스 사이트 스크립팅 (Cross-Site Scripting, XSS) (0) | 2025.11.30 |
| SQL Injection (SQLi) (0) | 2025.10.30 |