store.js icon indicating copy to clipboard operation
store.js copied to clipboard

there is no Issues just question about security!!!

Open karencho777 opened this issue 5 years ago • 7 comments

Hello, can you please tell me with help of Store.js is there possible to store files like .exe or other executable files and then execute them? or js script and then execute it? it is very scary if it does, anyone can hack you? thank you

karencho777 avatar Apr 07 '19 05:04 karencho777

so no one can answer?

karencho777 avatar Apr 07 '19 20:04 karencho777

Browsers can't execute EXE files due to security concerns, so storing a file in state won't work since JS is client-side, it's quite impossible to execute a file or anything that can interact with the core OS (the container would be the browser who won't allow the interaction), and those hacks you've more than likely seen doesn't include malicious code execution from the browser itself, but normally exploits a vulnerability that allows them to use something else to execute their code remotely. This is the reason why Flash was discontinued as the vulnerabilities exploited within Flash components allowed to interact with the core OS, which allowed them to execute code within/through the Flash that was loaded on the site.

AcidRaZor avatar Apr 25 '19 08:04 AcidRaZor

I just read about how they can store encoded code to local storage and then call out it... so if the stored code is in local storage when it will be executed from there will be interact with OS? and now can they store files with Flash?

karencho777 avatar Apr 28 '19 19:04 karencho777

Please share where you found this information?

Local storage cannot interact with the core OS and store.js doesn't use local storage, it uses state which is wiped every time you navigate off the website.

Browsers are "containerized" meaning each tab is in it's own isolated session, so can't interact with other browsers even. There's a LOT of security when it comes to the web.

Local storage is also isolated PER DOMAIN. So an attacker that wants to read sensitive information stored in local storage and send it to his own server (username/password or even credit card credentials or even try to embed encoded code) needs to first exploit your site through cross-site scripting attacks to test for vulnerabilities in your setup to inject their own JavaScript code in your website.

Even if they get that right, the only access they have is within the containerized environment of the browser and can only read the information, they cannot execute an exe that is stringified and embedded there either.

So if your site security sucks, then yes, they can store encoded code on local storage, but again, they're isolated from the OS.

Here's an article going over everything in detail: https://dev.to/rdegges/please-stop-using-local-storage-1i04

Also see the following answer if you don't believe me: https://security.stackexchange.com/a/95068

AcidRaZor avatar May 03 '19 10:05 AcidRaZor

@AcidRaZor Thanks for your explanations. Can we somehow mark this issue as finished to improve Issue count? I don't have rights to close the issue, but i've seen that storeJS did not have any updates for 2 years on npm, so this looks like not very actively maintained currently.

bjesuiter avatar Jul 09 '19 15:07 bjesuiter

@marcuswestin This issue can be closed.

Maybe the Readme should be extended by a part about security in Localstorage, so that users understand the implications.

I can recommend to link to this article for that: https://www.rdegges.com/2018/please-stop-using-local-storage/

Maybe I'll add a PR Later to add this to the Readme.

bjesuiter avatar Jul 09 '19 15:07 bjesuiter

I wish people would stop using that article. Its mostly wrong. And doesn't address how to store things like JWT and other tokens (no, cookies is not a valid answer as XHR requests don't normally use cookies and JWT needs to be set in the header)

eddiemonge avatar Aug 15 '19 02:08 eddiemonge