CSRF
Cross-Site Request Forgery · 사이트 간 요청 위조
는 브라우저가 자동으로 붙이는 인증 정보를 이용해 사용자가 의도하지 않은 요청이 처리되는 문제다. 서버는 인증된 세션만 보지 말고 요청의 의도와 출처를 증명하는 조건을 검사해야 한다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- 요청에 세션과 연결된 토큰 검증을 적용한다.
- ··를 서로 다른 방어층으로 연결한다.
- 정상 폼과 외부 출처 요청의 처리 결과를 비교한다.
02어떤 순서로 동작하나
- 정상 폼 발급
서버가 인증된 세션에 연결된 예측하기 어려운 토큰을 정상 폼에 제공한다.
- 변경 요청 전송
브라우저가 폼 값·토큰과 쿠키 정책에 맞는 인증 쿠키를 보낸다.
- 인증과 토큰 검증
서버가 세션 유효성, 토큰 존재·일치·세션 연결을 확인한다. 쿠키에 토큰이 자동 첨부된다는 사실만으로는 충분하지 않다.
- 와 입력 검증
현재 사용자에게 변경 권한이 있고 값이 업무 규칙을 만족하는지 확인한다.
앞선 검증을 통과한 경우에만 변경한다. 오류 응답 전에 DB 변경을 먼저 수행하면 거부가 실제 보호가 되지 않는다.
03먼저 알아둘 용어와 구성요소
- 서버 세션과 연결하여 발급·검증하는 토큰.
- 쿠키와 요청 값의 관계를 검사하는 방식으로 서명·세션 결합 설계가 중요하다.
- 요청 출처의 스킴·호스트·포트 조합.
- 사이트 간 요청에서 쿠키 전송을 제한하는 속성.
- 요청의 사이트 관계·방식 등을 브라우저가 제공하는 헤더 정보.
- 이체·수정·삭제처럼 서버의 업무 상태를 바꾸는 처리.
- 스킴·호스트·포트가 같은 출처 관계.
- 사이트 관계를 기준으로 한 구분이며 과 동일하지 않다.
쿠키가 동반된 상태 변경 요청을 패킷에서 읽기
정상 로그인 상태가 사용자의 변경 의도를 증명하지 않는다는 점을 실제 요청 구조로 설명한다.
실습 구성과 전제
- 격리 의 폐기 가능한 계정으로만 을 시험한다.
- 사진 속 요청과 테스트 값은 당시 교육 환경의 기록이다. 자신의 환경에서는 새 토큰과 무해한 변경 항목을 사용한다.
상태 변경을 유발하는 입력 위치를 찾는다
- 사진의 폼은 게시 메시지 안에 다른 기능을 향하는 링크를 넣은 사례다. 메시지 저장과 링크 목적지의 은 서로 다른 요청이다.
- 링크를 봤다는 것·눌렀다는 것·서버가 변경을 수락했다는 것을 각각 구분한다.
원본 크기로 보기 ↗- URL-encoded 폼의 mtxMessage에 링크가 들어가며 별도의 변경 기능 경로를 가리킨다.
- 버튼 값은 Sign Guestbook이다. 겉으로 보이는 게시 기능과 링크의 목적 기능이 다르다.
확인 기준이 첫 화면은 입력 저장 요청이며 계정 변경 성공의 증거는 아니다.
자동으로 붙는 인증 자료를 확인한다
- 다음 캡처에는 변경 기능을 향한 GET과 Cookie가 함께 보인다. 브라우저가 인증 자료를 첨부해도 사용자가 그 변경을 의도했다고 증명할 수는 없다.
- GET은 안전한 조회 의미로 설계해야 하며, 을 GET에 맡기지 않는다. 메서드를 POST로 바꾸는 것만으로 가 해결되는 것도 아니다.
원본 크기로 보기 ↗- 요청 행은 비밀번호 변경 기능을 향한 GET이고 Cookie 헤더가 포함된다.
- Referer는 다른 과제 페이지를 나타내며 Response in frame 링크가 제공된다. 실제 변경 판정에는 대응 응답과 계정 상태가 더 필요하다.
확인 기준응답 메시지뿐 아니라 서버 상태가 바뀌었는지 확인한다.
의도 검증 실패가 변경 전에 끝나는지 시험한다
- 정상 토큰·누락 토큰·다른 세션 토큰으로 요청을 구분한다. 토큰 검증 실패는 실제 변경 코드가 실행되기 전에 거부돼야 한다.
- ··는 보조 조건이며 배포 환경의 정상 요청과 함께 시험한다.
확인 기준누락·불일치 토큰 요청 뒤 계정 정보가 그대로인지까지 확인한다.
실습에서 확인한 동작 원리
- 인증된 요청과 의도된 요청은 다르다.
- 거부 화면이 아니라 변경이 수행되지 않았다는 상태 증거가 필요하다.
04예제로 따라가기
- 정상 요청: 유효 세션·허용 ·일치하는 토큰을 가진 요청은 새 주소 형식과 업무 권한까지 검증한 뒤 변경한다.
- 토큰 누락: 같은 세션 쿠키를 보내도 토큰이 없으면 변경 전에 거부한다. 인증 성공과 변경 의도 검증 실패가 동시에 존재할 수 있다.
- 외부 출처: 토큰 없이 cross-site로 들어온 요청은 정책상 거부한다. 브라우저가 응답을 읽지 못하더라도 변경이 발생하면 보호에 실패한 것이다.
- 오래된 화면: 토큰이 회전한 뒤 이전 탭이 제출한 값은 정책에 따라 거부될 수 있다. 이때 데이터 변경 없이 다시 불러오도록 안내한다.
- 증거 연결: 상태 코드·거부 이유·DB 변경 여부를 함께 본다. 거부 응답을 보낸 뒤 내부 변경이 이미 발생한 구현은 순서가 잘못되었다.
05혼동하기 쉬운 점과 확인 기준
- 비교: 문자열 접미사 포함 여부 대신 파싱한 스킴·호스트·포트를 정확히 비교한다. 신뢰 프록시의 외부 URL 전달 설정도 함께 확인한다.
- 다중 탭: 요청마다 토큰을 즉시 폐기하는 정책은 뒤로 가기·재시도·동시 탭과 충돌할 수 있다. 보안 요구와 허용 수명을 명시한다.
- CORS 혼동: CORS 허용은 응답 읽기 정책이다. 단순 요청의 전송·서버 처리 자체를 모두 차단하는 방어로 가정하지 않는다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
함께 보는 학습 자료
아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.
OWASP: CSRF token과 출처 검증
인증 쿠키가 있는 요청과 사용자가 의도한 요청의 차이를 token·· 조건으로 설명한다.
- 검증과 의 선후 관계
- 의 한계와 · 구분
- ·Referer 검증에서 기대한 출처를 정하는 방법
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.