웹서버에서 CSRF 보호를 설정하는 방법은?

Q1: CSRF 보호란 무엇인가요?
A1: CSRF(Cross-Site Request Forgery)는 사용자가 의도하지 않은 요청을 공격자가 대신 보내게 만드는 공격입니다. CSRF 보호는 이런 공격을 막기 위한 보안 기법입니다.

Q2: 웹서버에서 CSRF 보호를 설정하는 기본 원리는 무엇인가요?
A2: 서버는 유효한 사용자 세션과 요청의 진위를 확인하기 위해 CSRF 토큰을 생성하여 클라이언트에 전달하고, 클라이언트가 요청 시 이 토큰을 반드시 포함하도록 요구합니다. 서버는 요청에 포함된 토큰을 검증해서 유효하면 요청을 처리합니다.

Q3: 대표적인 CSRF 보호 설정 방법은 무엇인가요?
A3:
1. CSRF 토큰 사용 : 서버가 난수로 생성한 토큰을 사용자 세션에 저장하고, 사용자 폼이나 AJAX 요청에 이 토큰을 숨은 필드나 헤더에 포함시킵니다.
2. SameSite 쿠키 설정 : 쿠키에 `SameSite` 속성을 `Strict` 또는 `Lax`로 설정하여 외부 출처에서 쿠키가 자동으로 전송되는 것을 제한합니다.
3. Referer 헤더 검증 : 요청의 Referer 헤더를 검사하여 요청이 신뢰할 수 있는 출처에서 왔는지 확인합니다.
4. Custom 헤더 검증 : AJAX 요청 등에 커스텀 헤더(`X-Requested-With` 등)를 설정해 서버에서 확인하도록 합니다.

Q4: CSRF 토큰을 웹서버에 어떻게 적용하나요?
A4:
- 서버에서 사용자 세션당 고유한 CSRF 토큰을 생성합니다.
- HTML 폼 내부에 `` 형태로 토큰을 삽입합니다.
- AJAX 요청 시 요청 헤더에 CSRF 토큰을 삽입합니다.
- 서버는 요청을 받을 때 토큰 값을 세션에 저장된 토큰과 비교해 검증합니다.

웹 프레임워크(예: Django, Spring, Express 등)는 CSRF 보호 기능을 기본 혹은 확장 모듈로 제공하므로, 해당 기능을 활성화하는 설정으로 간단히 적용할 수 있습니다.

Q5: 서버 설정에서 SameSite 쿠키를 어떻게 적용하나요? A5:
- 웹서버(예: Apache, Nginx)나 애플리케이션에서 세션 쿠키에 `SameSite=Lax` 또는 `SameSite=Strict` 속성을 추가합니다.
- 예시 (Set-Cookie 헤더): `Set-Cookie: sessionid=abcd1234; SameSite=Lax; Secure; HttpOnly`
- 이를 통해 외부 도메인에서 쿠키가 자동 포함되는 것을 제한해 CSRF 위험을 줄입니다.

Q6: 주요 웹서버별 CSRF 보호 설정 방법은?
A6:
- Apache : 모듈에서 직접 CSRF 보호 기능 제공하지 않음. 애플리케이션 레벨에서 CSRF 토큰을 구현하거나 `mod_security` 룰을 사용해 서버 레벨 필터링 가능.
- Nginx : 역시 애플리케이션 레벨의 CSRF 토큰 검증 필요, `SameSite` 쿠키 설정은 `proxy_cookie_path` 또는 애플리케이션에서 처리.
- Node.js (Express) : `csurf` 미들웨어를 설치 및 등록해 사용.
- Django : 기본적으로 CSRF 미들웨어 활성화 상태임, 추가 설정으로 토큰 검증 강화 가능.
- Spring Boot : `Spring Security`의 CSRF 보호 기본 활성화, 필요시 `.csrf().disable()`로 끌 수 있음.

Q7: CSRF 보호와 관련해 주의할 점은 무엇인가요?
A7:
- CSRF 토큰은 HTTPS 환경에서 반드시 사용해야 중간 공격 방지 가능.
- JSON API는 CSRF 토큰 대신 CORS 정책과 `SameSite` 쿠키를 조합해서 대응하는 경우가 많음.
- 토큰은 예측 불가능한 값이어야 하며, 세션당/요청당 적절히 갱신해야 보안성이 높아짐.
- GET 요청에는 사이드 이펙트가 없도록 설계하여 CSRF 공격에 취약하지 않게 해야 함.

---

요약하면, 웹서버에서 CSRF 보호를 위해서는 애플리케이션 레벨에서 CSRF 토큰을 생성·검증하는 로직을 구현하고, 웹서버환경에서는 쿠키에 SameSite 속성을 설정해 쿠키의 자동 전송을 제한하며, 안전한 HTTPS 프로토콜을 사용하는 것이 기본입니다. 대부분의 현대 웹 프레임워크는 CSRF 보호 기능을 내장하고 있으니 이를 활성화하는 것이 효율적입니다.

웹서버에서 CSRF(Cross-Site Request Forgery) 보호를 설정하는 방법은 여러 가지가 있으며, 주로 웹 어플리케이션 레벨에서 구현됩니다.

