Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Wednesday January 29, 2003
10:36 PM

More security problems

[ #10287 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • ... 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 u

  • At least they didn't sue you for pointing out the security issue :/

    -matt
    • 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 think the choice of technology says a lot about the company - if they are using ASP then they care more about following the crowd and ticking boxes than actually thinking.

    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

    --

    @JAPH = qw(Hacker Perl Another Just);
    print reverse @JAPH;