|Perl: the Markov chain saw|
(Ovid - my adventures with COBOLScript)by Ovid (Cardinal)
|on Dec 31, 2001 at 02:59 UTC||Need Help??|
I've known about them for quite some time and I think that is one of the worst mis-matches of language to task that I have seen. Basically, it's designed so that your experienced COBOL programmers can start doing Internet development without having to completely relearn everything. The problem, of course, is that while COBOL programmers are often excellent, they're working with an entirely different paradigm and do not understand Web development. What about security? How do you design an application that reads Web pages correctly? What's going on with headers? What are headers? And what the heck is TCP/IP?
To be fair, anyone going into Web development needs to pick up the above issues and more, but COBOL programmers (remember, I was one) are working in a different world.
In COBOL, variables are declared in Working Storage before the actual program starts. In the example above, we have those variables automatically populated with the ACCEPT DATA FROM WEBPAGE statement. It's interesting to note that this does not allow a GET request or verify that the length of the data matches the content length (of course, much of this may be done behind the scenes). Ignoring that, though, let's look at some of the HTML:
Ugh, that's pretty messy, but I won't worry about it too much. I'm more interested, right now, in the input box. It's named update_desc. It's defined in the COBOL as this:
Essentially, that means it can be 80 bytes of anything.
Later on, we see that this is written out to a record in a file:
That actually happens in two different places. One is to append a record and the other is to update one.
In reading further, we see that rec_desc is actually written out to a temp string, byte by byte, with "naughty" characters converted (it's not immediately obvious, because they forgot to escape the character codes like > in their HTML). Now, they do that with a routine similar to this:
I find the above code fascinating for two reasons. One, the only thing that they did any sanity checking on is the input text field (didn't bother with hidden fields, can you say "hmm..."? I knew you could). The other thing I find fascinating is that this code used to not exist!!!
In the good ol' days (about a year ago), you could enter HTML directly in the input boxes and screw up their pages. When I discovered this, I sent them an email. They ignored me. So, I sent an email off to a mailing list, explained the situation, and had friends play around -- with the caveat that they not do anything malicious. Pretty soon, we had scantily clad women (no nudity), security warnings, and at least one "use Perl;" graphic floating around on their test pages. They would usually take them down as fast as they found them, but they just wouldn't fix the durned problem. I finally sent them another email explaining who I was, what I was doing, why I was doing it, and how to fix the problem. A few days later, the problem dissappeared from the timesheet application but they didn't update the COBOL code with the patch! Actually displaying the patch appears to be recent.
I haven't checked their other applications today, but after they (clumsily) patched the timesheet application, I discovered that their other programs had the same problems, albeit a bit tougher to exploit. Of course, it's trivial to mess with these pages and I think this just goes to show that if the developers of COBOLScript don't understand the implications of what they do, how can they expect that average COBOL programmer to do so? Here are a bunch more security holes waiting to happen.
Update: I forgot to point something out. You may have noticed that their input fields have a lot of space padded on the end:
Now, some may just think that this is sloppy HTML. While that's true, it's interesting to look at the COBOL code. In the input box above, the value is exactly 20 characters. It's defined in the COBOL as PIC X(20) VALUE `Matt`.. Since COBOL traditionally works with fixed-length records (but not always), that's how it gets translated into the Web page. I imagine that there is probably not a problem with data input that is too short, but I wonder about data input that is too long. Somewhere, either in the custom code that the COBOLScript people have written, or in the programmers COBOL, this has to be tested. I can see all sorts of problems if this isn't done properly. COBOL does not handle text manipulation well and the Web is primarily text. Once again, this is a terrible mismatch between a language and the task to which it is applied.
Join the Perlmonks Setiathome Group or just click on the the link and check out ou stats.