Isn't it unsafe that any program can access cookies of a browser?

Question

For example, for Firefox the cookies are kept as an SQLite DB in user's folder. Any program can read these cookies. So, for example, can't an .exe program read the contents of a cookie and pretend to the web site of that cookie as if it is the logged in user and start sending requests on behalf of that user?

Answer 1

To expand on Robert's comment, from the moment you have a malicious program running on your machine, using your cookies is not the worst thing it can do to you.

It can, among others:

• Add a certificate to your machine and change the DNS records. Now, when you connect to https://bank.example.com/, you reach the servers of an attacker, and his website looks very like your banking website when it prompts you for a password.

• Record your keyboard, especially the part where you enter your credentials, which usually change less frequently than session cookies.

• If the infected machine happens to be your smartphone (or can infect your smartphone through LAN), it may also track SMS you receive, cancelling the security provided by 2-factor authentication.

• Act as a ransomware, i.e. trash your backups, encrypt all your files and ask you to transfer $10.000 to a bank account in case you want your files back (given that when you pay, you won't get your files back anyway).

So can it access your cookies? Yes, it can. This may by itself cause you some harm, since a cleverly-written application which has access to your cookies may pretend that it's actually you when accessing a website you either accessed before or are doing right now.

How does it happen? Often, websites rely on cookies for authentication. You probably don't want to reenter your credentials on every page, so once you login, the website asks the browser to remember a session cookie; on server side, the identifier within this cookie is associated to a bunch of data, including the one which indicates that you, user 91313f91-c7dd-4f8e-8e88-24c08d162f53, was previously logged in using the account of Canol Gökel. Any request to the server which has a session cookie containing 91313f91-c7dd-4f8e-8e88-24c08d162f53 in it will be associated with the account of Canol Gökel, and the server is unable to know if the request comes from a legit usage of the site through the browser, or the fake one from a malicious application.

If the cookies expire as soon as you close the browser, it might¹ protect you from a malicious application which will run sometime in the future; although, it will do nothing against the malicious app which runs at the same time as you're browsing your website.

Therefore:

• Don't run untrusted code on your PC.

• If you do want to run untrusted code, create a virtual machine. Run the code inside. Throw the virtual machine away.

• Run semi-trusted code from accounts which have limited privileges. Cookies being stored in a way only your account can access them, just switching to a different account should be safe.

---

^{¹ Note that the fact that you (or your browser) deleted a file doesn't mean it cannot be recovered later. Therefore, even if you launched the malicious app after you removed all your cookies and closed your browser, it could still possibly access some of your cookies.}

Answer 2

Security is a matter of degree, and reasonable expectations.

All true multi-user-systems (Windows NT, Unixoids, ...) try to make sure that one users programs cannot interfere with another users data and programs.

While they generally also allow for more protection (using services running from a different account, for example the system-account), that's quite cumbersome and not designed for general deployment. The problem is that the interface needs to be rigorously defined, comprehensive, but still strictly secured.

Next, take a look at security through obscurity, which while in itself already a bad and very fragile idea, is quite impossible in open-source.

Then, consider asking the user for a password on every program-start for decrypting your data, with the caveat that concurrently-running programs of the same user would still be able to extract the secret from the process memory.

So, finally having exhausted us in trying to secure the client-side any more, there are mitigation techniques for the web-site itself, namely binding id and password somewhat to the clients network-address and/or other identifying markers it might leak. That way, exploiting stolen ephemeral credentials is quite restricted.