CSRF와 요청 정당성 검증 | 정보보안기사 필기

1. CSRF가 성립하는 조건

일반적인 CSRF는 다음 조건이 연결될 때 발생한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

피해자: 신뢰 사이트에 로그인
            ↓
공격자 사이트: 상태 변경 요청을 유도
            ↓
Browser: 대상 사이트의 Session Cookie를 자동 포함
            ↓
Server: Cookie만 확인하고 요청을 처리

공격자는 세션 쿠키 값을 직접 훔치지 않아도 된다. 브라우저가 이미 보유한 인증 상태를 요청에 실어 보내도록 유도하는 것이 핵심이다.

GET은 조회 중심으로 사용하고 상태 변경에는 사용하지 않는 것이 기본이다. 상태 변경을 GET으로 구현하면 Link Preview, Crawler, Prefetch 등 의도하지 않은 접근으로도 상태가 바뀔 수 있다.

그러나 Cross-Site Form도 POST 요청을 전송할 수 있다. 따라서 다음 문장은 틀리다.

POST를 사용하면 CSRF가 해결된다.

Method를 올바르게 설계한 뒤에도 CSRF 토큰, SameSite, Origin 검증과 같은 별도의 통제가 필요하다.

Same-Origin Policy는 주로 다른 Origin의 응답 내용을 스크립트가 읽는 것을 제한한다. Link 이동, Form 제출, 일부 Resource 요청처럼 Cross-Site 전송 자체는 허용될 수 있다.

CORS는 어떤 Origin에 응답을 공유할지 통제한다. Custom Header나 JSON 요청에 필요한 Preflight는 방어에 도움이 될 수 있지만, 단순 Form 요청을 자동으로 막는 장치는 아니다.

따라서 “응답을 읽지 못한다”와 “요청을 보내지 못한다”를 구분해야 한다.

서버가 예측하기 어려운 토큰을 생성해 세션과 연결하고, 상태 변경 요청에서 제출된 토큰이 현재 세션의 토큰과 일치하는지 확인한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

Server가 Session에 Token 저장
        ↓
정상 화면에 Token 포함
        ↓
Browser가 상태 변경 요청에 Token 제출
        ↓
Server가 Session과 Token을 함께 검증

토큰은 다음 조건을 만족해야 한다.

Stateless 구조에서는 쿠키와 요청 매개변수 또는 Header에 토큰을 각각 보내고 일치 여부를 확인할 수 있다. 단순히 두 값이 같다는 사실만 검사하기보다, 서버 비밀키로 서명하고 세션 식별정보와 연결한 값을 사용하는 편이 안전하다.

필기에서는 Synchronizer 토큰은 서버 측 세션 연결, Double-Submit은 쿠키와 요청값의 이중 제출이라는 차이를 이해하면 된다.

상태 변경 요청의 Origin을 신뢰 Origin Allow-list와 정확히 비교할 수 있다. Origin이 없을 때 Referer를 보조적으로 확인할 수 있다.

검증 시 다음을 지킨다.

구분	실행 주체	공격자가 이용하는 것	대표 대응
CSRF	피해자 브라우저가 대상 서버에 요청	자동 포함되는 인증정보	토큰·SameSite·Origin 검증
XSS	피해자 브라우저에서 공격 스크립트 실행	안전하지 않은 출력 문맥	출력 인코딩·Sanitization
세션 Hijacking	공격자가 탈취한 세션으로 직접 요청	세션 비밀값 탈취	세션 보호·재발급·만료
SSRF	애플리케이션 서버가 다른 대상에 요청	서버의 네트워크 권한	대상 제한·URL 검증·Egress 통제

XSS가 있으면 정상 페이지의 스크립트 문맥에서 토큰을 읽거나 요청을 만들 수 있으므로, XSS 방어는 CSRF 방어의 전제이기도 하다.

SameSite 쿠키 속성의 차이는 HTTP·HTTPS·쿠키·세션에서, XSS와 안전한 출력 처리는 XSS와 안전한 출력 처리에서 확인한다.