Previous Entry Share Next Entry
QL inside CSS?
jducoeur wrote in querki_project
Huh. I was just thinking about CSS inside of Querki, and the trend towards using LESS instead of raw CSS. I don't really want to do that -- it's a lot of extra overhead to compile, isn't like anything else in the system, and will probably only be used occasionally.

But it just occurred to me: what about putting QL expressions inside of CSS? That is, you might be able to consider Querki's CSS stylesheets to be dynamic in exactly the same way as ordinary Text fields -- basically templates that you can stick arbitrary QL expressions in. Still has some efficiency concerns, but at least they are the *same* efficiency concerns we already have and need to deal with. (And the parser is optimized so that, if there are no "[["'s in the expression, it should be quite fast.) It's consistent with the rest of the system, and would allow you to define your CSS in terms of exactly the same Properties, with the same Methods, that you use for the page content.

That's quite neat conceptually, and likely *extremely* easy and quick for me to implement. It only works for "static" server-side CSS, not stuff that's changing on the client, but that's how LESS is mostly used. (Although if we go this route, I suspect there will be a demand for Thing-wide "variables", that work across multiple QL expressions, to define something in one place and use it everywhere else. Interesting -- I wonder if we'll get demand for those on normal Thing Text?)

That said, it's currently a Feature in search of a Use Case, and nothing is allowed to be implemented without a clear, real Use Case to motivate it. So y'all stick it in the back of your minds, and if you think of them, please toss out examples where you might want to use this in real Spaces. I'd be quite happy to have some good reasons to implement this one at some point.

(I do have one example offhand, although it's a small one: this would be a super-easy way to implement a bar-chart display of Ratings, the way you often seen in the Google App Store and the like.)
Tags: ,

  • 1
FYI, allowing Javascript inside of CSS turns out to be a weird but powerful cross-site scripting malware attack vector. See Rule #4 of

What are you doing to secure the system?

FYI, allowing Javascript inside of CSS turns out to be a weird but powerful cross-site scripting malware attack vector.

Already long since known. While it hasn't been coded yet, "disallow Javascript inside CSS" is on the near-term to-do list. Remember, I've been doing browser software for *many* years -- longer than anyone else I know -- and first encountered this particular issue almost ten years ago. I'm often the one who points this quirk out to folks who are building sites.

The thing is, though, this enhancement doesn't change that. Querki *already* allows you to have CSS for your Thing/Space. Indeed, that was one of the first features added, since I needed it for the wedding invitations. So it's already necessary to scrub that CSS properly.

That being the case, the only change here is that the scrubbing needs to occur after the QL expressions are expanded. Which is precisely the same way that the HTML scrubbing already occurs for text fields, so there's a nice symmetry to it. (Indeed, now that you bring it up, it's tempting for me to just enable this feature now, to remind me why scrubbing needs to happen at output time rather than input time.)

All that said, Rule #4 is the best summary of the problem that I've come across, and worth my while as a reference. Added to my bookmarks, and to this enhancement's description -- thanks! I really should take another wander through the OWASP pages: it's been a while.

At the moment, Querki is largely immune to XSS simply because it crudely stomps on the key HTML characters, but I'll have to keep an eye on this if I begin to ease off on that. I'm generally proceeding from a "start paranoid, and ease from there" standpoint. Currently, all XML is stomped. I am *thinking* of allowing limited HTML, but that's going to be strictly whitelisted for the foreseeable future -- not just whitelisting the tags, but fully parsing and validating the attributes of those tags. Done properly, that should avoid most of the common XSS attacks. But I've added that page as a helpful checklist.

  • 1

Log in

No account? Create an account