CSRF 공격은 사용자가 인증된 상태에서 공격자가 의도하지 않은 요청을 서버에 보내도록 유도하는 공격이기 때문에, 이를 방지하기 위해서는 서버가 요청의 정당성을 검증하는 메커니즘이 필요합니다.

다음은 CSRF 보호를 위한 주요 방법과 설정 방법에 대한 설명입니다.

1. CSRF 토큰 사용 ----------------- 가장 일반적이고 널리 사용되는 방법입니다.

서버는 사용자가 폼을 요청할 때마다 고유한 CSRF 토큰을 생성하여 폼 안에 숨겨진 필드(hidden field)로 삽입하거나, AJAX 요청 시 헤더에 포함하도록 합니다.

클라이언트가 폼을 제출할 때 이 토큰도 함께 전송되며, 서버는 요청에 포함된 토큰과 세션에 저장된 토큰을 비교해 일치하는지 확인합니다.

일치하지 않으면 요청을 거부합니다.

- 구현 방법: - 서버에서 세션 당 고유한 CSRF 토큰 생성 - HTML 폼에 `` 형태로 삽입 - AJAX 요청 시 헤더에 CSRF 토큰을 포함 - 서버에서 POST/PUT/DELETE 등의 변경 요청 처리 시 CSRF 토큰 검증 - 주요 웹 프레임워크들은 CSRF 보호 기능을 기본 제공하거나 플러그인 형태로 지원 - 예) Django에서는 `CsrfViewMiddleware`를 활성화하고 템플릿 태그 `{% csrf_token %}`를 사용

2. Referer 헤더 검사 ------------------- HTTP Referer 헤더를 검사해 요청이 동일 출처(Same-Origin)에서 온 것인지 확인하는 방법입니다.

만약 Referer가 악의적인 출처라면 요청을 차단합니다.

- 장점: 별도의 토큰 관리가 필요 없음 - 단점: 일부 프라이버시 설정이나 프록시 환경에서 Referer 헤더가 누락될 수 있어 신뢰도 낮음 - 설정 방법: - 서버에서 요청이 오면 Referer 헤더가 존재하는지 확인 - Referer가 본인의 도메인과 일치하는지 검사 - 일치하지 않으면 요청 거부

3. SameSite 쿠키 속성 활용 ------------------------- 최근 브라우저는 쿠키에 `SameSite` 속성을 지원하여, 서드파티 사이트에서 쿠키가 자동 전송되는 것을 제한할 수 있습니다.

`SameSite=Lax` 또는 `SameSite=Strict` 설정을 통해 CSRF 공격을 효과적으로 줄일 수 있습니다.

- `SameSite=Strict`: 쿠키가 동일 사이트에서만 전송되어 가장 강력한 보호 제공 - `SameSite=Lax`: 기본 설정으로 GET 방식으로 이동할 때는 쿠키가 전송되지만, POST 등의 요청에는 전송 제한 - 설정 방법: - 웹서버 혹은 애플리케이션에서 세션 쿠키 발급 시 `SameSite` 속성 추가 - 예: `Set-Cookie: sessionid=xyz; SameSite=Strict; Secure; HttpOnly` - 단점: 오래된 브라우저에서 지원이 부족할 수 있음

4. Custom Header와 CORS 정책 이용 --------------------------------- XHR 또는 Fetch API로 요청을 보낼 때 커스텀 헤더를 포함시켜 요청이 정상적인 출처로부터 오는지 확인할 수 있습니다.

CSRF 공격은 같은 출처 정책(SOP) 때문에 악의적 사이트가 커스텀 헤더를 포함한 요청을 만들 수 없으므로 간접적인 CSRF 방어 수단이 됩니다.

- 서버는 특정 헤더 여부를 확인해 요청 허용 - CORS 설정으로 허용된 출처 이외의 요청 차단

5. POST 요청 제한과 idempotent 메서드 활용 ----------------------------------------- CSRF 공격 대부분은 상태를 변경하는 POST, PUT, DELETE 요청을 노리므로, 민감한 상태 변경은 반드시 POST 요청으로 제한하고 GET 요청으로는 상태 변경을 하지 않도록 설계합니다.

또한 CSRF 토큰 검사와 병행하면 효과적입니다.



6. 보안 헤더 설정 ---------------- - `X-Frame-Options` 헤더 설정으로 클릭재킹 공격 방지 - HTTPS 강제 적용, Secure 쿠키 설정 등으로 보안성 강화 CSRF 보호를 위해서는 기본적으로 CSRF 토큰 방식을 도입하는 것이 가장 효과적이며, 이것을 SameSite 쿠키, Referer 검사 등과 병행하여 이중으로 보호하는 것이 좋습니다.

여러 웹 프레임워크에서는 이미 CSRF 방어 기능을 내장하고 있으니, 사용 중인 프레임워크 문서를 참고해 활성화시키고, 필요한 경우 웹서버 설정(쿠키, 헤더 등)을 병행하는 형태로 적용하는 것이 일반적입니다.