Well, yes. If you were going to exploit CGI scripts you'd likely use wget or curl instead of coding an HTTP client from scratch so why is this suprising?
I think the author missed the point of CGI. The point being that the web server doesn’t parse anything, it just passes the request to the CGI program via environment variables and standard input/output.
CGI has always been an accident waiting to happen, but hardly anybody uses it anymore anyway, and even more rarely in a manner that invokes bash, of all things.
I fail to see how "HTTP requests" generically are a vector, and its "Here is a sample" statement is not a link and is followed by... nothing.
This article tells me nothing useful other than "don't allow untrusted data into your environment", which we've all known for 20 years.
Knowledge of plain old CGI on a web server seems lost due to fancy frameworks? And even without the CGI-Interface, you can make it work if you have a script monitoring your web server's logs:
I sometimes transfer data with curl via a url which does not exist, but where a script running on the server watches the server's error log and extracts data from those entries. For example: access (via curl or perl' GET, or whatever) these urls
The script watches for these entries and acts upon the stuff following the data0815 part. It's a fast hack, which can be augmented and expanded in various ways, all without frameworks.
> Zero external configuration, other than telling your webserver to enable CGI on your file
This is only true if you've done it before, and know what you're doing. In reality, it looks like a mess of `mod_cgi` configuration, trying different combinations of file permissions, finding the magic `cgi_bin` directory, finding the right obscure log files when there are inevitably errors, wrestling with CORS and other subtleties of HTTP headers, and other complexities that are only easy to navigate if you're already an experienced CGI user.
That being said, I love the philosophy of using CGI for scripts. Instead of using CGI itself, though, I wrote a (single-file, statically-linked) web server called "QuickServ" to bring this philosophy into the twenty-first century. It has all of the upside of CGI, but is much easier to set up and run, especially for beginners.
One of its benefits is that it automatically parses submitted HTTP forms, and converts the form fields to command line arguments. That means it's extremely easy to put existing CLIs on the web with minimal changes other than writing an HTML form front-end.
If you like CGI, I will (shamelessly) ask that you check it out!
Ok, let me see if I have this straight, since I'm not seeing an end of the world situation here.
This requires a webserver to be running CGI (mod_cgi or whatever) and the get request has to go to a valid page, correct? So in this case `GET /cgi-bin/hello ... yada yada yada` /cgi-bin/hello has to be a valid location.
So, explain to me how this is any worse than any remote execution vulnerability in something like PHP?
CGI defined an interface between a web server and an executable that would provide a response.
- Request meta-data i.e. path, query string, and other headers passed as environment variables.
- Request body passed via stdin
- Response header and body passed via stdout
In this way, a webserver like Apache could provide a platform for a wide array of languages. Yes there were security and scaling concerns, but it also was an opportunity to rapidly release and iterate on a product.
Wow I havent written a CGI script since before Christmas.
Stuff still works just fine, a nice simple way to expose things to users without them having to ssh into a server.
Not everyone is trying to build the next adladen POS unicorn financed from abusing millions of users for a couple of cents, some are just trying to make peoples lives a little easier and make their jobs a little more efficient, and throwing some Perl, Python, PHP or whatever together often accomplishes that just fine.
They reinvented CGI scripts but didn't actually implement CGI. Could have implicitly supported a lot of apps by default. There's some pretty decent CGI libraries for Bash, too.
Personally I use busybox's httpd (which does support CGI) for a small portable web server.
> That is completely false. CGI has basically no attack surface. And personally, I trust Perl or C or even bash (which do have an attack surface) more than I trust all these random frameworks.
While you're technically right that CGI doesn't include Perl/C/Bash, it feels like you're hand-waving somewhat to avoid discussing the real crux of the problem. Having spent a significant amount of the last 30 years writing software in Perl, C and Bash (languages that I genuinely do enjoy coding in too), I honestly don't trust anyone's ability to knock their own framework out as securely as many of the established frameworks already out there.
There's all sorts of hidden traps in those languages themselves, hidden traps in the way the the web behaves as well as bugs you could introduce just through human error.
CGI is fun for hacking stuff together but if you're building anything for public consumption - even if it's only going to be a low hit count - then you have to consider what damage could be done if that machine was compromised (though it's prudent to follow that train of thought regardless of the framework you end up on).
> Except oftentimes these days you need both an HTTP server and an app server (as mentioned). CGI only needs an HTTP server.
Except oftentimes you also don't. And even in the instances where you do, often something like S3 or some CDNs will fill the role (as often it's just static content you need hosting and some CDNs allow you to manually transfer content). Or if a CDN isn't an option and you do need a webserver + app server (eg nginx + php-fpm) then you can run them as two docker containers (for example) on the same server....and even if that isn't an option, it's really not that much more work monitoring 2 servers than it is 1 (if you were talking about a farm of dozens or more then you'd have a point. But then CGI also becomes a clear no-go because of it's performance penalties).
My point is there are a breadth of options out there these days and CGI rarely stacks up well against them.
One issue was that people configured CGI wrong. You had executable scripts that had free range on the entire filesystem. Ideally you'd need to limit the cgi-scripts to a chroot, but that made it difficult to use Perl, Python and PHP. OpenBSD shipped/ships a chrooted Perl for use with CGI, but other operating systems just left that bit as an exercise to the programmer.
More modern languages like Go or Rust provides a lot of safety and is pretty easy to statically compile, so it's easily chrooted. It would however be weird to do a CGI program in Go, because that language already have a really good build in webserver and more powerful/easily accessible features for interacting with requests compared to what CGI provides.
reply