Ah ok, I see. @Krishna would it be fine to add localhost to the csp rules? Is it also possible to add file:// so we can run it without local server?
I’d vote against that – at least for production usage. It is quite a security whole to allow localhost things. I’d very much like to have either a toggle for this in the App or (which I prefer:) have minimal proxy-setup which alters the CSP rules for development only. This proxy could/would then also act as a file-server serving the app in development…
1 Like
I don’t really mind how it would be done but it would be very useful to have. Changing the CSP rules to allow it is easy to do and we could have it now. Maybe change the rules for now and later on change it for something else when times allow it. What is the security issue you have with allowing localhost?
For rare occasions when this is needed you might as well just clone safe_launcher and run in dev mode as in the OP. I don’t like the idea of opening up security holes to everyone running a local server - so it should at least be opt-in, and this achieves that.
EDIT: And if you want to keep the CSP and just allow localhost, you can edit your copy of safe_launcher/server/web_proxy.js
But is that really the best answer for all the new devs that will come flocking here to try their hand at the API, clone and modify the launcher? A switch for dev mode in the launcher would work. Meanwhile a change to the rules would do the trick.
Either way I still don’t understand why this is a security hole (not saying it isn’t). You need an authorization token to do anything and for this the user needs to explicitly authorize it. Your local server might become compromised and send authorization request but the user always need to accept it.
I understand there are ways around it but I also understand every single dev starting with the SAFE API will get stuck by this. It doesn’t make for a friendly dev environment and it’s especially bad if this compromise is more based on fear then on facts.
Anywyay, my two cents on the subject.
Or. If you are using webpack (and their dev-server) you can transparent-proxy /0.5 through to the launcher and all is good (as ‘self’ is listed), like so. Then you can run it against local development or even live safenet…
This is much better and emulates the final behavior of the network closest.
Would there be interest in us providing a minimal proxy-ing webpack setup for people to start their development with?
2 Likes
The problem isn’t on this side, but the other way round. There was a lengthy discussion, which lead to the CSP rules in the first place. I recommend to read up on that, but the gist is: Allowing any not *.safenet domain means potential leakage of information – like tracking tools and alike. And although the potential problem with localhost itself is small (like, the tracker would need to have either installed something on the computer or somehow route it through localhost), I’d consider whitelisting it bad practice – especially as it is only about development convenience. This is where security bugs come from: developer convenience (or why do you think all router have a super simple default password).
We should not compromise on this, considering there are clean and easy ways (as shown right before) to provide a smooth development experience without touching the good integrity of the CSP rules.
1 Like
Fair enough, I don’t really mind how it’s done, but I think it would be good to keep the amount of hoop someone needs to go through to start coding as little as possible.
And it should be done quickly, with the new API coming up and the tutorials on their way we need this ASAP.
2 Likes
I whole heartily agree!
1 Like
Under Windows 10 IE11 en Edge can’t be bothered to prevent access when doing it this way:
<!-- https://crypto.stanford.edu/cs155/lectures/11-workers-sandbox-csp.pdf -->
<!DOCTYPE html>
<html>
<head>
<title>Simple Safe API example</title>
</head>
<body>
<iframe sandbox="allow-same-origin allow-scripts allow-popups allow-forms"
src="http://localhost/simple_safe/simple_safe.html"
style="border:0; height:300px; width:100%;">
</iframe>
</body>
</html>
This is “index.html”, opening it from a local webserver loads “simple_safe.html” containing @DavidMtl’s code and localhost:8100 as endpoint.
Also works from “simple_safe.html” opened as a local file if you remove his ‘localstorage’ lines.
FF and Chrome do complain. As the MS twin set should but does not.
1 Like
IE doesn’t understand default CSP (unless you do the deprecated prefix, wondering if we might want to provide that) and Edge only from version 12 – see https://content-security-policy.com/ – which version are you running?
But even then Edge only supports CSP-1.0 and the child-src (which should prevent this here) is only part of CSP-2.0 (I refer to the URL from before). I suppose we should also add the already deprecated frame-src 'self'. I’m wondering though why the default-src doesn’t catch it here.
Is there any way you, @JBishop, can confirm it blocks with that tag added?
2 Likes
Added:
Header add Content-Security-Policy "default-src 'self'"
Stopped and started the server and indeed, blocked:
CSP14312: Resource violated directive 'default-src 'self'' in Content-Security-Policy: http://localhost:8100/auth. Resource will be blocked.
Took that CSP line out again, stopped and started and was allowed to approach Safe Launcher again. This was in Edge 14 (Microsoft Edge 38.14393.0.0)
Odd, default-src 'self' is already in the proxy.
Just to clarify, the setup is: you are hosting a file (the one you posted), which has an iframe to a file hosted on safenet/served through the safenet proxy?
Wait. That doesn’t appear to be the case though. Only that second file (from within the iframe) is then going through the launcher, am I correct? Well in that case, that’s the first place the CSP is currently returned and thus the other pages before aren’t protected by it. It’s rather odd that FF and Chrome block here, they shouldn’t.
But that isn’t realistic conditions: on safenetwork also your initial html and the iframed-html page would be served with CSP headers, thus eliminating the problem you are talking about. This only happens in the specific development setup you are having at the moment.
Either way, I feel even stronger about streamlining this now. The pages of your local system should be served with the same CSP-headers to create realistic conditions and avoid finding out about problems like these only after you deployed.
I agree, but also with the option to turn CSP off with a debug setting, not something directed at everyday users (like the difficult to access CORS control variable in Firefox etc.)
I’m now trying to locally run a safe web app and I’m running into this issue with launcher v0.10.0.
I tried with a local launcher as well, with “npm run dev” but it still doesn’t work. Is there a way to overcome this with the launcher? or what are my options?
I’m using safe-js, and either with or without the polyfill I see the same result.
1 Like
CSP is disabled on latest launchers, because there is no proxy anymore.
I think there might be a different problem, but it gets exposed as an “CSP” problem - dunno why, but the browser does that sometimes. Take a close look to the actual error message in the object in the console and the http request.
Just to check: have you “disabled web security on new tabs” and opened a new tab?
If not that would cause this.
EDIT: Oh, you’ll need to be running a local Beaker too, with NODE_ENV=devel or you won’t get that menu option!
2 Likes
Thanks a lot @ben and @happybeing!
It worked after “disabling the web security for new tabs” as suggested by @happybeing (I’m sorry I wasn’t aware of this option 
). Although, I was able to do it with an AppImage of Beaker (v0.4.0-5).
4 Likes
Although, I was able to do it with an AppImage of Beaker (v0.4.0-5).
That sounds like a bug! @joshuef?
Huh? I’m confused… It works or?
If not, please try with the latest version (0.4.2 stable) Releases · joshuef/beaker · GitHub , dev mode with NODE_ENV=development as @happybeing noted.
Let me know how you get on!
1 Like