귀하가 웹사이트를 탐색할 때, 해당 웹사이트가 귀하를 대신하여 다른 웹사이트에서 데이터를 요청하는 것이 일반적입니다. 예를 들어 대부분의 경우 웹 사이트에 표시되는 동영상은 일반적으로 웹 사이트 자체에 저장되지 않습니다. 비디오는 웹 사이트에있는 것처럼 보이지만 실제로 youtube.com 같은 비디오 스트리밍 웹 사이트에서 삽입되고 있습니다. 이것이 바로 콘텐츠를 더 빠르게 전달하는 데 사용되는 CDN(콘텐츠 전송 네트워크)입니다. 많은 웹 사이트는 CDN에 스크립트, 이미지 및 기타 대역폭이 부족한 리소스를 저장하므로 검색 할 때 이미지와 스크립트 파일은 웹 사이트 자체가 아닌 가까운 CDN 소스에서 다운로드됩니다. GET 및 POST 요청은 특정 HTML 태그를 통해 또는 자바스크립트를 통해 자동으로 트리거되는 경우가 있습니다. 따라서 항상 사용자 상호 작용이 필요한 것은 아닙니다. 실시예; 태그는 src 특성 내에 선언된 이미지 링크에 대한 GET 요청을 자동으로 생성합니다. 또 다른 예로는 사용자가 쿼리를 입력할 때 검색 제안을 자동으로 가져오는 데 사용되는 XHR POST 요청이 있습니다. CSRF 공격 예는 웹 사이트에서 사용자가 이메일 주소를 사용하여 로그인할 수 있도록 허용합니까? 대부분의 웹 사이트에는 사용자의 정보를 저장하는 “내 계정” 페이지 또는 기타 유사한 페이지가 있으며 종종 사용자가 자신의 이메일 주소를 변경할 수 있습니다.

이 이메일 주소 변경은 POST 요청또는 GET 요청으로 변경될 수 있습니다. 공격자가 이 요청을 알고 나면 이 요청을 위조할 수 있으며, 특히 사용자가 자신의 계정을 등록할 수 있는 경우 구조를 발견하는 것은 간단합니다. CSRF 공격이 성공하면 공격자는 피해자 사용자가 실수로 작업을 수행하게 됩니다. 예를 들어 계정의 이메일 주소를 변경하거나, 암호를 변경하거나, 자금을 이체하는 것일 수 있습니다. 작업의 특성에 따라 공격자는 사용자의 계정을 완전히 제어할 수 있습니다. 손상된 사용자에게 응용 프로그램 내에서 권한 있는 역할이 있는 경우 공격자는 응용 프로그램의 모든 데이터와 기능을 완전히 제어할 수 있습니다. GET을 사용하는 응용 프로그램에 대한 CSRF 공격의 실제 예는 악성 코드를 다운로드하기 위해 대량 규모로 사용 된 2008 년의 uTorrent 익스플로잇이었습니다. 이 기술의 보안은 동일한 원본 내에서 실행되는 자바스크립트만 쿠키의 값을 읽을 수 있다는 가정에 기반을 두고 있습니다. 악성 파일이나 이메일에서 실행되는 자바 스크립트는 그것을 읽고 사용자 정의 헤더로 복사 할 수 없습니다. csrf 토큰 쿠키가 악성 요청과 함께 자동으로 전송되더라도 서버는 여전히 유효한 X-Csrf 토큰 헤더를 기대할 수 있습니다. 쿠키의 동일한 사이트 플래그는 CSRF 공격을 방지하고 웹 응용 프로그램 보안을 개선하는 데 사용되는 비교적 새로운 방법입니다.

위의 시나리오에서는 세션 쿠키와 함께 https://example.com/ POST 요청을 보낼 https://attacker.com/could 있는 것으로 보았습니다. 이 세션 쿠키는 모든 사용자에 대해 고유하며 웹 응용 프로그램은 서로 다른 사용자를 구별하고 로그인여부를 확인하는 데 사용합니다.