use Perl

I'm working with company XXXX and they asked me to send them some information. After they received it, they sent me a link to said information. In checking the link, I noticed an "email this info" link. I clicked on it and was presented with a form with text input boxes for both the to and from addresses. After confirming the problem by sending myself email from god@heaven.mil, I dug a little further. I inserted a single quote mark into an ID in the query string and was presented with a very informative ASP error message. Were I inclined (and I wasn't), I suspect that it would only take a few minutes of work to break into their system with an SQL injection attack. I sent them an email explaining the issue and a useful URL on how the attack works and I hope they fix this.

Why, why, why, after all of the exposure to these problems, do programmers still trust user input? Even if it's not a cracker trying break in, users can still make mistakes. XXXX is a company that works with technology professionals every day and someone should have spotted this before now. Instead, this technology company decided to apparently accept the lowest bid on work for their site.

I think the problem lies in a couple of areas. First, many programmers can get the job done and if everything works as expected, they think they're done. They don't bother to think about the unexpected. There's a saying I've heard that I love: a good programmer looks both ways before crossing a one-way street. Many programmers look for where the cars are supposed to be coming from and think "it's not my fault if someone is driving the wrong way". This is absolutely the wrong attitude to take. However, hubris can bind people to this attitude and it's tough to shake. I've struggled with this myself.

The other reason I think this is so prevalent is the dot-com boom followed by the unfortunate, but necessary, dot-com bust. Many companies were so desperate for programmers that upon discovering that a clerk was able to edit an HTML doc in Notepad were willing to promote him or her to a programmer. Thus, we had people with no real experience hiring people with no real experience and passing on their knowledge. We are stuck with this today.

Many would argue that the latter point is incorrect because we've always had bad programmers. I haven't been in the industry long enough to refute this from experience but when I did mainframe programming I would sometimes work with programs written before I was born. These programs were some of the worst spaghetti I had ever seen ... but they worked. They worked darned well. These would often be embedded in long-running batch processes and failure was not an option. Today, people seem to be so intent on tossing something together as quickly and inexpensively as possible that they don't consider the long-term issues they may be causing.