로그인/등록 양식에 AntiForgeryToken을 채우는 것이 합리적입니까?

제 질문이 너무 단순하지 않기를 바랍니다. 그러나 보안에 관해서는 모두 회의적입니다.로그인/등록 양식에 AntiForgeryToken을 채우는 것이 합리적입니까?

이 두 가지 경우 (로그인/등록) 이전에는 로그인 한 사용자 (세션 쿠키)가 없었기 때문에 로그인/등록 양식에 AntiForgeryToken을 등록해야하는 이유는 무엇입니까?

2012-01-02 Kenan Deen

일반적으로 그렇지 않습니다. 당신이 말하는 공격은 교차 사이트 요청 위조 (CSRF)입니다. 이러한 유형의 공격은 로그인 한 사용자 (사이트 A와 사이트 B에 로그인 한 상태에서 사이트 A가이를 알고있는 경우 HTML 코드를 삽입하면 요청이 사이트 B로 이동하게됩니다 당신은 그것을 시작했고 민감한 행동이 수행 될 수 있습니다). 이러한 공격은 문제의 사이트에 대한 모든 요청과 함께 세션 쿠키/토큰을 보내는 브라우저에 의존합니다 (사이트 A는 사이트 B에 요청을 보내고 브라우저가 사이트 B에 요청을 보내 모든 쿠키를 포함하도록 조치 X를 수행하라는 요청을 포함 함) (세션 쿠키를 포함하여, 요청과 함께 사이트 B로 보내야 함).

anti-CSRF 토큰은 클라이언트에 요청 양식을 보내면 클라이언트가 조치 요청과 함께 보내야하는 예상치 못한 값을 포함하기 때문에 작동합니다. 다시 돌아 오면 수행 할 작업 요청이 클라이언트에 보낸 양식으로 시작되었음을 알게됩니다. 그것이 돌아 오지 않는다면 요청은 위조 될 수 있으므로 무시해야합니다. 사이트 A의 코드가 사이트 B에 대한 세션 쿠키를 사용하여 사이트 B에 요청을 보내면 사이트 A의 코드는 포함 할 anti-CSRF 토큰 값을 알 수 없으므로 위조 된 요청은 거부됩니다.

사이트에서 CSRF 공격을 막으려면 로그인 된 사용자를 활용하여 위조 된 요청을 방지하기 위해 중요한 작업을 시작할 수있는 모든 양식에 이러한 토큰을 포함시켜야합니다. 사용자가 현재 로그인하지 않은 상태에서 브라우저가 모든 요청과 함께 세션 쿠키/토큰을 전송한다는 사실을 다른 사이트에서 활용할 수 없으므로이 방어는 로그인하지 않은 사용자에게는 무의미합니다.

출처

2012-01-02 01:04:32 jeffsix

CSRF에 대한 좋은 설명 평범한 말로! – Romias

나는 또한 "일반적으로"나는 지적해야한다. CSRF의 변형 인 "로그인 CSRF"라고 불리는 공격이 있습니다. 이미 로그인 한 사이트에 요청을 제출하도록 속여서하는 대신 공격자는 사이트가 다른 사용자로 보도록 다른/자신의 자격 증명을 사용하여 사이트에 로그인하도록 속일 수 있습니다. 예를 들어 관련없는 사이트에 Google의 로그인 코드가 포함되어 있고 브라우저가이를보고 실행하면 Google에 공격자 제어 사용자로 로그인하게됩니다. 그런 다음 검색 할 때 로그인하지 않았다고 생각하면 – jeffsix

이 될 것이며 Google은 검색 기록 (가상의 예)을 추적합니다. 그런 다음 공격자는 나중에 해당 자격 증명을 사용하여 로그인하고 검색 한 내용을 볼 수 있습니다. 그것은 매우 다르지만 매우 관련이있는 CSRF 공격이며, CSRF 토큰을 적절한 유스 케이스로 생각하면 완화시킬 수있는 CSRF 토큰을 넣어 완화 할 수 있습니다. – jeffsix

로그인/등록 양식에 AntiForgeryToken을 채우는 것이 합리적입니까?

답변

관련 문제