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
Discussion about security implications for offline-only apps or apps that only load secure content #110
Comments
bump 😀 |
Hi @petef19, thanks for being patient here. (Pulling some details from my earlier post in case it's helpful for others to reference). I'm also publishing a larger post on an introduction to electron that you may find helpful to understand some context of security, and how the framework has changed. nodeIntegrationTurning I wouldn't ever recommend anyone use rare cases
The key is that your app is never used by anyone else that I would see using enableRemoteModuleIt's deprecated, so don't use it. It's essentially another way similar to You accept the same risks as contextIsolationThis should always be set to By setting If your preload file doesn't eg. if your "verified" resource (1st party) gets a DNS takeover, then what you thought was safe, is now returning malicious content, your backend electron code might have a security hole on the fact that you were relying your resources were secure and in control by you. (granted, it's a low-possibility occurrence, but when you are thinking of security, a walled approach (many defenses)) is a better approach. If you are distributing this app to anyone besides yourself, For offline apps, you'd only have to worry about a trojan or malware affecting your computer in such a way to exploit the prototype pollution but at this point your computer is likely hosed anyway. Setting contextIsolation should likely not affect community-electron libraries you are using (but there may be exceptions). sandboxIf you really want to be secure, you should set SummaryIn general, straying from the recommended values of For any app that you intend to distribute to others, I would strongly recommend not straying for the defaults (and especially work towards setting @petef19 did I answer your question or do you need additional detail? |
@reZach
this is typo, I think you meant "to true" (1st sentence under nodeIntegration section)
could you elaborate on specific use case scenarios what you mean by "get into the app" ?
b/c if you enable
that is one use case scenario for sure, question is what chance is higher: IMO, what we've seen since the 80's in app hacking, (2) is way more likely - could be wrong. In our specific case, we do NOT load any 3rd party content in the view. The view does not communicate w/ outside world at all. The main process (if the user is online) receives
w/ sandbox set to true, you can NOT bytenode encode the preload file anymore (as see... no matter how one turns this: this is the problem w/ Electron and the team not recognizing this, you are exposed either way. Their recommendation leaves you exposed, unless your app is online only (which is what they seem to push). Conversations about this have been shut down w/ absolute non-sense bogus arguments. A built-in encryption protection option like |
@petef19 Thanks - I've updated that typo. I will preface this and say that I'm not a pen-tester, nor that I'm a security researcher, I've just tried to compile resources from those that are more knowledgeable than I. I will do my best to reply to your concerns. ContextIsolation true would more err on the side of users playing around with your app rather than loading external 3rd party content. I found an example of someone using a method that would have been prevented if ContextIsolation were turned on. Interesting, I have not explored bytecoding encoding the source files of my app with as much time as you appear to have. By I mean, you can of course disable ContextIsolation for offline only apps or apps that load secure content. With it disabled, prototype pollution attacks can happen, but if it's more important to encrypt the source code, then I feel that's a decision you have to weigh for yourself. Yes, I feel your reply about the DNS takeover shouldn't really be an issue for your app, granted you are encrypting and verifying [in the app]. Gotcha, so I feel you are using or building this app for a business or for other users. In that case the fear of leaking the source code would be more detrimental than protecting against prototype pollution attacks. I think I understand your use case a bit more. Yeah, I'd be interested to know what you are trying to encode your source files with and why that doesn't keep |
w/ Encoding files for protection or obfuscation is definitely important, to protect IP and/or the user itself (remember: a hacker can easily modify your unprotected app and re-distribute it w/ malware that compromises the user). Unfortunately For anybody that release commercial apps, but also anybody who simply does not want to openly share the src code, this is a huge problem. So, for folks that do is the extra security I gain using |
Thanks for your explanation, @petef19. With
In my opinion, I feel malicious users would choose to exploit the fact that contextIsolation is off before trying to decompile your app. But due to the fact that you say your content is encrypted and then evaluated, I think its more secure that your use of |
the
this is the same conclusion we came to (for our specific use case). But in the other thread, and another dedicated one before that, it was all dismissed and it was hammered over and over that you need ok, thanks for taking the time and chiming in, much appreciated. Always good to have another mind think through a specific use case. And if anybody else wants to chime in, please do ! Def open to hear anybody else solution to how you protect your code in Thanks ! |
@petef19 can you help me understand this?
Isn't it the case that But otherwise yes, I agree that it doesn't seem important/high enough priority right now for the Electron team to tackle the fact that anyone can simply decompile your app and view the source code. |
Closing for now, @petef19 feel free to get in touch if you want to re-open this conversation! |
@reZach How about the case where you are writing a front end for a nodejs script that is normally run from the command line? In this case, it seems pointless to add any security measures as the whole point of the script was to directly access nodejs functionality, and the whole point of using Electron would be to create a nicer interface to the existing functionality. It seems like having to create a whole API would be a lot of extra unnecessary work as opposed to just dropping the existing code in. Am I missing something here? |
@michael-ts I would still recommend executing the script on the backend of the Electron app, if nothing else as it allows for extensibility if you decide to distribute it to others in the future, besides adhering to the frameworks current best-practices. However if what I'm reading between the lines here is that it's a tool for yourself as a QoL improvement, you would probably be fine dropping your script in an Electron app. |
@reZach
as per my original post, and you were nice enough to offer insights, I would love to get clarification and your thoughts on the following.
Since Electron currently does NOT implement any security mechanism to protect the src code, it would be helpful for devs to get an explanation what security implications they are facing when changing certain recommended Electron settings.
Types of apps would include:
(1) online only app (e.g. Slack)
(2) app that connects to remote sources, but NOT to 3rd party sources, hence the app ONLY loads verified/validated content
(3) offline only app (only loads local content)
Specifically, why is the
contextIsolation
setting "helpful" and/or "needed" for apps (2) and (3) ?Thanks !
The text was updated successfully, but these errors were encountered: