CSRF
🔗 CSRF (Cross-Site Request Forgery)
CSRF는 '사이트 간 요청 위조'라는 뜻으로, 공격자가 사용자의 인증된 세션(로그인 상태)을 악용하여, 사용자가 의도하지 않은 요청(예: 글쓰기, 비밀번호 변경)을 서버에 강제로 보내도록 만드는 공격 기법입니다. 사용자는 자신도 모르는 사이에 공격자가 원하는 행동을 하게 됩니다.
⚙️ CSRF 공격 시나리오
1. 사용자는 정상적인 웹 사이트(예: 은행 사이트)에 로그인하여, 인증된 세션 쿠키를 브라우저에 가지고 있습니다. 2. 공격자는 악의적인 스크립트가 포함된 이메일이나 게시글(예: `<img>` 태그나 form을 이용)을 사용자에게 보냅니다. 3. 사용자가 이 이메일이나 게시글을 열면, 브라우저는 자신도 모르게 은행 사이트에 특정 요청(예: `https://bank.com/transfer?to=attacker&amount=1000`)을 보냅니다. 4. 이때 브라우저는 자동으로 은행 사이트의 세션 쿠키를 함께 첨부하여 보냅니다. 5. 은행 서버는 이 요청이 정상적인 사용자의 세션 쿠키와 함께 왔으므로, 진짜 사용자의 요청이라고 믿고 공격자가 의도한 송금 작업을 처리해버립니다.
🛡️ 방어 방법
CSRF 공격을 막는 핵심 원칙은, 서버가 받은 요청이 정말로 사용자의 의도에 의해 보내진 것인지를 추가적으로 확인하는 것입니다.
- CSRF 토큰 사용 (가장 일반적인 방법) :
> 1. 서버는 사용자의 세션에 임의의 난수 값인 'CSRF 토큰'을 저장하고, 페이지를 응답할 때 이 토큰을 함께 보내줍니다. (주로 `hidden` input 필드에 저장) > 2. 사용자가 요청을 보낼 때, 이 CSRF 토큰을 요청 파라미터나 헤더에 포함하여 함께 보냅니다. > 3. 서버는 요청을 받으면, 요청에 포함된 토큰과 세션에 저장된 토큰이 일치하는지 비교합니다. 일치할 경우에만 요청을 처리합니다. > * 공격자는 사용자의 세션에 저장된 CSRF 토큰 값을 알 수 없으므로, 올바른 요청을 위조할 수 없습니다.
- SameSite 쿠키 속성 사용 : 쿠키를 전송할 때의 정책을 설정하여, 다른 출처(Cross-site)에서 시작된 요청에는 쿠키 전송을 제한할 수 있습니다. `SameSite=Strict` 또는 `SameSite=Lax`로 설정하면 대부분의 CSRF 공격을 막을 수 있습니다.
- Referer 헤더 검증 : 요청 헤더의 `Referer` 값을 확인하여, 허용된 도메인에서 온 요청인지를 검증하는 방법도 있으나, 이 값은 위조될 수 있어 보조적인 수단으로만 사용됩니다.
💡 정보처리기사 핵심 Point
- CSRF는 사용자의 권한을 도용하여 원치 않는 행동을 수행하게 만드는 무서운 공격입니다.
- 정보처리기사 시험에서는 CSRF의 공격 원리, 방어 방법(특히 CSRF 토큰)을 묻는 문제가 자주 출제됩니다.
- 사용자의 상태를 변경하는 모든 요청(`POST`, `PUT`, `DELETE` 등)에 대해서는 CSRF 방어 대책이 반드시 필요합니다.
