최근에 로그인 페이지 및 CSRF 토큰과 관련된 흥미로운 문제가 발생했습니다. 그러나 사용자가 오랜 시간 동안 로그인 페이지에 남아 있으면 세션이 만료되고 CRSF 토큰이 무효화 될 때/로그인 폼이 CSRF 토큰으로 보안되는지 확인하려고합니다. 이 문제를 피하는 방법에 대한 조언이 있습니까? 로그인 페이지에 CRSF 토큰을 사용하지 않을 것을 고려하고 있지만 이것은 좋지 않은 방법입니다.로그인 페이지에 CRSF 토큰을 어떻게 처리합니까?
기술적으로 말하면, 로그인 페이지는 사용자가 아직 로그인하지 않은 비 세션 페이지이므로 CSRF 완화가 실제로 필요하지 않습니다. 사용자가 세션을 설정하지 않은 경우 해커가 할 수있는 일은 많지 않습니다. 나는 그가 사용자 이름과 암호를 알고 있다면 로그온하도록 사용자를 속일 수 있다고 생각하지만, 그렇게 할 수 있다면 그는 대신 자신의 브라우저에서 로그인 할 수 있습니다.
로그인 페이지에서 CSRF 토큰을 고집하는 경우 토큰이 만료되기 전에 평소와 같이 토큰을 렌더링하고 Javascript 타이머 (setTimeout)로 페이지를 새로 고치는 것이 좋습니다.
CSRF에 대한 위키 백과 페이지 here은 로그인 CSRF라고하는 CSRF의 특수 카테고리가 가능하다고 언급합니다. 나는 공격자는 공격자의 자격 증명을 사용하여 대상 웹 사이트에 피해자를 기록하는 요청을 위조 할 수
페이지 자체에서 인용; 이것을 로그인 CSRF라고합니다. 로그인 CSRF는 다양한 새로운 공격을 가능하게합니다. 예를 들어, 공격자는 나중에 합법적 인 자격 증명 을 사용하여 사이트에 로그인하고 계정에 저장된 활동 기록과 같은 개인 정보를 볼 수 있습니다. 이 공격은 YouTube에 대해 시연되었습니다.
또한 최근 출시 된 매우 유명한 Java MVC 프레임 워크 (스프링 MVC)는 CSRF 토큰을 사용하여 CSRF 보호를 추가했으며, CSRF 보호를 위해 로그인 양식을 사용하도록 권장합니다. 다시 나는 형태 의 로그가 너무 CSRF 공격으로부터 보호되어야 요청에 로그 위조를 방지하기 위해 here
에서 인용. CsrfToken은 HttpSession에 저장된 이므로 HttpSession은 바로 으로 생성됩니다. 이것은 RESTful/stateless 아키텍처에서 불만족 스럽지만 실제로는 실질적인 보안을 구현하는 데 필요한 상태입니다. 상태가 없으면 토큰이 손상되면 아무 것도 할 수 없습니다. 실제로 CSRF 토큰은 크기가 작고 아키텍처에 거의 영향을주지 않아야합니다.
CSRF 보호 방법을 고려할 때는 Encrypted Token Pattern을 확인해야합니다. 이는 설계 상 비 상태이며 두 개의 토큰을 비교하는 Synchronizer Token 또는 Double Submit Cookie Patterns와는 반대로 단일 Token 만 필요합니다.
토큰이 로그인 페이지에서 만료되는 문제와 관련하여 ARMOR이라는 프레임 워크를 활용하여 CSRF로부터 보호 할 수 있습니다. CSRF와 관련된 로그인 페이지는 걱정할 필요가 없습니다. 일반적으로 사용자가이 단계에서 상태를 변경할 수있는 옵션을 제공하지 않기 때문에 CSRF가 중요합니다. 사용자가 로그인 한 후 토큰을 주입하는 것을 고려해 볼 가치가 있습니다.
또한 공식 을 참조하십시오.
추가하기 만하면 토큰이 익명 사용자 세션과 연결되어 있는지 확인하십시오. 그렇지 않으면 공격자가 HTML을 구문 분석하여 모든 세션에서 작동 할 토큰을 검색 할 수 있습니다. – SilverlightFox