2

I have a request that uses a one time token embedded in the page to ensure CSRF protection - an attacker might be able to fool my users into making a illicit request, but they can't get the token, and even if they can it is changed with each request and can expire.

So far, so secure.

I want to implement background-sync with a service worker, so a user can post data offline, and then send that data later when they get a connection.

However, that means that the page isn't available to get the CSRF token, and any token linked with the request when the user builds it may be invalid by the time the data is actually sent.

This would seem to be a general issue with any progressive web site, what is the best practice to handle it?

I think that the background-sync could request a new token, apply it to the data to send and then send it, and that still be a loop that a CSRF attacker couldn't take advantage of, but I'm not certain of that. Can anyone confirm this either way?

At the moment the CRSF tokens ensure that the request has come from a specific page - that's going to have to change for any background process to work. Instead there will have to be some kind of CSRF token service, so we'll only be able to ensure that the user has previously and recently been able to make a request from that service. Is that still adequate protection against CSRF?

1

I think that the background-sync could request a new token, apply it to the data to send and then send it, and that still be a loop that a CSRF attacker couldn't take advantage of, but I'm not certain of that. Can anyone confirm this either way?

I'd take this approach. The Same Origin Policy will still ensure that any attacker cannot grab the CSRF token.

At the moment the CRSF tokens ensure that the request has come from a specific page - that's going to have to change for any background process to work. Instead there will have to be some kind of CSRF token service, so we'll only be able to ensure that the user has previously and recently been able to make a request from that service. Is that still adequate protection against CSRF?

It is good enough to have one CSRF token per user session. There is little need to go more granular than this and to do it per page. As long as the token is associated with the session and cannot be used for other sessions, then this would mitigate CSRF.

A CSRF token service is a good idea.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.