영향
CSRF(Cross-Site Request Forgery)를 통해 공격자는 피해자의 브라우저를 속여 피해자가 현재 인증된 다른 웹사이트에서 원치 않는 작업을 수행하도록 할 수 있습니다. 브라우저는 요청에 쿠키와 같은 주변 자격 증명을 자동으로 포함하기 때문에 공격자는 사용자가 모르는 사이에 암호 변경, 데이터 삭제, 트랜잭션 시작 등 상태 변경 작업을 위조할 수 있습니다.
근본 원인
CSRF의 근본적인 원인은 요청 출처 [S1]에 관계없이 해당 도메인에 대한 요청이 있을 때마다 해당 도메인과 연결된 쿠키를 보내는 웹 브라우저의 기본 동작입니다. 요청이 애플리케이션의 자체 사용자 인터페이스에서 의도적으로 트리거되었는지에 대한 구체적인 검증이 없으면 서버는 합법적인 사용자 작업과 위조된 작업을 구별할 수 없습니다.
Django CSRF 보호 메커니즘
Django는 미들웨어 및 템플릿 통합 [S2]를 통해 이러한 위험을 완화하기 위한 내장 방어 시스템을 제공합니다.
미들웨어 활성화
django.middleware.csrf.CsrfViewMiddleware는 CSRF 보호를 담당하며 일반적으로 [S2]에 의해 기본적으로 활성화됩니다. CSRF 공격이 이미 처리되었다고 가정하는 뷰 미들웨어 [S2] 앞에 위치해야 합니다.
템플릿 구현
내부 POST 양식의 경우 개발자는 <form> 요소 [S2] 내에 {% csrf_token %} 태그를 포함해야 합니다. 이렇게 하면 고유한 비밀 토큰이 요청에 포함되어 서버가 사용자 세션에 대해 유효성을 검사합니다.
토큰 유출 위험
중요한 구현 세부 사항은 {% csrf_token %}가 외부 URL [S2]를 대상으로 하는 양식에 포함되어서는 안 된다는 것입니다. 그렇게 하면 비밀 CSRF 토큰이 제3자에게 유출되어 잠재적으로 사용자 세션 보안 [S2]가 손상될 수 있습니다.
브라우저 수준 방어: SameSite 쿠키
최신 브라우저에는 심층 방어 [S1] 계층을 제공하기 위해 Set-Cookie 헤더에 대한 SameSite 속성이 도입되었습니다.
- 엄격함: 쿠키는 자사 컨텍스트에서만 전송됩니다. 즉, URL 표시줄의 사이트가 쿠키의 도메인 [S1]와 일치합니다.
- Lax: 쿠키는 사이트 간 하위 요청(예: 이미지 또는 프레임)에서는 전송되지 않지만 사용자가 표준 링크 [S1]를 따라 원본 사이트로 이동할 때 전송됩니다.
FixVibe가 이를 테스트하는 방법
FixVibe에는 이제 게이트 활성 검사로 CSRF 보호가 포함됩니다. 도메인 확인 후 active.csrf-protection는 발견된 상태 변경 양식을 검사하고 CSRF 토큰 형태의 입력 및 SameSite 쿠키 신호를 확인한 다음 영향이 적은 위조 원본 제출을 시도하고 서버가 이를 수락할 때만 보고합니다. 또한 쿠키 검사는 CSRF 심층 방어를 감소시키는 약한 SameSite 속성을 표시합니다.