After going through the code for #1712 I noticed that rambox employs a handful of worst practices when it comes to webapp security. I was going to dig into them and contact the owner but after seeing someone has already reported the problem in https://github.com/saenzramiro/rambox/issues/1044 it isn't worth the effort.
What it comes down to is that electron apps can be configured to be relatively secure but by default they're basically giving system level access to any javascript embedded within the app. On top of that rambox goes a step further by lowering the already weak security configuration so that you don't have to write proper access controls.
These lines are the biggest problem: https://github.com/saenzramiro/rambox/blob/3a4c89bd65c23284640d3f098c0b449f96ab6075/electron/main.js#L160-L161
And:
https://github.com/saenzramiro/rambox/blob/master/app/ux/WebView.js#L177-L178
Even the electron security tutorial highlight specifically that these things should never be done.
:warning: Under no circumstances should you load and execute remote code with
Node.js integration enabled. Instead, use only local files (packaged together
with your application) to execute Node.js code. To display remote content, use
the<webview>tag and make sure to disable thenodeIntegration
I see the issue has been assigned so I guess someone will start working on it? Wanted to add that before writing any code attempting to fix the issue work out a plan on what to fix. By using a lax security configuration in favor of rapid development there's been a huge build up of technical debt. Enabling webSecurity and disabling nodeIntegrations means breaking many services and probably stuff you didn't even think would break.
If one or more people are serious about fixing these security issues I'd be happy to take a serious look at the code and provide some more in depth feedback.
Edit: Another good starting point would be thanking the people like @TheGoddessInari and @greenred123 who were so kind to a code review (#1044) and resolve over 85 known security vulnerabilities (#1706 / PR still open.. )
Comments left on this repo have got me encouraged to maintain things working and up to date downstream until this upstream repo is maintained again. I hate JS, but will accept PRs for the time being. Working on getting my local changes fixed and up to date, will focus on it more by Wednesday.
I was just about to donate, then checked through the issues mentioned here. I think I'll donate when this has been addressed because it's not just dangerous, it's also invasive (tracking on by default).
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
I see the issue has been assigned so I guess someone will start working on it? Wanted to add that before writing any code attempting to fix the issue work out a plan on what to fix. By using a lax security configuration in favor of rapid development there's been a huge build up of technical debt. Enabling webSecurity and disabling nodeIntegrations means breaking many services and probably stuff you didn't even think would break.
If one or more people are serious about fixing these security issues I'd be happy to take a serious look at the code and provide some more in depth feedback.
Edit: Another good starting point would be thanking the people like @TheGoddessInari and @greenred123 who were so kind to a code review (#1044) and resolve over 85 known security vulnerabilities (#1706 / PR still open.. )