There’s a lot of talk these days about cloud security. The usual, sensible, and frankly right answer is, don’t be silly. With the right combination of VLANs firewalls, proper machine isolation in the hypervisor, and all the normal sort of things you should be doing with a server anyway (hardening, patching, and those other things sysadmins like spending their evenings and weekends on)… yeah, all that stuff. We’re covered (well, close enough)
But…
There’s a whole bunch of new vendors springing up every five seconds, trying to sell new, or port old, systems management, help desk, monitoring and whatever else tools to the new smaller private cloud vendors. A lot of them are shiny, they’re all lovely, and many many of them haven’t the slightest idea how to maintain web security. I recently discovered (with a quick look at the page source, and some playing around) that one such white-labelled, make-it-easier-for-the-help-desk system was a litany of everything you can get wrong with web security.
Some hints:
Don’t store an admin user’s password in plain text in a cookie. Especially not when you’re more than happy to send that cookie back and forth a few thousand times a day over unencrypted http.
Client state is not where you keep security. Clients should be aware of security. This is a UX thing, ie, if the user doesn’t have the permission, they shouldn’t see / be able to push the button (unless you’re trying to upsell the function to them, or something of the sort, but that’s a whole other debate). Permissions need to be enforced on the server.
Permissions do not just apply to pages / actions / end-points. Always check the permissions on the parameters, the filters you’re applying to aggregated data etc. This is particularly relevant if you want to sell a multi-tenant system. Ideally there should be full separation of per-tenant databases, with proper database level permissions. Hey, I know not every junior web dev has this sort of thing at front of mind, and it’s real tempting to just assume you can get away with a few where clauses, and a single jndi reference for your data source (the unnamed victim of this rant looked like a cobbled together bunch of technical debt denominated in struts)… but at least make sure you consistently apply your where clause (try aspects if you’re worried about the junior guys forgetting). I really should not know as much about my cloud provider’s other customers as I now do.
Web development rules still apply when you’re making ‘intranets’. Clean, valid HTML, unobtrusive javascript, missing links, not using the mouseover attribute in anchor tags, clear, concise javascript which has at some point been aware of the concept of architecture. It’s all good stuff. Do it, even if your audience is a select group of highly technical IT managers and CTOs. We’re sometimes users too, and don’t want to have to break out the Greasemonkey just to make the tool work.
</rant>
