I often rant about the liability that one assumes when one buys/procures software. Steven Robinson expounds on the topic a bit over at SecurityFocus
More on security for vendors vs. security for users.
Is anyone really suprised that MS is a prime culprit here?
Looks like Matt and I are now members of the OWASP input filters project.
Well, after my whining about OWASP yesterday, I had a good email exchange with the author(s) of this article and it looks like they'll be fixing some of the deficiencies that were introduced in the editing process.
I consider myself something of a security geek. I work for a security company, I develop applications that require security, I've written authentication mechanisms before, etc...
So I was happy to run across OWASP. Goodness knows most web application developers wouldn't know a good hash function if it bit them, let alone input validation, so OWASP provides a valuable service. Which brings me to the big "but". They don't often (ever?) mention that anything you send to a browser is out of your controll as soon as it's left the server. You can make suggestions to the browser, but you can't actually instruct it to reliably do anything, nor will you ever be informed if it deviates from the behavior you (incorrectly) assume it will exhibit. This feature is both what fueled the uptake of the web as the people's publishing medium, yet it's also the Achilles heel of web application security. Unless you are unambiguously tracking things on the server side and mapping what you expect to what you actually get (and then scrubbing it), you're in for a rude awakening. In the same way the developers that use CSS understand that you don't control the browsers behavior, back-end developers need to start learning that you don't have the faintest idea about who/what's really on the other end of that TCP/IP socket.
As a web developers we are nothing but muses on the client side of things, we exist to suggest and never to act.