Content Security Policy
- This is kind of a big deal. Electron runs node. Node can access the file system. Micro.blog is directly displaying remote user web content. Left to its own devices that means that someone could potential sneak in some content that runs a script that alters the filesystem… and pwn3d as the kids used to say! Hacker anachronistic jokes aside: yikes.
- There are lots of barriers in place for this in micro.blog to only allow nice content. @manton has clearly done his homework. But it would be lazy of me to rely on that never failing.
- Chrome and thus electron now have support for the standard “content security policy” — which sounds like legalese, but is actually a cool tech thing. We can set this either via headers, via pre-load script, but the way that is most difficult to work around is via a meta tag in the page itself.
- So I’ve disabled all remote EVERYTHING except images. Scripts, fonts, and styles are only allowed if local and styles are never allowed to be inlined. This prevents a lot of old-school data inlining shenanigans.
- This only leaves one last hole to plug: eval. The JS eval function is super powered. It can potentially write new local functions that can replace existing ones and … pwn3d again! So we need to disable that by setting the default src to ‘none’ and script-src to ‘self’
Handlebars and eval
- Lots of templating systems like Handlebars and Jade run template content through eval to create a JS function for the template. This function is much faster than parsing the template on each render. And compiling the template into the JS function only needs to happen once. However to create a new JS function we need to use
evalwhich — as I just mentioned — means total pwn3age!
- Fortunately we can precompile the handlebars templates. I mentioned this briefly in my last post — but without any detail as to why. With this out of the way I can disable unsafe-eval.
- The downside of precompiling is it makes compiling/running the app take a bit longer. I should probably build in a dev-mode switch into the templating. Someday.
- I figured I could blog about Content Security Policy without giving away too many details. I’ll be doing more to try to keep user-content far away from any node functionality — but I play the other cards close to my chest.
Main Menu Routing
OK, switching gears away from security — I also worked on getting some of the “routing” working. Although routing can be used for a lot of things, I like to think of it as just web-dev speak for the over-arching app-delegate event system.
* I’d love to have an AppKit style responder chain for dealing with events, but that’s not really a thing outside of cocoa.
* I’m trying to go with the flow and make event handling follow the web way. So I pass these events directly to the router to handle and the router dispatches them to the appropriate timeline. It’s a bit more explicit than a responder chain, but this is a simple app, so no big deal. If this were something like Stacks with a hierarchical object tree I’d fret over this bit a lot more. * The work is pretty much done — the dispatch at least. Although a lot of the functions are just scaffolding right now — I don’t really have post/reply/quote sort of functionality right now at all.
Sorry, another day without a fun gif. Partly that’s because I’m layed up in bed a lot this week – but I’m on the mend, so I’ll try to have some fun UI pictures for next time.
What is this: these are random snippets from my dev journal working on a simple client app for fun. This is a non-serious side project, progresses very slowly, and will probably never see the light of day. The images may not perfectly correspond to the journal entry. In most cases I’ve added them later based on the relative time of git checkins.