Security thoughts

This page contains random musings about security considerations for Querki

Javascript Security

In LiveJournal, I asked for thoughts about Javascript in Apps. That produced a lot of good input, and several points to think about.

The main issue here is, do I allow Apps to contain arbitrary HTML and CSS -- and thus, Javascript? For that matter, some Apps could be much more powerful with a little Javascript, so do we want to permit that?

Querki should not require Javascript

This is an important point that I am apt to forget: while I like to make my UI clever and pretty, some people are dead-set against Javascript. Therefore, it should be possible to do all important things in Querki without it, so that folks with noscript can still work reasonably well.

Flag Javascript Explicitly

A number of my security-conscious friends would be much happier knowing that an App contains Javascript before making use of it. dsr suggested that we have a "Yes, this contains Javascript" flag that must be explicitly set -- he suggested it per-edit, but I think it's more appropriate per-Space. Either the Space allows JS or it doesn't. Indeed, we might even make that stronger, and require a positive "Allow arbitrary HTML" flag if you want that; without that, we would simply convert all the dangerous symbols.

Furthermore, kihou points out the danger of cut-and-paste -- naive users might copy Javascript into their space unwittingly. So a Big Red Button that you must explicitly push, and otherwise we make a best-effort to strip out the script, looks like a reasonably pragmatic compromise.

Possibly even better: you have to explicitly turn HTML/Javascript on in any Property that uses it. That way, we can do fairly heavy-handed stripping of suspect characters (ie, angle brackets) otherwise. This also makes it a bit trickier for child Spaces to inject illicit Javascript in publicly-visible places.

Strip dangerous user data

Ilaine points out that the biggest risk is from third parties -- not so much the App's author, but malicious users who are sticking illicit stuff into data. That's a very good point, and a tricky one: since page source is simply data, we have to be very careful to reason properly about what to strip.

By and large, though, it seems like the rule should be that any time a field is exposed outside of its own Space, it should be angle-bracket-stripped. When rendering a Thing inside its own subdomain, fields may contain HTML and Javascript if they are so marked. In all other circumstances, especially all public listings, emails, notifications, etc, we will strip it.