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.
... 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.
In the past, people also wanted something done quickly and inexpensively, but two factors made the difference in the old mainframe programs you saw.
First, the economics were different when those programs were written: computer time cost more than programmer time. It behooved people to get the most out of their allocation, so they set up tests and diagnostics from the beginning, and spent more time going over design, doing desk-checking, and so on. During the dot-com boom, "HTML programmers with Notepad" were more expensive than the potential damage caused by insecure web sites, so there was no incentive to spend resources on security and robust design.
Second, most mainframe programs have been around for umpty-ump years, and have grown into spaghetti code over that time by being patched, fixed, and tweaked. Most web sites have been not been around more than a few years, so their bugs are still fresh and near the surface. In another twenty years, security features will become the norm. (In Perl 7.2, strict will be the default, and you won't be able to turn off taint mode or warnings.
Re:Lucky
Ovid on 2003-01-30T21:26:30
I had briefly considered that possibility. I had noticed that the data I sent had a typo and I was tempted to have fun by fixing the typo myself by creating an account, but that would have been pushing my luck
:) As it stands now, they have incentive to keep me happy and I did not compromise their system. Fortunately, I have better luck than merlyn.
I have worked with ASP for over a year and can safely say that server-side validation is the exception rather than the norm.
Worse still even if you do server-side validation, you can't control what happens when you call COM objects that are required for even basic tasks like email, file uploads and browser detection.
It is possible to write a good web application in ASP but it takes a great deal more work than doing so in Java, Python, Perl, coldfusion or PHP.
