Stop Using CGI

No, not the dinosaur kind of CGI that is Computer Generated Imagery, but the Common Gateway Interface kind used by web servers to render dynamic content.

CGI for web applications may appear simple and easy, but it is slow, clumsy, insecure and ancient. There are much better alternatives for nearly every use case.

Stop using it!

Common Gateway Interface

CGI is an old standard for web servers to dynamically respond to client web requests. Each request invokes an external, stand-alone program to generate a response for the incoming client HTTP request. Requests parameters are passed to the CGI program via environment variables. Client posted data is sent to the CGI program via its standard input. The CGI program reacts by writing an appropriate response to its standard output, which the web server then parses, transforms and relays to the web client. CGI programs can be written in any language.

A Bit Too Simple

The CGI protocol itself is very simple and that is both its allure and downfall. The protocol at its essence is a pipe with the CGI program reading standard input plus environment and generating a response to the standard output. Both ends of the pipe are connected to the web server.

Created in the 90’s, CGI was the first technique for generating dynamic content. However, the needs of web applications have grown enormously, and CGI has not evolved to meet the need. It simply is not up to the challenges of modern web applications and the onerous security environment of today. Unfortunately, many embedded devices still use CGI today.

Why Do Some Devices Use CGI?

• Some use it because of the apparent simplicity of CGI.

• Some have a mistaken belief that their web interface is so simple, only CGI is needed.

• Some think their device has limited processing resources and therefore the device cannot run a proper web framework.

• Some have believed misinformation on the web such as “state of the art CGI” and “Advanced web server with CGI” by vendors selling web servers that only have CGI capabilities.

The result is many embedded devices with slow, insecure management applications that exhibit very poor usability.

Serious Issues with CGI

CGI is simple and the task of creating a secure device management user interfaces is not. This mismatch and the simplicity of CGI comes at high price, as there are serious problems with CGI:

1. CGI creates a new process on each and every request. Creating a process is costly and on modest embedded systems, it can easily take a significant portion of system resources. This means less resources are available for running important device services and the web user interface itself becomes slow and less responsive.

2. CGI creates a denial-of-service security vulnerability. Creating a new process for each request is a significant consumption of resource and introduces delays in responding to client requests. Multiply this by a few dozen or hundred requests and an embedded system will have little or no resources left for running the actual device services. Devices using CGI are easy targets.

3. CGI is slow. In addition to creating a new process for each request, the web server must relay data to and from the CGI program. Some web servers pass this data via pipes but others use files. This means client responses are delayed and user response and page refresh often takes seconds. This means the client’s browser experience is slow and soggy.

4. CGI responses cannot easily compute the response content length. This means the request may not be able to use HTTP Keep-Alive and the socket cannot be reused for subsequent requests. This introduces lengthy TCP/IP connection delays which are especially slow on mobile devices.

5. CGI is a very low level interface. It does not provide any framework, reusable components or developer assistance in creating a web application. CGI offers no template framework so HTML is typically generated programatically. This means developing web applications is slow, clumsy and error prone.

6. CGI opens new security vulnerability vectors. Rather than increasing security, CGI means that you must also secure the CGI interface and CGI programs as well as the web server. Further, CGI does not assist in addressing injection attacks, cross-site scripting, user authentication, information disclosure, cross site forgery or user input validation.

7. The target languages for CGI programs are poorly suited for creating web applications. CGI scripts are often written in Perl or C/C++. These languages provide minimal or no assistance for creating secure web applications.

8. CGI programs do not scale well. Developers can choose to either create one large monolithic CGI program that is hard to test and maintain, or they can create many separate CGI programs. The latter approach often means replicating code in each CGI program.

Some servers have tried to address the problems with CGI with a variant called Fast-CGI or FCGI. This does improve performance but many of the same issues remain.

CGI is the wrong solution for modern embedded web applications. CGI is slow, unresponsive and hard to secure. Stop using it! Instead, use one of the integrated web frameworks that embedded web servers offer. These provide plenty of support in creating secure, responsive and usable web interfaces.

Alternatives

While there are many excellent options for building web applications, my top choice is Ioto. Ioto is a powerful C-language web framework that runs at native speed, delivering exceptional efficiency. It seamlessly accesses hardware and system data, making it ideal for creating fast and compelling web applications.

Ioto maps request URLs directly to native functions, eliminating unnecessary data copying or processing. Modern device management applications often rely on browser frameworks like Vue.js or React, and Ioto is specifically designed to efficiently deliver device data to these front-end frameworks.

Background Reading:

• ShellShock - Bash
• Linux.Darloz
• Linux Worm
• Embedded Security
• Hacking Embedded Devices
• Shodan - embedded device search