New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Privacy consideration about the "cache" parameter of the Request object #585

Closed
tyoshino opened this Issue Dec 10, 2014 · 7 comments

Comments

Projects
None yet
6 participants
@tyoshino
Contributor

tyoshino commented Dec 10, 2014

(Copied from #398 (comment))

Let's start reviewing new functionalities carefully from security point of view.

I'm concerned that fetch() with the cache parameter set to e.g. the only-if-cached option may cause privacy leak. Like CSS :visited (http://dbaron.org/mozilla/visited-privacy), could it be abused to probe if a certain site was visited by the user?

@tyoshino tyoshino changed the title from Security consideration about the `cache` parameter of `Request` to Privacy consideration about the `cache` parameter of `Request` Dec 10, 2014

@tyoshino tyoshino changed the title from Privacy consideration about the `cache` parameter of `Request` to Privacy consideration about the "cache" parameter of the Request object Dec 10, 2014

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Dec 10, 2014

Member

I think this is a problem for force cache and only-if-cached, as both ignore timing information from the cache and therefore expose functionality beyond that of timing attacks on the cache.

I guess that's not really acceptable :-(

Member

annevk commented Dec 10, 2014

I think this is a problem for force cache and only-if-cached, as both ignore timing information from the cache and therefore expose functionality beyond that of timing attacks on the cache.

I guess that's not really acceptable :-(

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Dec 10, 2014

Collaborator

Agreed. If it's worth keeping, it could be restricted to the same origin.

Collaborator

jakearchibald commented Dec 10, 2014

Agreed. If it's worth keeping, it could be restricted to the same origin.

@tyoshino tyoshino referenced this issue Dec 11, 2014

Closed

window.fetch #581

7 of 14 tasks complete
@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 28, 2015

Member

@mayhemer @nikhilm @mnot any thoughts? I kind of like preserving the functionality for same-origin, but that also adds some complexity (e.g. rejecting cross-origin redirects).

Member

annevk commented Jan 28, 2015

@mayhemer @nikhilm @mnot any thoughts? I kind of like preserving the functionality for same-origin, but that also adds some complexity (e.g. rejecting cross-origin redirects).

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Jan 28, 2015

Member

same-origin makes sense if it's a significant attack. I'm not sure it is -- how is this qualitatively different than timing the cache, or just examining the Date in the response (subject to clock skew)?

AFAICT the only differences are:

  • It gives a slightly higher degree of confidence, but any decent heuristics on the timing + response are going to give a very high degree of confidence anyway...
  • It doesn't allow information about the probing to escape to the server. That's a little more concerning, but OTOH a single request that is the same as any legitimate request -- except that it doesn't happen as part of a page load -- is unlikely to be useful in actually stopping the attack.
Member

mnot commented Jan 28, 2015

same-origin makes sense if it's a significant attack. I'm not sure it is -- how is this qualitatively different than timing the cache, or just examining the Date in the response (subject to clock skew)?

AFAICT the only differences are:

  • It gives a slightly higher degree of confidence, but any decent heuristics on the timing + response are going to give a very high degree of confidence anyway...
  • It doesn't allow information about the probing to escape to the server. That's a little more concerning, but OTOH a single request that is the same as any legitimate request -- except that it doesn't happen as part of a page load -- is unlikely to be useful in actually stopping the attack.
@mayhemer

This comment has been minimized.

Show comment
Hide comment
@mayhemer

mayhemer Feb 9, 2015

For cross-origin 'without credentials' (the default) XHRs Gecko is using a distinct cache area called 'anonymous'. There is more - the anonymous context means to not send out any authorization headers, cookies, and to not use the standard cache (that is populated when you visit the page/load the resource as part of the page content.)

We could do the same here?

mayhemer commented Feb 9, 2015

For cross-origin 'without credentials' (the default) XHRs Gecko is using a distinct cache area called 'anonymous'. There is more - the anonymous context means to not send out any authorization headers, cookies, and to not use the standard cache (that is populated when you visit the page/load the resource as part of the page content.)

We could do the same here?

@mattto

This comment has been minimized.

Show comment
Hide comment
@mattto

mattto May 7, 2015

Member

Cache control options are tracked in https://crbug.com/453190

Member

mattto commented May 7, 2015

Cache control options are tracked in https://crbug.com/453190

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk May 7, 2015

Member

This issue moved here: whatwg/fetch#39 (There's also several other issues around cache in that repository, if anyone can solve them, please!)

Member

annevk commented May 7, 2015

This issue moved here: whatwg/fetch#39 (There's also several other issues around cache in that repository, if anyone can solve them, please!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment