Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Sad, but true

by jcwren (Prior)
on Dec 30, 2001 at 22:09 UTC ( #135261=perlmeditation: print w/ replies, xml ) Need Help??

So the other day, a user in the chatterbox was asking some questions about how the PM server "knew" what timezone you were in, and asked if it was done with Javascript.

I joking replied it was done with COBOLScript, a lesser known but more powerful scripting language.

Today, the aforementioned (but unnamed) user forwarded me this link:

http://www.cobolscript.com

So sad...

--Chris

e-mail jcwren

Comment on Sad, but true
Re: Sad, but true
by simon.proctor (Vicar) on Dec 30, 2001 at 22:32 UTC
    well they use a dinosaur in their logo - freudian slip? :P
      I think the dinosaur (it's not a very fearsome one, is it?) may be an allusion to the old cartoon which shows a T. Rex with a midrange sort of box in its claws.

      The caption reads:
      Mainframes! We're back, and we're pissed!
      or words to that effect.

      Well it made us m/frame jockeys feel a bit better 8-)

      hagen - who now rides Solaris 8-) and NT 8-(

      Have a great 2002 everyone.

Re: Sad, but true
by Beatnik (Parson) on Dec 30, 2001 at 22:35 UTC
    Why do people tell me about CGI programming in COBOL EVERY time I'm studying for my exams?? :)
    • Yes, I knew COBOL could be used for CGI stuff, altho I saw a different link a few months ago. COBOL & CGI on Google perhaps?
    • Yes, COBOL is one of those languages I'd rather forget but unfortunatly I can't since it's burned into my soul
    • Yes, I'll have nightmares about this... THANK YOU VERY MUCH! :))))
    • Yes, COBOL DOES suck :)

    Greetz
    Beatnik
    ... Quidquid perl dictum sit, altum viditur.
(Ovid - my adventures with COBOLScript)
by Ovid (Cardinal) on Dec 31, 2001 at 02:59 UTC

    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

    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>

    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).

    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.

    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 &gt; 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

    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 " +>

    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.

      Exploitable COBOL code... wonder if I'll pass my COBOL exam if I told it to my professor :)

      Greetz
      Beatnik
      ... Quidquid perl dictum sit, altum viditur.
      Ovid,

      I'm either really impressed or really bored about knowing so much about the interiors of COBOLScript - can't decide which :-)

      cLive ;-)

      Coming soon - Z80script - yes, you too can turn your ZX81 into a powerful CGI gateway (16Kb RAM module recommended)

Re: Sad, but true
by Maclir (Curate) on Jan 01, 2002 at 21:14 UTC
    Ohhh, yeah baby - talk dirty to me (that WORKING_STORAGE SECTION does things to me)!!

    Now all I want is FORTRANscript. As everyone knows, real programmers use Fortran - and Fortran programmers can write Fortran programs in any language.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://135261]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (9)
As of 2014-07-29 13:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (217 votes), past polls