3

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?

Is there some feature of service workers or background sync that I'm missing?

Keith
  • 150,284
  • 78
  • 298
  • 434

1 Answers1

3

I'm not qualified to speak for "best practices" on the subject of CSRF, but from my understanding of the OWASP guidelines on CSRF your thinking is correct.

Currently, I use OAuth in a similar fashion: individual clients are issued a refresh and a bearer token. The refresh token has a lifetime significantly longer than the bearer token. The client may choose to mint new bearer tokens as they see fit using the refresh token. Some clients may choose to do "full rotation", a new bearer on every request. Some may choose to use a bearer until it reports failure, then mint a new one.

In your scenario, your background-sync would request and receive both refresh and bearer tokens. It could go ahead and build the URL with the bearer token on hand, then when syncing if the attempt fails, use the refresh token to mint a new bearer and to rebuild the URL with the new bearer. Of course, if the refresh has expired (or been revoked) then you were offline too long and you need to reauth.

bishop
  • 37,830
  • 11
  • 104
  • 139
  • Cheers for the response - I kind of figured something similar, but I'm sure there are security experts who can pick holes in my opinion. – Keith Aug 05 '16 at 19:59
  • Possibly, though I'm note sure the answer isn't something specific to the implementation of service workers that I've missed, in which case I'm more likely to get an answer on here. – Keith Aug 05 '16 at 20:19
  • Facing a similar problem. I thought pages that are saved for offline should have security. But if you design the service worker as an api, it might not be needed. The sw is on the client com after all. Auth should happen server side in the background by an api and through json responses. Just an idea. – Nitin Dec 22 '16 at 19:57