사용자가 로그인한 상태에서 의도와 무관하게 악성 행위(게시글 삭제, 비밀번호 변경 등)를 강제로 수행하게 만드는 웹 보안 공격
<aside> 💡
피싱 사이트 접속 유도는 개시글 방문이나 메일 등등 여러 방법으로 유도할수 있다.
</aside>
Referer check (리퍼러 체크)
**HTTP 요청 헤더(request header) 정보에서 Referrer 정보를 확인할 수 있다**
- (Referer 헤더는 HTTP 요청이 발생한 출발지 웹 페이지의 URL을 담고있다)
**사용자가 taetae.com 에서 /count 경로에 접속 할때 서버로 전송되는 요청의 헤더에는 다음과 같은 정보가 포함된다.**
- Host = taetae.com
- Referer = taetae.com/count
**하지만 공격자의 웹 사이트 xxx.com 에서 /count 에 접근 하게 되면**
- Host = taetae.com
- Referer = xxx.com/count
**서버는 Host(taetae.com)와 Referer(xxx.com)의 도메인이 서로 다르다는 것을 확인한다.**
서버 도메인 이름과 **Referer의 도메인이 일치하는 것을 확인하고, 정상적인 요청으로 판단하여 처리를
진행한다.
따라서 서버는 이 요청을 외부에서 들어온 비정상적인 요청 (CSRF 공격)으로 판단하고 차단하게 된다.**
CSRF 토큰사용 (세션 기반)
**사용자가 페이지를 방문할때나 로그인 한 경우 CSRF 토큰을 생성해 서버 세션에 저장한다.
이후 사용자가 요청한 페이지의 HTML 코드를 서버에서 생성할 때 쿠키나, 헤더에 저장된 세션 아이디를 통해 서버
세션에 저장한 CSRF토큰 값을 읽어와 HTML 폼 내부의 숨겨진 필드(<input type="hidden">)에 삽입 후 페이지를 반환 한다.**
- 공격자 서버에서 구성되는 페이지는 저장된 CSRF 토큰을 알수 없기 때문에 HTML 폼에 토큰을 삽입할수 없다.
**서버는 요청에서 온 토큰과 세션에 저장되어 있는 토큰을 비교 한다
정상적인 출처에서 온 경우 요청을 처리 한다.
만약 불일치 한 경우 요청을 차단한다.**
<aside> 💡
Spring Security 의 CSRF 보호 ****기본 방식이다
</aside>
Double Submit Cookie (무상태)
**사용자가 페이지를 방문할때나 로그인 한 경우 CSRF 토큰을 생성해 쿠키에 담아 클라이언트에 전송한다.
이후 사용자가 요청을 보낼때 쿠키에 저장된 CSRF 토큰의 정보를 요청 데이터에 수동으로 삽입 한다.
-** 이때 xxx.com에서 taetae.com에 설정된 쿠키를 읽을수 없기 때문에 토큰의 정보를 요청 데이터에
수동으로 삽입할수 없다.(Same-Origin Policy)
**서버는 쿠키에 담긴 CSRF 토큰과 데이터 정보에 담긴 CSRF 토큰 두개를 획득 한다.
이 두개의 CSRF 토큰이 일치 하는지 확인한다
정상적인 출처에서 온 경우 요청을 처리 한다.
만약 불일치 한 경우 요청을 차단한다.**
<aside> 💡
JWT 방식과 어울리는 방어 방법이다.
</aside>