CSRF 취약점
CSRF(Cross-Site Request Forgery, 사이트 간 요청 위조)
사용자가 의도하지 않은 요청이 사용자의 권한으로 서버에 전달되도록 속이는 공격.
정상적으로 사이트에 로그인한 상태의 피해자가 공격자가 생성한 악의적 웹페이지 또는 링크에 접속하면, 브라우저는 쿠키를 자동으로 첨부하기 때문에 공격자의 요청을 정상 사용자 요청으로 착각한다.
❗전제 조건은 피해자가 로그인 된 상태에서 악의적 링크/웹페이지에 접속하는 것
CSRF가 왜 발생할까?
→ 브라우저가 쿠키를 자동으로 전송하기 때문
시나리오
사용자가 A사이트에 로그인하면 세션 쿠키가 저장됨. 그 후 공격자가 만든 페이지를 클릭하면, 브라우저는 자동으로 A.com 쿠키를 첨부한다. 따라서 서버는 “정상 사용자 요청”이라고 믿고 계정 변경, 게시글 삭제, 송금 요청 등이 실행된다.
→ 서버가 “요청이 진짜 사용자가 보낸 것인지” 확인하지 않음
즉, CSRF Token이 없거나 검증하지 않을 때 공격 성공.
CSRF 공격 예제
내 웹사이트는 CSRF 취약점이 있을까?
간단 테스트:
다음과 같은 내용의 html 파일을 생성한다.
<form action="https://site.com/products/1/delete" method="POST"></form>
<script>document.forms[0].submit()</script>site명과 게시글의 number, 요청 내용은 필요에 따라 조작한다.
사이트에 로그인한 상태로 html 파일을 클릭하였을 때 게시글이 삭제되면 CSRF에 대해 취약한 것으로 판단할 수 있다.
CSRF는 다음과 같이 다양한 공격에 적용될 수 있다.
| 기능 | 위험도 |
|---|---|
| 비밀번호 변경 | 매우 높음 |
| 계정 삭제 | 매우 높음 |
| 송금/결제 | 치명적 |
| 게시물 수정/삭제 | 높음 |
| 상품 등록/삭제 | 높음 |
| 좋아요/댓글 조작 | 중간 |
CSRF 취약점 진단
-
POST 요청에 CSRF Token이 있는가?
→없으면 취약 가능성이 높다
있어도 서버에서 검증하지 않으면 취약 -
Referer / Origin 체크를 하는가?
→없으면 위험 -
쿠키 SameSite 설정이 적절한가?
SameSite=Lax → 대부분의 CSRF 자동으로 막힘
SameSite=None; Secure → 외부에서 쿠키 전송 가능하므로 취약 -
민감 요청이 GET 방식인가?(예:GET /delete?id=1)
→GET으로 삭제/변경이 가능한 경우 CSRF 취약
