CSRF(사이트 간 요청 위조) 공격은 공격자가 사용자의 인증된 세션을 악용하여 의도하지 않은 요청을 서버에 보내는 방식
즉, 사용자가 특정 사이트에 로그인한 상태에서 공격자가 조작된 요청을 실행하게 만들어 권한이 있는 사용자 대신 악성 요청을 서버에 전달하는 공격이야.
🔹 CSRF 공격 원리
1️⃣ 사용자가 웹사이트(A)에 로그인하고 세션을 유지 중
예를 들어, bank.com에 로그인한 상태에서 계좌 이체를 할 수 있는 세션 쿠키가 저장됨.
2️⃣ 공격자가 악성 웹사이트(B)에 사용자를 방문하게 함
사용자가 malicious.com(공격자 사이트)을 방문함.
이 웹사이트에는 bank.com으로 요청을 보내는 악성 스크립트 또는 숨겨진 폼이 포함됨.
3️⃣ 사용자가 공격자의 사이트에서 조작된 요청을 실행
사용자가 malicious.com을 방문하는 순간, 요청이 자동으로 bank.com으로 전송됨.
4️⃣ 서버가 요청을 정상적인 사용자 요청으로 착각하고 실행
사용자가 bank.com에 로그인한 상태라면, 세션 쿠키가 자동으로 전송됨.
bank.com은 이 요청을 합법적인 사용자 요청으로 인식하고 공격자의 계좌로 돈을 이체할 수 있음.
🔹 CSRF 공격 예제
예제 1: 로그인 유지 중 계좌 이체 요청
<img src="https://bank.com/transfer?to=attacker&amount=1000">예제 2: 관리자 계정 비밀번호 변경
<form action="https://admin.site.com/change-password" method="POST">
<input type="hidden" name="new_password" value="hacked123">
<input type="submit">
</form>
<script>document.forms[0].submit();</script>관리자가 로그인된 상태에서 이 코드를 포함한 페이지를 방문하면, 비밀번호가 공격자가 설정한 값으로 변경될 수 있음.
🔹 CSRF 방어 방법
1️⃣ CSRF 토큰 사용 (가장 효과적인 방법)
요청을 보낼 때 CSRF 토큰을 포함하여 서버에서 유효성을 검증.
서버는 클라이언트가 보낸 토큰과 서버에 저장된 토큰이 일치하는지 확인함.
2️⃣ SameSite 쿠키 설정
SameSite=Strict: 다른 사이트에서의 요청에 쿠키가 포함되지 않음.
SameSite=Lax: 일반적인 링크 클릭은 허용하지만, 자동 요청은 차단.
3️⃣ Referer 또는 Origin 헤더 검증
요청을 받을 때, Referer 또는 Origin을 확인하여 신뢰할 수 있는 도메인에서 온 요청인지 체크.
4️⃣ CORS 정책 강화
Access-Control-Allow-Origin을 신뢰할 수 있는 도메인으로 제한하여 악성 사이트에서 요청을 보낼 수 없도록 설정.
✅ 1. 신뢰할 수 있는 도메인만 허용
.allowedOriginPatterns("https://trusteddomain.com")모든 도메인을 허용하지 않고 특정 도메인만 허용.
✅ 2. 허용할 HTTP 메서드 제한
.allowedMethods("GET", "POST")불필요한 HTTP 메서드를 차단하여 보안 강화.
✅ 3. 인증 정보 포함 여부 결정
.allowCredentials(true)true이면 인증 정보를 포함한 요청 가능 (ex. 세션 쿠키, Authorization 헤더 사용).
✅ 4. 특정 헤더만 허용
.allowedHeaders("Content-Type", "Authorization")불필요한 헤더를 차단하여 보안 강화.
5️⃣ POST 요청만 허용
GET 요청은 브라우저에서 자동 실행될 가능성이 있으므로, 중요한 변경 작업(예: 송금, 설정 변경)은 반드시 POST 요청으로 제한.
