왜 악의적인 사이트는 공격하기 전에 GET를 통해 CSRF 토큰을 얻을 수 없습니까?

왜 악의적인 사이트는 공격하기 전에 GET를 통해 CSRF 토큰을 얻을 수 없습니까?

내가 정확히 이해했다면, CSRF 공격에서 악의적인 A 웹사이트는 내 브라우저에게 B 사이트로 요청을 보내라고 말합니다.내 브라우저는 자동으로 내 B 쿠키를 그 요청에 포함시킬 것입니다.비록 A가 그 쿠키들을 볼 수 없지만, 만약 내가 B에서 이미 인증을 받았다면, 그 요청은 합법적으로 보일 것이고, 요청된 어떤 조치도 성공적으로 수행될 것입니다.이를 피하기 위해 양식이 포함된 B 페이지를 방문할 때마다 CSRF 토큰을 받습니다.이 토큰은 내 세션과 연결되어 있으므로 B에 게시할 경우 해당 토큰을 포함해야 합니다. 그렇지 않으면 B가 내 요청을 거부합니다.이 계획의 이점은 A가 해당 토큰에 액세스할 수 없다는 것입니다.

두 가지 질문이 있습니다.

• 위의 설명이 맞습니까?
• 그렇다면 사이트 A가 먼저 브라우저에 B에게 GET를 보내고 응답에서 CSRF 토큰을 얻은 다음 토큰을 사용하여 B에게 POST를 전송하도록 지시할 수 없는 이유는 무엇입니까?GET에는 내 B 쿠키도 모두 포함되어 있으므로 토큰은 유효하고 내 세션에 연결됩니다.

감사합니다!

당신의 설명이 맞습니다.

사이트 A가 브라우저에 B로 가서 토큰을 가져오라고 하면 괜찮지만, 도메인 간 요청이기 때문에 A는 자바스크립트(브라우저 기능)로 토큰에 액세스할 수 없습니다.따라서 A가 브라우저에 B로 돌아가서 실제로 무언가를 하라고 말할 때 여전히 토큰을 요청에 포함시킬 수 없습니다.

즉, B가 토큰을 쿠키로 설정하지 않는 한.토큰 쿠키도 전송되어 모든 보호를 무효화하기 때문에 분명히 결함이 있을 것입니다.따라서 이 경우 토큰은 양식 값 또는 요청 헤더(또는 쿠키처럼 자동으로 전송되지 않는 다른 것)로 전송되어야 합니다.

이는 또한 B가 사이트 간 스크립팅에 취약할 경우 토큰이 도용될 수 있기 때문에 CSRF에도 취약하지만 CSRF가 더 작은 문제라는 것을 의미합니다.:)

맞아요.

사이트 A는 브라우저의 CORSF 전략 때문에 사이트 B의 csrf 토큰을 얻을 수 없습니다.

그리고 우리는 요청의 유효성을 확인해야 합니다.referer(위조될 수 있습니다.)https://en.wikipedia.org/wiki/HTTP_referer

또한 URL(AKA 쿼리 문자열)에서 crsf 토큰의 유효성을 검사하는 것이 좋습니다.

참고로,Laravel널리 사용되는 웹 프레임워크는 csrf 공격을 방지하기 위해 양식의 숨겨진 CSRF 토큰 필드를 사용합니다.

언급URL : https://stackoverflow.com/questions/40841355/why-cant-a-malicious-site-obtain-a-csrf-token-via-get-before-attacking