In today's environment, you can layout a domain and with a few keystrokes magically have persistence to a database taken care of. In some languages and frameworks, you don't even have to create the schema it persists to. A few more keystrokes and you can have a rudimentary administrative panel for that domain. For the custom development after that, in most MVC frameworks, model binding takes care of the laborious task of transcribing data from web forms.
Can you believe we once coded these very things by hand? Spending countless hours, time and time again writing the same functionality over and over. We must have been really dumb! But wait a second, we aren't dumb - nor were we back then. If this functionality truly was boilerplate stuff, surely we would have realized that we could simply copy/paste a project basis and started off half done, right? Well, why didn't we?
Here's my theory. I'll say that those features, and many others, proved each time we worked on them to be complex, challenging problems that were rewarding to solve in a better way than we solved them last time. But then something happened. Many bright and forward thinking peers of ours made their solutions generic and packaged them for the rest of us to use. I think, then, that we ultimately realized that we were a little tired of working on the same problems so many times. We rationalized to ourselves that these folks have it cold - they've put the real time in and truly solved these problems for good, and so we accepted their solutions.
Now, so far to this point, I really have no problem. I use these libraries, frameworks and tools on a daily basis and certainly wouldn't start a real project without them. It's the next step that I have noticed us taking that really hurts. I have watched numerous otherwise brilliant, thoughtful, careful developers rely on these tools as black boxes unworthy of scrutiny or even light questioning. It seems these tools are plugged into a project and all of a sudden the lazy switch gets thrown - we dust off our hands and move on to the next problem. Rarely have I seen my fellow developers truly think about what the tools they are using are doing, how they are doing it, and ultimately how it affects their product. In some sense, it seems that they forget that it is THEIR product they are building.
Ok, now for the tough love.
If a plugin you are using is slow, your product is slow. If the form handling framework you are using is insecure, your product is insecure. If the framework you are using is bloated and confusing your product is bloated and confusing.
Here's a quick example (what triggered this post, actually). In MVC.NET there is truly great support for Model Binding. With it, you rarely, if ever, need to touch the actual form post anymore. Simply add some domain arguments to your action, make sure the names match up, and you're good to go.
But wait a second:
How does this functionality work? It matches up the form element names to object and property names in your domain and transcribes the values to your domain objects.
How does this impact your product? This means any user of your product can manipulate the form to their liking, and directly influence not just the data you receive, but the type and relationship of objects you receive.
For instance, let's say you have a user information form: Name, Email, Favorite Food - that kind of thing. Then let's say that a malicious user knows or otherwise guesses that User.UserType determines whether someone is a "Member" or an "Administrator". By manipulating the form, and injecting a field named "UserType" with a value of "Administrator", they can trick you into making their user an administrator! This technique can be used to modify any data you treated with trust - from a user's account type, to a simple little setting you didn't expect them to have access to.
Now for the mind-boggling part. Every developer I bring this up to knows of both this behavior and effect. They also know of any number of things they could do to close this security hole - though not a single one of them addresses the problem!
So I find myself wondering... why? Why would these, as I said earlier, brilliant, thoughtful, careful developers take a shortcut on such an important issue - obviously weakening their product? I think it is because of the reason they are using the tool in the first place. In some way, if they spend time plugging up the holes left by the tool, they still aren't getting on to those bigger problems, those bigger fish that are so alluring in the first place. Pride in one's product, it seems, has taken a backseat to immediate gratification.
I challenge anyone reading this to revitalize your sense of pride in your work. Take a good look at the tools you use. Consider the impacts they have on your product, and plug up the problems you see. Then, post your solutions... I want to use it as a plugin :P
No comments:
Post a Comment