Let’s do this the hard way by Edd Dumbill.
Discovery of high profile security vulnerabilities (Rails, MongoDB) caused Edd to pen this suggestion for software security:
But perhaps we are in need of an inversion of philosophy. Where Internet programming is concerned, everyone is quick to quote Postel’s law: “Be conservative in what you do, be liberal in what you accept from others.”
The fact of it is that being liberal in what you accept is really hard. You basically have two options: look carefully for only the information you need, which I think is the spirit of Postel’s law, or implement something powerful that will take care of many use cases. This latter strategy, though seemingly quicker and more future-proof, is what often leads to bugs and security holes, as unintended applications of powerful parsers manifest themselves.
My conclusion is this: use whatever language makes sense, but be systematically paranoid. Be liberal in what you accept, but conservative about what you believe.
Which raises the little noticed question of topic map security.
Take for instance, if you are using the TMDM model for a topic map and someone submits the topic map equivalent of “spam.” That is a topic that has the same subject identifier as some legitimate topic in your map but it is an ad to get you into “bikini shape.”
My inbox has seen a rash of those lately. I shudder to think what I would look like in “bikini shape.” It would be good for others, not so much for me. 😉
Or a topic that has a set of subject identifiers that causes merging between topics that should not be merged. Possibly overloading your system or at the very least, causing a disruption to your users.
There are no standard solutions to topic map security although I suspect some users/vendors have hand crafted their own.
To be taken seriously in these security conscious times, I think we need to extend the topic maps standard to provide for topic map security.
Suggestions and proposals welcome!
How about the technique Wandora already uses with Topic Maps: Layers.
That way the user generated topics could still merge but they could be easily removed if they cause a problem. Or merging with the user layer topics could be restricted by rules.
With the ability to exchange Topic Map Fragments and no restrictions on the number of subject indicators and subject locators that a topic can have, sooner or later someone will create and share a universe/virus/spam/god/zen/ topic (depending on your orientation) that will merge with many of the things it touches.
Comment by clemp — March 28, 2013 @ 5:30 pm
Good point about Wandora! Speaking of software I need to write more about.
I also like your point about the number of subject indicators/locators a topic can have. Some restriction there would be fairly effective at stopping crude hacks.
I haven’t fleshed it out yet but the thought also occurs to me that a topic could have an anti-merging property. One that if set, prevents merging. Or requires an additional property, say an authentication token property in order for a merge to occur.
Comment by Patrick Durusau — March 28, 2013 @ 6:23 pm
Authentication can be looked at as a run-time validation. Maybe TMCL could be co-opted into supporting authentication and related topics instead of just schema based validation.
If topic A is associated with a topic of type X then these associations are allowed. Otherwise, only these associations are allowed
Comment by clemp — March 29, 2013 @ 6:38 pm