A Firefox extension to block outgoing cookies?

Discussion in 'privacy technology' started by gorhill, Apr 7, 2014.

  1. gorhill

    gorhill Guest

    I found many cookie managers, which can delete cookies, but is there an add-on out there for firefox which can remove outgoing (specifically, if possible) cookies from outbound the HTTP headers? The problem with only deleting cookies from the browser is that there is no guarantee cookies won't be sent back to the server before they are deleted.
     
  2. dogbite

    dogbite Registered Member

    Joined:
    Dec 13, 2012
    Posts:
    1,290
    Location:
    EU
    HTTP SB when you develop it for FF as well! :D:D
     
  3. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    Why would an extension need to look for and remove cookies in outbound HTTP headers?

    I haven't dug into the implementation, but I'm inclined to think that the primary mechanism for controlling cookies would be blocking read/write access to the cookie storage system. Which would indirectly prevent cookies from making their way into outbound Cookie: headers. Having said that, some potential exceptions that come to mind...

    1) An extension modifying behavior and injecting it own cookies, directly or indirectly, into outbound headers. Rare? Difficult to address via another extension due to order dependence?

    2) Javascript attempting to create or modify XMLHttpRequest Cookie headers. I think I read that this should *not* work, for the objective is to prevent interface users from messing with headers that should be maintained by the browser itself. Haven't tested this myself.

    3) A plugin injecting its own cookies. I don't think there is anything Firefox can do if the plugin bypasses Firefox and talks directly with the destination site. When talking through Firefox, perhaps there are protections (similar to #2 idea above) to prevent Cookie header manipulation?? Haven't tested this myself.
     
  4. gorhill

    gorhill Guest

    I wanted to further investigate why Flash-based videos are served on Youtube for Firefox when using an encrypted connection, while the same video is served HTML5 on an unencrypted connection (this happens just for FF, not Chromium). Not that important, I was just curious.

    Re. "remove cookies in outbound HTTP headers", well that's what I do in HTTPSB, and there is no better way to ensure no cookies are leaving the browser. I could strip them from the response header, but this would prevent me from reporting them accurately to the user -- I would have to parse the set-cookie string, which is really not a straightforward task (RFC etc.). The browser does the parsing already, so I leverage this. Now I could delete them when the browser fires an event that a new cookie has been written to the browser, but all this is asynchronous (the event and the deletion), so no guarantee no cookies would make it to the request headers. Stripping the cookie header synchronously before the request headers are sent guarantees that the extension does what the user is told it does.
     
  5. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    Well if you saw anything interesting there let us know. For now I'll try to stay focused...

    ... *that* way. However, the information stored in cookies (isn't that we're really trying to block?) could potentially leave the browser via some other mechanism (URL param, POST data, etc). Less likely perhaps, but worth noting.

    That [also] wouldn't prevent them from being manipulated via javascript and document.cookie operations.

    Hmmm. So the browser (are you talking about Chrome, or Firefox, or both right here?) does not provide *any* way for extensions to allow/deny cookie storage writes and reads [synchronously]? This being fact would jive with your question, but it seems strange to me... that window of vulnerability you are describing. Technically speaking, I think a cookie blocker should block even back to back write cookie then read cookie operations via javascript, which could be extremely fast. Both the write and the read should fail.[/QUOTE]
     
  6. gorhill

    gorhill Guest

    Would, should, could...

    I went through all what you are pondering above. I really did. Multiple times. Still come back to re-evaluate regularly. And in a practical context (providing users a useful and reliable tool).

    Re. "the information stored in cookies"... A cookie name can also be *the* information. Safest is to assume the cookie name and value are sensitive. Now, if someone blocks cookies while allowing javascript, than he has more than just js code reading cookies to worry about (localStorage, etc.), so I am not going to forfeit the cookie stripping feature because some other mechanisms could be used if a user allows javascript. Running stats collected by the extension shows that a lots of cookie headers are foiled, so it's definitely is helping reduce leaked information while a user surf.

    Stripping them at the outbound requests takes care of these javascript-created cookies.

    Reality is I have to deal with an API, and stripping the cookies from the outgoing headers works toward the most important goal of giving the user control to prevent cookies from reaching a server. That a cookie sits on their machine for a few second does no harm. That the same cookie doesn't reach its intended destination *is* what really matters.

    Whatever new API comes around, I will re-evaluate my real-world implementation, but then, that goes for everything, not just cookies.
     
  7. Sadeghi85

    Sadeghi85 Registered Member

    Joined:
    Dec 20, 2009
    Posts:
    747
    Do you know a way to use Youtube unencrypted when logged-in?
     
  8. gorhill

    gorhill Guest

    I did the test not logged in. Someone over at Hacker News mentioned this was not possible to be unencrypted while logged in. In any case, there is an add-on for Firefox which takes care to be sure HTML5 is served.
     
  9. Sadeghi85

    Sadeghi85 Registered Member

    Joined:
    Dec 20, 2009
    Posts:
    747
    Thanks.
     
  10. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    Yes, anyone concerned about cookies should also be concerned about other forms of client side storage. If you block one form you, you should consider blocking the other forms as well. Javascript enabled + storage mechanisms disabled would be a common objective I think, due to many sites requiring Javascript but still functioning adequately without client side storage.

    Removing... or not adding... the outbound cookie header stripping only makes sense if it is duplicative and provides no additional protection. At this point it sounds like it can provide some additional protection (for some contexts and purposes at least).

    Stripping the outbound cookie headers takes care of the outbound cookie headers.

    ... and any limitations or other restrictions that API, or the more general context, imposes upon your extension. Understood. Determining whether cookie blocking extensions... in general... are in any way hampered by such limitations/restrictions has been my primary goal here.

    Yes. Key words being "works toward". Generally speaking, we wouldn't want to solely rely upon outbound cookie header stripping. The objective would be to 1) prevent cookies from being created/stored/read on the machine, and 2) to prevent them from leaving the machine. With 1 having bearing on 2 of course.

    At this point I'm going to pause if not stop until I've had a chance to look over some cookie API and extension code, and maybe do some testing.
     
  11. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    FWIW, I looked into the Mozilla cookie API and saw no way to shim the storage reads/writes to control cookies that way. However, I did see the nsICookieService notifications. To experiment, I created a cookie-changed observer which immediately deletes every cookie added or changed, and also created a http-on-modify-request observer which looks for outbound Cookie: headers.

    I've tried this against a number of sites, including against a page that passes cookies cross-domain via XHR. So far, no cookies have gotten past the deletion routine and made it into an outbound Cookie: header.

    I've also tried this against a javascript page that does numerous back-to-back cookie writes/reads. So far, no javascript was able to read a cookie back after creating it.

    I also noticed that the cookie-changed observer appears to be re-entered before completing. IOW, the "observed: cookie-changed (added)" code is interrupted by and completes after the "observed: cookie-changed (deleted)" code, due to nsICookieManager remove() being called when a cookie is added.

    This is not enough to convince me that such an approach is reliable and I can't find words to that effect, but I was pleased to see no failures. I'd be curious to know if you were able to observe cookies slipping past such an approach, and if so, what the conditions were.
     
  12. John Hinsdale

    John Hinsdale Registered Member

    Joined:
    Nov 20, 2014
    Posts:
    1
    I noticed this thread, which is rather dated, however the functionality discussed is exactly what is done by a Chromium (i.e., Chrome, Opera) extension I just published here: http://www.alma.com/chromium/hin/

    I've found it very useful to block cookies in BOTH directions on a selective basis. In particular, you can set things up so that, in the same browser window, you can remain signed into Google Gmail or Yahoo Mail, but not send the cookies when using Google search or Yahoo search that would allow them to log the search under your ID.

    -- John Hinsdale
     
  13. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    426
    Yes. The "Modify Headers" firefox extension enables you to set rules (per request header name) and you can use it to strip the "Cookie:" header.
    https://addons.mozilla.org/en-US/firefox/addon/modify-header
    Note that MH rules are applied globally, though (vs on a site-by site, or per per-domain basis)
     
  14. Alhaitham

    Alhaitham Registered Member

    Joined:
    May 18, 2013
    Posts:
    188
    Location:
    Egypt
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.