-
Notifications
You must be signed in to change notification settings - Fork 11
Security thoughts
This page contains random musings about security considerations for Querki
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?
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.
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.
Indeed, we might be even stricter -- the Allow HTML flag might be metadata on the Value. That is, you can have unstripped HTML if and only if the Space, the Property and the Value all explicitly request it, and it only render unstripped in the same Space where it is declared. That's draconian (and a mild hassle), but may be the right answer.
Actually, no -- that's both overkill, hassle, and doesn't solve the problem properly. Instead, the allowHtml flag is in direct contention with the publiclyEditable field. That is, if this field is visible in public data-entry forms (that can be accessed by anyone other than the Space's managers), it is not permitted to have allowHtml set, because we do not want to allow arbitrary people to include HTML. This seems like an appropriate policy: only the Space's managers may edit values that potentially contain HTML.
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.
Ilaine also pointed out the danger of clickjacking. Pretty much separate from the Javascript question, I should think about embedding a framekiller by default.
One of the most dangerous problems is that Javascript in a subdomain can steal the top-level domain's cookies. So basically, it makes login security awfully dangerous.
The long-term approach may have to be that, if you want to use HTML you have to request it specifically. If so, we will wrap it in Google Caja to sanitize that HTML appropriately. That is probably the necessary approach: leverage the work done in the larger community to deal with this problem. (See also the developer's guide for more Caja information.)