I actually ran across a similar problem while doing some Perl/CGI freelancing. The client hired me to add some functionality to an existing shopping cart CGI that he had already paid for. I don't know who wrote the shopping cart but although it was (on the surface) perfectly functional and suited the client's needs, it was really, really ugly on the backend. (No CGI.pm, hand-rolled templating functions a la HTML::Template, you get the idea.) Although prices for items were stored in a db (a 5,000 row flat-file, natch) the shopping cart deliberately accepted price changes from the HTML form to allow for things like discounts for re-sellers and premier customers and such.

I thought this was amazingly dumb, but it made some of the things I was contracted to do easier (adding "bonus items" from the db for free, for example.) Fixing the security problems would have involved a fairly major re-write of the whole shopping cart (although trust me, adding "use CGI;" would've saved a hell of alot coding) and it was near Christmas and the client didn't have the time for the re-write/re-test cycle for a cart that, like I said, already worked.

So I did what I was hired to do, got paid, and the client was happy. The original program was just so bad there really wasn't anything else to do give the time and money at issue. It felt very wrong, though... we spend so much time making sure that our code is as secure as we can manage that deliberately leaving security holes is, literally, a sin.

But perhaps the bigger sinners are those that write this crap to begin with. My clients were small businessmen, not coders. When they hire someone to do a job they don't have the means to do a third-party review of the code they just bought; they're just taking the programmer's word that what they bought is secure. The client (in my case) got ripped off by the original coders long before they almost certainly got ripped off by people taking advantage of the security hole.

sigh

Gary Blackburn
Trained Killer