원글 페이지 : 바로가기
CSRF 란 사이트 간 요청 위조(Cross-site request forgery, CSRF)는 웹사이트 취약점 공격의 하나로, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격을 의미한다. CSRF 공격 시나리오 1. 사용자는 정상적으로 웹 애플리케이션에 로그인 – 로그인 과정에서 서버는 사용자의 세션 정보를 쿠키에 저장 – 이 쿠키는 세션 ID를 포함하고 있으며, 사용자가 로그인 상태를 유지하도록 함 2. 공격자는 사용자를 피싱 이메일이나 메시지를 통해 악성 링크를 클릭하도록 유도 – 피싱 이메일은 긴급한 보안 문제나 계정 확인을 빌미로 사용자를 속임 3. 패스워드 변경 요청 – 사용자가 악성 링크를 클릭하면 브라우저는 자동으로 웹 애플리케이션 서버에 요청을 보냄 – 이 요청에는 쿠키에 저장되어 있던 사용자의 세션 ID도 포함되어 있음 – ex) 공격자가 생성한 악성 링크는 다음과 같음 클릭하세요 – 사용자가 이 링크를 클릭하면 브라우저는 쿠키에 저장된 세션 ID와 함께 패스워드 변경 요청을 서버로 전송 4. 서버 처리 – 서버는 악성 링크를 통해 전송된 요청을 수신함 – 전송된 요청에 담긴 세션 ID를 통해 인증된 사용자로부터 온 것으로 판단 – 사용자의 패스워드를 변경함 5. 변경된 패스워드로 접속 – 공격자는 새로운 패스워드를 사용하여 사용자의 계정에 접근 CSRF 공격이 성공하기 위한 2가지 조건 1. 사용자가 사이트에 로그인 된 상태 2. 사용자가 공격자의 악성 링크나 페이지에 접근 XSS와 CSRF 차이 XSS와 CSRF의 차이를 표로 정리하면 다음과 같다. 구분 XSS CSRF 방법 악성 스크립트가 클라이언트에서 실행 권한을 도용당한 클라이언트가 가짜 요청을 서버에 전송 원인 사용자가 특정 사이트를 신뢰 특정 사이트가 사용자를 신뢰 공격 대상 클라이언트 서버 목적 쿠키, 세션 탈취, 웹사이트 변조 권한 도용 CSRF 방어 방법 1. CSRF 토큰 사용 – 사용자의 세션에 임의의 난수 값을 저장하고 사용자의 요청 마다 해당 난수 값을 포함시켜 전송 – 백엔드에서 요청이 들어올 때마다 세션에 저장된 토큰 값과 요청 파라미터에 전달되는 토큰 값이 일치하는지 검증 2. SameSite 쿠키 설정 – 쿠키가 동일한 사이트에서만 전송되도록 설정 3. Referer 검증 – 백엔드에서 요청의 Referrer 헤더를 확인하여 요청이 올바른 도메인에서 왔는지 확인 4. GET 요청을 안전하게 처리하도록 구현 – 백엔드에서 GET 요청은 상태를 변경하지 않는 작업에만 사용 – 상태 변경 작업은 POST, PUT, DELETE 등의 메소드를 사용하도록 구현 출처 : https://nordvpn.com/ko/blog/csrf/ https://rjswn0315.tistory.com/173 https://velog.io/@haizel/XSS%EC%99%80CSRF-%EC%B0%A8%EC%9D%B4%EC%A0%90-%EB%B0%8F-%EB%8C%80%EC%9D%91-%EB%B0%A9%EC%95%88 https://velog.io/@rookieand/HTTP-Cookie-%EC%99%80-SameSite-%EC%A0%95%EC%B1%85%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C https://velog.io/@cjyooong/CSRF-%EA%B3%B5%EA%B2%A9%EC%9D%B4%EB%9E%80-%EA%B7%B8%EB%A6%AC%EA%B3%A0-CSRF-%EB%B0%A9%EC%96%B4-%EB%B0%A9%EB%B2%95