I have recently installed an application that was developed with Electron that requires I authorize via Google to use the application.

I did this at the same time as monitoring the application with procmon and seeing what the application does. It appears to write to a SQLite3 database stored in AppData/Roaming on Windows.

The database is not encrypted or password protected but contains sensitive cookies such as .google.com NID xxxxxxx and HSID and LSID values.

This concerns me because I can use these values to make requests to Google which could be used to mimic my identity.


I took the values and I replicated a Google request by replaced the values in the database and I could successfully make a request to a Google service. In my example I used returned my recent Google activity in JSON form. After more testing I was also able to view my contacts and perform other actions.

I am not a Windows user or Windows developer but this strikes me as strange as this database is readable which means a rouge application/user could read this and the fact I can replicate requests worries me. Surely apps are supposed to use API's for this and not storing users cookies? Basically this app undermines the security of my Google service.

I know Chrome stores it's cookies in a SQLite database but there is at least some level encryption there because cookies are encryption. But, they're not for this applications database. My Brave browser's database for example is protected by SQLCipher.

Is this a security concern and if so what category does it fall under?


EDIT: Based on your comment, it sounds like your concern might be less "why are these secrets not encrypted?" and more "why is this app storing full Google session tokens instead of using OAuth to get restricted-access tokens?" That is a perfectly valid criticism of the software; it is highly unlikely that it needs more access than it could get through OAuth, and using OAuth is more secure because in the event that the token (or the app itself) gets compromised, it can do less harm to your account and it is easier to tell what happened and close off access.

Just don't expect the access token or refresh token to be stored encrypted, unless the app asks you for a password every time you launch it (and even then, it's possible for a malicious program to steal the tokens anyhow). There are some apps for which the extra security gained from demanding a password on every launch is worth the hassle (password manager apps/extensions like LastPass or encryption tools like gpg often do this, for example). Unless that's happening, anything else that is done to the secrets is basically obfuscation, not security.

The standard security model for Windows (and other modern general-purpose operating systems) assumes that any code you run is trusted to have whatever privileges you run it with. In other words, if you don't trust a program with access to your saved cookies (and all major browsers store cookies either in plain text or easily decryptable by a running program), then either run it in a sandbox that has limited access to the file system (such as a Windows Store app on Win8+, or the highly-restrictive sandbox Chrome uses for its renderer processes), run it under a different user (standard users cannot read the contents of another user's profile directory, including the AppData directory), or don't run it at all. "Full-trust" (non-sandboxed) apps running under the same user account do not, and cannot, keep secrets from one another; the burden is on the user to not run such full-trust software unless you do, in fact, trust it.

While it might give you some peace of mind if the cookies were encrypted, what encryption key would you use, and where would it be stored? You'd either need to enter a password to generate a key every time you launch the app, or the key would need to be stored in such a way that any other programs running under your account could also access the key and then access the files (there is no such thing as data that only one program could ever read). For that matter, if you run a malicious program under your account, it could simply attach to the Electron app as a debugger and read its secrets straight out of memory.

If you're concerned that somebody running software outside of your account - for example, a privileged process that can read into other users' home directories, or another operating system entirely (such as a thief might use to bypass Windows' protections and try to steal data from your hard disk), you could use encryption to defeat that. Windows offers three main ways to do this: DPAPI (Data Protection API), EFS (Encrypting File System) and BitLocker Full Volume Encryption. DPAPI encrypts or decrypts arbitrary blobs of data with a key that is protected by the user's password; a program must specifically request the data be encrypted or decrypted but doesn't have to supply a key because if the program is running under a logged-in Windows session, the user's key is used (if the program is not running under the user that encrypted the data, this won't work). EFS encrypts specific files (setting it for a directory encrypts all the files within that directory) also using a key protected by your Windows password, but transparently decrypts the data on read (and re-encrypts on write) for processes running under your account. So long as an attacker cannot guess / brute-force your password the data is safe, but malicious software that you run (or that an attacker runs after compromising a program you ran) can still read the data. BitLocker encrypts the entire hard disk (aside from a small bit containing some boot code to enable decrypting the rest) and can be set up to require a password when the computer boots to Windows, but once Windows is running, any software (not just software under your account) will be able to access the disk; BitLocker only protects against offline attacks.

EDIT 2: You mentioned Chrome's encryption of cookies. Chrome uses DPAPI (on Windows), which uses your password as a key protector much like EFS does. On OSX, it uses a password-derived key and stores the password in the Keychain, which I believe is also protected by the user's password (though I may be wrong). On Linux, Chrome apparently uses the static, hardcoded password "peanuts" to derive the encryption key. Security-wise, that last approach is worth exactly "peanuts", so at least the "password" is appropriate. Also added DPAPI to the main response.

  • Fair point. I do not like this model, and gives me even more reason to dislike windows. Anyway, my other concern with this is that the actual application owners have access to these cookies that can be used for far more than just querying basic data. I can't understand why the Google API wasn't used here because they can gather so much more than just my name and basic data. Do I trust the company? No. But they're huge and I was pentesting their exe so it raised some concerns. – BugHunterUK Dec 13 '18 at 0:00
  • I mean, literally every mainstream-ish desktop or server OS works this way. Linux, MacOS, *BSD, all the other flavors of Unix, etc. ChromeOS, Android, iOS, and so on get around this "problem" by simply not allowing you to have any full-trust software, at the cost of being limited to whatever the OS makers decide to permit sandboxed apps to do. (That restriction is a large part of why some people jailbreak those operating systems.) – CBHacking Dec 13 '18 at 0:14
  • As for pentesting untrusted software, there are many reasons why you should be using a VM and a throw-away account for that, and "in case it is untrustworthy and compromises my security and/or privacy in some way" is very much among them. – CBHacking Dec 13 '18 at 0:17
  • I am most definitely running untrusted software securely :) I have separate machines purely for this. My main OS is Qubes and my other machine Ubuntu. Just not a regular Windows user. My opinions are based on my pains using Windows as a Linux user. – BugHunterUK Dec 13 '18 at 0:23
  • I'm tempted to write this issue up public though simply because this large brand that is trusted in many corporate environments is storing cookies and not using an API. At least if they used the API the user would have some sort of trust that sensitive data can not be seen. Their current implementation risks users privacy and security imho. – BugHunterUK Dec 13 '18 at 0:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.