서비스 근로자를위한 모범 사례 패턴 - CSRF 보호를 통한 백그라운드 동기화

Question

CSRF 보장을 위해 페이지에 포함 된 일회 토큰을 사용하는 요청이 있습니다. 공격자가 내 사용자를 속여서 불법적 인 요청을 할 수는 있지만 그들은 토큰을 얻을 수 없으며, 가능할지라도 요청마다 변경되어 만료 될 수 있습니다.

지금까지 그렇게 안전합니다.

서비스 작업자와 백그라운드 동기화를 구현하여 사용자가 오프라인으로 데이터를 게시 한 다음 나중에 연결이되면 해당 데이터를 보낼 수 있습니다.

그러나 CSRF 토큰을 가져 오는 데 페이지를 사용할 수없고 사용자가 문서를 작성할 때 요청과 연결된 토큰이 실제로 데이터가 전송 될 때까지 유효하지 않을 수 있음을 의미합니다.

이것은 모든 점진적인 웹 사이트의 일반적인 문제인 것처럼 보입니다. 어떤 웹 사이트를 처리하는 것이 가장 좋은 방법입니까?

background-sync가 새로운 토큰을 요청하여 보낼 데이터에 적용한 다음 보내면 CSRF 공격자가 사용할 수없는 루프가 될 수 있다고 생각합니다. 확실하지 않습니다. 누구든지이 방법을 확인할 수 있습니까?

부재중 서비스 직원이나 백그라운드 동기화의 기능이 있습니까?

Answer 1

저는 CSRF의 주제에 대해 "모범 사례"에 대해 말할 자격이 없지만 OWASP guidelines on CSRF에 대한 귀하의 생각은 정확합니다.

현재 OAuth는 비슷한 방식으로 사용됩니다. 개별 클라이언트는 새로 고침과 무기 토큰이 발행됩니다. 새로 고침 토큰의 유효 기간은 무기명 토큰보다 훨씬 깁니다. 클라이언트는 새로 고침 토큰을 사용하여 새로운 베어러 토큰을 만들 수 있습니다. 일부 고객은 모든 요청에 ​​대해 새로운 소지자 인 "전체 순환"을 선택할 수 있습니다. 어떤 사람들은 실패를보고하고 나서 새로운 것을 작성하기 전까지 무기를 사용하기로 선택할 수도 있습니다.

시나리오에서 백그라운드 동기화는 새로 고침 및 무기명 토큰을 요청하고 수신합니다. 그것은 계속 진행중인 무기 토큰으로 URL을 만들고, 시도가 실패 할 경우 동기화 할 때 새로 고침 토큰을 사용하여 새 베어러를 작성하고 새 베어러로 URL을 재구성 할 수 있습니다. 물론, 새로 고침이 만료되었거나 취소 된 경우 오프라인으로 너무 길어 재실행해야합니다.