Responsibility / Liability for Security In Our Software

A question of curiosity that may be of some benefit to myself and other fledgling developers:

How do you folks handle the issue of security liability in your programming? I strive to make my scripts (especially my scripts for other people) as secure as possible by default. However, no program or programmer or programming language is perfect, and there will always be security problems. How do you folks let your clients know up front about this? Do you disavow anything related to the security of your scripts beyond fixing holes that are found? Do you specify right off that you will not be responsible for lost data, time, business, etc. for security holes? I don't want to wring my clients out to dry on this issue, but, frankly, I don't want to accept responsibility for super-hidden security problems in a script when I know I made every attempt to make it secure "out of the box". I already offer to make free fixes for any glaring bugs / security problems that are found. So, how do you guys that've been in the biz a little longer handle this sticky issue?

[P.S.: Sorry, had a hard time coming up with a subject]

Well, you can't see the future, and you can't guess what new hack might come out next week.

I build scripts to be as secure as currently possible. That means checking user input, addslashes, limiting the input size on form fields, etc. I also like to limit the amount of data a user can actually input. If you use drop downs, radio buttons, check boxes, etc. you can reduce your vulnerability to hacks (can't paste code into a radio button). It also has the added benefit of reducing user screwups, i.e. where the visitor types the wrong info into a form.

If something comes up down the road, then I charge to fix it. If it's a mistake that I made, then no charge. One way around this is ongoing support contracts with clients. That way if there is a security problem down the road the cost to fix is just part of the support contract. And neither side feels like they are getting the shaft.

Don't rely on drop-down menus (or other "limited choice" form elements) as a security measure- A malicious user could always just save your form locally and edit it to send whatever they want to your server. This requires only a very low-level understanding of HTML.

For instance- say you had a drop-down menu that pushed a value straight into an SQL query- you're vulnerable, unless you untaint the data.

A higher level cracker could just write a bot to simulate a web browser and send anything they wanted, too.

Validation should be both client and server side, and on ALL parameters.

You probably knew that, I just don't want other users to misinterpret your post as implying that drop-down menus make a more secure app. Less error prone in general usage, yes. More secure, no.

I feel fairly comfortable, I'm just looking for "how do I cover my own ***" if something goes wrong? In other words, if the client gets cracked, then what?

Hero,
You're right I didn't mean it as a "foolproof" method, just reduces vulnerability, anything can be circumvented.

I should have said it makes it more difficult for the malicious user. Instead of pasting bad code into a text box, they have to work a little more to get around it. The harder you make it to get in, the less likely they are to bother with it.

Although some might see it as a challenge.

The main reason I do it that way is to prevent user screwups.

CTB,
I haven't personally seen too many instances where servers get cracked, especially if they are linux or freebsd. Really big or popular sites are generally the targets of competent hackers, and not small biz sites.

Generally, if your host has things setup properly, keeps up with patches, passwords are complex, etc. sites won't get cracked. You should still take security very seriously.

If a client gets cracked and it's your fault, then you would first need to find out the how's and why's, and then fix the problem. When writng your scripts consider what will happen if the site does get cracked. Is there sensitive data? If so, should it be stored this way or is there a better way? Think about the worst case scenario and then figure out how to prevent it.