Javascript security

[conceivable]

Browsers are known to have a big attack surface around JavaScript, often leading to user tracking (loss of anonymity), cookie hijacking and even remote code execution. Projects like the Tor Browser disable js by default for this reason.
Executing js from anonymous websites presents much higher risk than traditional well known sites.

Can you please clarify how ZeroNet handle the security of js? Thanks

[HelloZeroNet]

The problem is if you want dynamic sites, then have to deploy and run the site logic in some way.
It could be possible to write a non-javascript cilent in python/java/php/etc, but javascript offers the best and most battle tested sandboxing enviroment.

[MuxZeroNet]

Static websites

It is perfectly fine to create static ZeroNet sites that work without JavaScript. Static site generators work very well in this case.

Dynamic websites

There is no backend. Computation, if necessary, must be done on the client side. We use JavaScript (browser side) and ZeroFrame APIs (restricted Python side computation) to make dynamic sites. It is impossible to display dynamic content while keeping things decentralized without running some algorithms on the client side to handle dynamic data.

Attack vector

Yes, JavaScript is a major attack vector. There is no extra protection except a sandbox iframe. Seriously, you should run ZeroNet in a virtual machine or in Whonix.

There are a few people asking us to implement PHP support. Keep in mind that "backend" code written by someone else will be executed on your computer. ZeroNet does not and will not support Flask, PHP, Node.js etc. that allows one to run totally unsandboxed code on your computer.

[anoadragon453]

Perhaps there could be an 'Execute Javascript on this site' toggle in the slide-over menu, and the user can choose whether this setting is on or off by default for all sites.

Of course Javascript will by default be globally on for the best user experience.

[conceivable]

"you should run ZeroNet in a virtual machine or in Whonix" - perhaps this should be written on the homepage or in the install instructions.

How does the Same-origin policy ties into serving content-addressed sites from localhost? Is it being circumvented?

[HelloZeroNet]

ZeroNet running content in sandboxed iframe that allows the content to be treated as being from the same origin.
https://www.w3schools.com/tags/att_iframe_sandbox.asp

[MuxZeroNet]

Hello! Even though dynamic websites do not work without Javascript, there are a lot of static HTML websites on ZeroNet. I would like to see those static websites load when I have Javascript disabled globally. I have a few wishes. o I hope the No Javascript warning could be dismissed. There is a CSS checkbox trick to accomplish this. o I would like to see the inner iframe load without Javascript. Despite awkward, a page is at least readable without Javascript. Is there a particular reason why the src attribute of the inner iframe is assigned by Javascript code? o I hope the developers could adopt [CSP script nonce] and [CSP script hash] to restrict inline Javascript, [harden] the sandbox and mitigate XSS attacks. o I hope the developers could encourage the use of a SSH tunnel for remote access, instead of telling people to bind the Web UI to the whole Internet. This allows CSP to work. o If you probe the port ~~15441~~ 43110, you will always find some misconfigured clients opening their ports to the whole Internet. This is another reason to encourage the use of SSH tunnels. [script nonce] "Define script execution by requiring the presence of the specified nonce on script elements" https://www.w3.org/TR/CSP2/#script-src-the-nonce-attribute https://content-security-policy.com

[HelloZeroNet]

Is there a particular reason why the src attribute of the inner iframe is assigned by Javascript code?

Without it the back button does not works, because the browser restores the old iframe url (at least in chrome) with expired nonce even if the wrapper html reloaded due no-cache header.

My ideas on JS-less mode:
Add support for /raw/siteaddress/any.html where the files are served without wrapper, but disabled js using Content Security Policy

Adding SSH tunnel to documentation would be a good idea and we could also enable the UiPassword plugin by default if someone start it with --ui_ip "*"

[MuxZeroNet]

disabled js using Content Security Policy

Using the HTML/iframe sandbox to disable JS is a good idea.

[HelloZeroNet]

• Should we use keep the wrapper and use iframe sandbox argument to disallow JS or use Content Security Policy headers and render it without wrapper?
• Should we check and care about browsers that does not support Content Security Policy? (IE9)

[HelloZeroNet]

It's landed in Rev2137 (with some fixes in 2141 & 2144) using the /raw/ prefix. Eg.: http://127.0.0.1:43110/raw/1AsRLpuRxr3pb9p3TKoMXPSWHzh6i7fMGi/en.tar.gz/index.html

It will serve the files without any wrapper, but adding Content-Security-Policy: default-src 'none'; sandbox allow-top-navigation; img-src 'self'; font-src 'self'; media-src 'self'; style-src 'self' 'unsafe-inline'; header.