opendID 연결 제공자를 통해 로그인하고 콜백 www.mysite.com/auth/callback으로 리디렉션되었다고 가정 해 봅시다. 그런 다음받은 토큰을 참조하는 ID가 포함 된 httponly 쿠키를 만들어 브라우저에 wwww.mysite.com/으로 전달합니다. 다른 사이트가 동일한 세션 쿠키가 포함 된 요청을 어떻게 제출합니까? 브라우저가 요청한 도메인의 쿠키 만 전달하지는 않습니다. 따라서 www.evil.com이 www.mysite.com/api/endpoint에 요청하면 세션 쿠키가 전달되지 않고 위조 된 요청이 무효화되지 않습니까?세션 쿠키를 사용할 때 csrf 토큰이 필요한 이유는 무엇입니까?
나는 여기에 기본적인 것을 놓치고 있습니까?
웹 브라우저가 다른 도메인으로 요청을 보내면 먼저 해당 도메인에 쿠키가 있는지 확인한 다음 요청이 있으면 해당 요청을 함께 보냅니다. 따라서 앱에 요청을 보내려는 웹 애플리케이션에서 쿠키와 함께 요청을 보냅니다. 위조 방지 토큰의 기본 개념은 웹 브라우저가 모든 정보를 보내는 경우에도 토큰이 응용 프로그램에서 제출 된 적법한 요청으로 작성한 토큰과 일치하지 않으면 실패합니다.
원본 출처 요청을 통해 쿠키를 보내지 않으려면 samesite 플래그를 쿠키에 사용할 수 있습니다. 여기서 Strict 모드와 Lax 모드를 선택할 수 있습니다. Strict 모드에서는 원본 교차 요청을 통해 사이트 쿠키를 보내지 않으므로 세션 쿠키를 보내지 않아도됩니다. 여기에서 문제는 다른 사이트 (예 : 페이스 북에서 엄격 모드를 사용하는 경우)로 이동하려고 시도하면 페이스 북으로 이동하려고하면 쿠키가 전송되지 않으며, 다시 인증 할 수 있습니다 (응용 프로그램과 사용자 기반에 따라 성가신 또는 좋은 기능 일 수 있음). Lax 모드는 꽤 비슷하지만이 모드에서는 안전 HTTP 동사 (GET, HEAD, OPTIONS 및 TRACE)를 통해서만 쿠키를 보내므로 여전히 POST/PUT XSRF 공격으로부터 사용자를 보호 할 수 있습니다. GET 요청에 대해 성가신 행동이 없습니다. 어떤 앱이 앱의 더 나은 옵션이 될지 결정하는 것은 개발자의 몫입니다. XSRF 및 samesite 쿠키에 대한
상세 정보 : 나는 경우, 브라우저, 그것은 사용하는 것이 URL`evil.com`에서 것을 상상 http://arnoldcer.com/2017/03/14/cross-site-request-forgery-what-it-is-how-to-exploit-it-and-how-to-defend-against-it/
에 관계없이 해당 페이지에 만들어진 것을 요청의 요청 도메인으로 . 이것은 잘못되었습니다. 브라우저는 해당 요청의 도메인에 따라 쿠키를 추가합니다. samesite 플래그는 csrf 토큰의 필요성에 대한 흥미로운 대안입니다. – Panda