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.

Let's examine one of their sample programs to see what I mean. You can check out their timesheet application and view the code here. Hmm... I wonder how they get the data from the form?

000172  GET_INPUT_FROM_WEB_PAGE. 
000173      GETENV USING `CONTENT_LENGTH` content_length. 
000174      IF content_length IS GREATER THAN 0 THEN 
000175          ACCEPT DATA FROM WEBPAGE
[download]

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:

<FORM ACTION="cobolscript.exe?uts.cbl" METHOD=POST>
<INPUT TYPE="hidden" NAME="month" VALUE="January     ">
<INPUT TYPE="hidden" NAME="year" VALUE="2000">
<INPUT TYPE="hidden" NAME="employee_name" VALUE="Matt                "
+>
<INPUT TYPE="hidden" NAME="day_var" VALUE=" 1">
<INPUT TYPE="hidden" NAME="update_flag" VALUE="Y">
<INPUT TYPE="hidden" NAME="update_record_key" VALUE="00084">
 <INPUT TYPE="text" maxlength=2 NAME="update_hours" SIZE=2 VALUE="80">
+</font></TD>
<TD><font size=-1 face="verdana"><INPUT TYPE="text" maxlength=80 NAME=
+"update_desc" SIZE=80 VALUE="
45testttt
"></font></TD>
<TD><INPUT TYPE="submit" VALUE="Update"> </TD></FORM>
[download]

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:

5 update_desc                  PIC X(80).
[download]

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:

000157      MOVE update_desc   TO rec_desc.
[download]

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:

000113          PERFORM VARYING i FROM 1 BY 1 UNTIL i = 80 
000114             IF rec_desc(i:1) = `<` 
000115                IF z + 4 < 80 
000116                   MOVE `&lt;` TO temp_str(z:4) 
000117                   ADD 4 TO z 
000118                ELSE 
000119                   MOVE ` ` TO temp_str(z:1) 
000120                   ADD 1 TO z 
000121                END-IF
[download]

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.

Cheers,
Ovid

Update: I forgot to point something out. You may have noticed that their input fields have a lot of space padded on the end:

<INPUT TYPE="hidden" NAME="employee_name" VALUE="Matt                "
+>
[download]

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.