So I've been grinding away on a database implementation for a few days now, and today passed a milestone peculiar to database geeks. That's the one where the number of data tables is surpassed by the number of functions (and stored procedures) written to read, update, and delete that data.
It's the point where I start to feel safe--as safe as you can be allowed to feel, anyway--what with data hanging out on a web server. Once, I thought of that "safe"(r) feeling as mere superstition. And, to a degree it is. Just like any situation where you go all-in on one factor.
In short, this flavour of coding is kind of thing logicians call "a necessary but not sufficient condition" for a reasonably safe application. A lot of different skills and roles play into that. And, even getting all the technical stuff right means bupkis if the human factor fails. ("Hi, this is the County Password Inspector calling. We need to verify that your password is strong enough..." [insert involuntary twitch])
That being said, there's no excuse for not doing it. Or for not automatically distrusting every bit of data that wants to be written to your database.
Thing is, writing database code is just repetitive enough to be boring, but just
quirky enough in its logic that I don't automate the process beyond
cut-paste-edit. And once that code is in place as the "gatekeeper" between the main application (web, desktop, API), the main application's code similarly walks the line between "boring" and "can't afford to mail this in."
Worse, it's slow business. And not simply because so much is being written from scratch instead of copied and adapted. This is also when the nitty-gritties that fell through the cracks of the design documents have to be fleshed out. Even when the developers were part of the design team, this means round-tripping back with the major stakeholders. Which means they're in meetings rather than coding. And I can pretty much guarantee you several "Uh-ohs" occasionally punctuated by the more serious "Oooooops."
Which is why it can seem frustrating to the (non-coder) manager that resolving questions last week spawned even more questions this week. That means your developers will spend even more time in meetings and less time doing what they're nominally paid to do. And as a developer watching the original milestones loom (and possibly slip), it can be awfully tempting to take the short-cuts. By which I mean querying, and (far, far worse) updating and deleting data directly in the web code.
Now, I don't have any proof whatsoever, but I would not be in the least bit surprised to learn that those sorts of shortcuts were behind last month's VTech hack. Because the smoking gun that left the information of 6.4 million children and adults exposed was a SQL injection hack. "What's a 'SQL injection hack'?" a non-coder might ask. I'll let "explain xkcd" well, explain it, because A.) He does it better that I did, and B.) Talking about SQL injection and not linking to the iconic xkcd comic (which I really need to get on a t-shirt) is like going to RenFest and not making a single "Holy Grail" joke. It just isn't done, mes amis.
Like I said, zero proof of my hypothesis. Whichever way, though, that's bush-league work. Let that sink in for a second: I'm a freelance coder working out in the wilds of Grande-Digue, New Brunswick, and even I roll my eyes at that kind of sloppy naiveté. Because SQL injection isn't half so much a technical problem as it is a human one. And, honestly, if you have millions of customers, you can afford to hire solid, experienced, disciplined programmers, and let them do their jobs. Which involves indulging the twitchy spider-senses developed from years of painful mistakes. Normally, you'll only find that level of paranoia in ammosexuals and StormTrumpers. But programmer twitchiness the sanest and most rational paranoia you'll ever encounter. Trust it.
