0

There are used cookies on my website. Recently I noticed some cases of scamming when a third-party extension steals user’s session cookies and sends it to scammers. Is it possible to prohibit access of browser extensions to cookies of my website? With the help of any meta tag maybe?

Эльдар Гучеренко
  • 101
  • 1
    An extension can read any cookie you transfer to the browser so the only way to prevent this is to not use cookies or add an additional layer of security (like 2FA is an added layer for user+password). – wOxxOm Aug 15 '18 at 15:18

1 Answers1

0

TLDR: HTTPS is a must. Extensions have absurd level of access to the cookies, including httponly. Looking over here, a manifest.json can point to an extension script that ultimately gets access to your cookie, but if you are using CSP header to whitelist domains, then I presume the extension cannot do anything with it, unless they work at a lower layer (scripts are injected (:facepalm:) so CSP isn't applicable to them, alas from what I read, it looks like that....)

I would consider first controlling the third party apps that I want to allow communication. For that, consider:

To make use of above, you 'need' to switch your protocol to https.

Next, it is still possible that scripts you trust can exhibit malicious behavior, then for those cookies that are strictly private, set those cookies from the server side with httponly option:

  • Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

This way js cannot access them. Read through the cookies @MDN

Needless to say, do not allow other people to get access to your window:

  • If you use oWindow = window.open(.....), make sure oWindow does not have access back to you: oWindow.opener = null;
  • If you have links etc, always use rel='noopener noreferrer' attribute on them.
  • Prevent other windows from opening your page in an iframe: X-Frame-Options: SAMEORIGIN

Lastly, I do not recommend this (I didn't try either) as it does not provide real security, however if you are sure the third party implementations do not need XMLHttpRequest, you can monkey patch it, delete it from the global:

 XMLHttpRequest  = (function(xhtp){
       //do whatever you need here while you have access
       return null;
    }(XMLHttpRequest))

or alternatively remove the withCredentials getter/setter from the prototype as this never affects same origin anyway (supposed not to):

delete XMLHttpRequest.prototype.withCredentials
ibrahim tanyalcin
  • 5,643
  • 3
  • 16
  • 22
  • It won't affect extension's content script (or the background script's using chrome.webRequest API) which can access any page cookies. – wOxxOm Aug 15 '18 at 15:17
  • It is true, however extensions are installed at the choice of the client and they have absurd level of access. There is no other solution either. Although, I presume if I know what domains the extension needs to communicate to, then not specifying those domains in the CSP, will ultimately work because yes, the extension will have access to the cookie, but cannot send it anywhere. – ibrahim tanyalcin Aug 15 '18 at 15:27
  • Correct or not? – ibrahim tanyalcin Aug 15 '18 at 15:34
  • Extension's background script can send it anywhere (it depends on its manifest.json) regardless of your page CSP. – wOxxOm Aug 15 '18 at 15:52
  • 1
    I wrote it pre-edit just now. So there is no other solution than advising your users to only use 'trusted' extensions from the web store. Is that it? – ibrahim tanyalcin Aug 15 '18 at 15:53
  • People who install malware extensions are usually don't even know what an extension is so I don't think they'll understand the advice. As for a solution, I would try to find some differences in the request log on the server. – wOxxOm Aug 15 '18 at 15:57
  • So ultimately we cannot do anything about the extension grabbing the cookie. However what is done with that cookie later on from another domain (REMOTE_ADDR, REMOTE_HOST etc) is where we can intercept (maybe), is that what you are saying? – ibrahim tanyalcin Aug 15 '18 at 16:03