Interfaz de puerta de enlace común

En informática , la Interfaz de Puerta de Enlace Común ( CGI ) es una especificación de interfaz que permite a los servidores web ejecutar un programa externo para procesar las solicitudes de los usuarios mediante HTTP o HTTPS .

Estos programas suelen estar escritos en un lenguaje de scripting y se conocen comúnmente como scripts CGI , pero pueden incluir programas compilados . ^{[ 1 ]}

Un caso de uso típico ocurre cuando un usuario web envía un formulario web en una página web que utiliza CGI. Los datos del formulario se envían al servidor web mediante una solicitud HTTP con una URL que indica un script CGI. El servidor web ejecuta el script CGI en un nuevo proceso informático , pasándole los datos del formulario. El script CGI envía su resultado, generalmente en formato HTML , al servidor web, y este lo reenvía al navegador como respuesta a su solicitud. ^{[ 2 ]}

Desarrollado a principios de la década de 1990, CGI fue el primer método común disponible que permitía la interactividad de una página web. Debido a la necesidad de ejecutar scripts CGI en un proceso independiente cada vez que un cliente realizaba una solicitud, se desarrollaron diversas alternativas.

En 1993, el equipo del Centro Nacional de Aplicaciones de Supercomputación (NCSA) escribió la especificación para llamar a ejecutables de línea de comandos en la lista de correo www-talk. ^{[ 3 ] [ 4 ] [ 5 ]} Los demás desarrolladores de servidores web la adoptaron, y desde entonces ha sido un estándar para los servidores web. Un grupo de trabajo presidido por Ken Coar comenzó en noviembre de 1997 para definir más formalmente la definición de CGI del NCSA. ^{[ 6 ]} Este trabajo dio como resultado el RFC 3875 , que especificó la versión 1.1 de CGI. En el RFC se mencionan específicamente los siguientes colaboradores: ^{[ 2 ]} 

• Rob McCool (autor del servidor web HTTPd de NCSA )
• John Franks (autor del servidor web GN)
• Ari Luotonen (el desarrollador del servidor web httpd del CERN )
• Tony Sanders (autor del servidor web Plexus)
• George Phillips (encargado del mantenimiento del servidor web en la Universidad de Columbia Británica)

Históricamente, los programas CGI se escribían a menudo utilizando el lenguaje de programación C. El RFC 3875 "The Common Gateway Interface (CGI)" define parcialmente CGI utilizando C, ^{[ 2 ]} al decir que las variables de entorno "son accedidas por la rutina de la biblioteca C getenv() o la variable environ".

El nombre CGI proviene de los inicios de la web, cuando los administradores web querían conectar sistemas de información heredados, como bases de datos, a sus servidores web. El programa CGI era ejecutado por el servidor y proporcionaba una "puerta de enlace" común entre el servidor web y el sistema de información heredado.

Tradicionalmente, un servidor web tiene un directorio designado como colección de documentos, es decir, un conjunto de archivos que se pueden enviar a los navegadores web conectados al servidor. ^{[ 7 ]} Por ejemplo, si un servidor web tiene el nombre de dominio completowww.example.com y su colección de documentos está almacenada /usr/local/apache/htdocs/en el sistema de archivos local (su raíz de documentos ), entonces el servidor web responderá a una solicitud de http://www.example.com/index.htmlenviando al navegador una copia del archivo /usr/local/apache/htdocs/index.html(si existe).

En el caso de las páginas generadas sobre la marcha, el software del servidor puede remitir las solicitudes a programas separados y transmitir los resultados al cliente solicitante (normalmente, un navegador web que muestra la página al usuario final).

Estos programas suelen requerir que se especifique información adicional con la solicitud, como cadenas de consulta o cookies . Por el contrario, al devolver una respuesta, el script debe proporcionar toda la información requerida por HTTP para responder a la solicitud: el estado HTTP de la solicitud, el contenido del documento (si está disponible), el tipo de documento (por ejemplo, HTML, PDF o texto plano), etcétera.

Inicialmente, no existían métodos estandarizados para el intercambio de datos entre un navegador, el servidor HTTP con el que se comunicaba y los scripts del servidor encargados de procesar los datos y, finalmente, devolver un resultado al navegador. Como consecuencia, existían incompatibilidades entre las distintas variantes de servidores HTTP que dificultaban la portabilidad de los scripts .

El reconocimiento de este problema llevó a la especificación de cómo debía realizarse el intercambio de datos, lo que dio como resultado el desarrollo de CGI. Los programas generadores de páginas web invocados por el software del servidor que se adhiere a la especificación CGI se conocen como scripts CGI , aunque en realidad pueden haber sido escritos en un lenguaje que no sea de scripting, como C.

La especificación CGI fue rápidamente adoptada y sigue siendo compatible con muchos paquetes de servidores HTTP conocidos, como Apache , Microsoft IIS y (con una extensión) servidores basados ​​en Node.js.

Uno de los primeros usos de los scripts CGI fue el procesamiento de formularios. Al principio de HTML, los formularios solían tener un atributo "action" y un botón designado como "submit". Al pulsar este botón, la URI especificada en el atributo "action" se enviaba al servidor junto con los datos del formulario como una cadena de consulta. Si el atributo "action" especificaba un script CGI, este se ejecutaba y, a su vez, generaba una página HTML.

Un servidor web compatible con CGI puede configurarse para interpretar una URL que sirva como referencia a un script CGI. Una convención común es tener un cgi-bin/directorio en la raíz del árbol de directorios y tratar todos los archivos ejecutables dentro de este directorio (y ningún otro, por seguridad) como scripts CGI. Cuando un navegador web solicita una URL que apunta a un archivo dentro del directorio CGI (por ejemplo, http://example.com/cgi-bin/printenv.pl/with/additional/path?and=a&query=string), en lugar de simplemente enviar ese archivo ( /usr/local/apache/htdocs/cgi-bin/printenv.pl) al navegador web, el servidor HTTP ejecuta el script especificado y pasa la salida del script al navegador web. Es decir, todo lo que el script envía a la salida estándar se pasa al cliente web en lugar de mostrarse en la ventana de terminal que inició el servidor web. Otra convención popular es usar extensiones de archivo ; por ejemplo, si los scripts CGI tienen consistentemente la extensión .cgi, el servidor web puede configurarse para interpretar todos esos archivos como scripts CGI. Si bien es conveniente y requerido por muchos scripts preempaquetados, expone al servidor a ataques si un usuario remoto puede cargar código ejecutable con la extensión adecuada.

The CGI specification defines how additional information passed with the request is passed to the script. The Web server creates a subset of the environment variables passed to it and adds details pertinent to the HTTP environment. For instance, if a slash and additional directory name(s) are appended to the URL immediately after the name of the script (in this example, /with/additional/path), then that path is stored in the PATH_INFOenvironment variable before the script is called. If parameters are sent to the script via an HTTP GET request (a question mark appended to the URL, followed by param=value pairs; in the example, ?and=a&query=string), then those parameters are stored in the QUERY_STRING environment variable before the script is called. Request HTTP message body, such as form parameters sent via an HTTP POST request, are passed to the script's standard input. The script can then read these environment variables or data from standard input and adapt to the Web browser's request.^[8]

CGI is often used to process input information from the user and produce the appropriate output. An example of a CGI program is one implementing a wiki. If the user agent requests the name of an entry, the Web server executes the CGI program. The CGI program retrieves the source of that entry's page (if one exists), transforms it into HTML, and prints the result. The Web server receives the output from the CGI program and transmits it to the user agent. Then if the user agent clicks the "Edit page" button, the CGI program populates an HTML textarea or other editing control with the page's contents. Finally if the user agent clicks the "Publish page" button, the CGI program transforms the updated HTML into the source of that entry's page and saves it.

CGI programs run, by default, in the security context of the Web server. When first introduced a number of example scripts were provided with the reference distributions of the NCSA, Apache and CERN Web servers to show how shell scripts or C programs could be coded to make use of the new CGI. One such example script was a CGI program called PHF that implemented a simple phone book.

Al igual que otros scripts de la época, este utilizaba una función. escape_shell_cmd()Esta función debía sanitizar su argumento, proveniente de la entrada del usuario, y luego pasarlo al intérprete de comandos de Unix para su ejecución en el contexto de seguridad del servidor web. Sin embargo, el script no sanitizó correctamente toda la entrada y permitió que se pasaran nuevas líneas al intérprete de comandos, lo que en la práctica permitió la ejecución de múltiples comandos. Los resultados de estos comandos se mostraban en el servidor web. Si el contexto de seguridad del servidor web lo permitía, los atacantes podían ejecutar comandos maliciosos.

Este fue el primer ejemplo generalizado de un nuevo tipo de ataque basado en la web llamado inyección de código , donde los datos no sanitizados de los usuarios de la web podían conducir a la ejecución de código en un servidor web. Debido a que el código de ejemplo se instalaba por defecto, los ataques se generalizaron y dieron lugar a varias advertencias de seguridad a principios de 1996. ^{[ 9 ]}

La vulnerabilidad 'Shellshock' de Bash permite la ejecución de datos inyectados en variables de entorno , que es precisamente el mecanismo que utiliza CGI para poner los encabezados HTTP a disposición de los programas; por lo tanto, los scripts de Bash utilizados como programas CGI pueden haber sufrido una vulnerabilidad a la ejecución remota de código . ^{[ 10 ]}

Para cada solicitud HTTP entrante, un servidor web crea un nuevo proceso CGI para gestionarla y lo destruye una vez procesada la solicitud. La creación y destrucción de un proceso puede consumir más tiempo de CPU y recursos de memoria que la propia generación de la salida del proceso, especialmente cuando el programa CGI aún necesita ser interpretado por una máquina virtual. Ante un elevado número de solicitudes HTTP, la carga de trabajo resultante puede saturar rápidamente el servidor web.

La sobrecarga computacional que implica la creación y destrucción de procesos CGI se puede reducir mediante las siguientes técnicas:

• Programas CGI precompilados a código máquina , por ejemplo, precompilados a partir de programas en C o C++ , en lugar de programas CGI ejecutados por un intérprete, por ejemplo, programas en Perl , PHP o Python .
• Extensiones de servidor web como módulos Apache (por ejemplo mod_perl, mod_phpy mod_python), complementos NSAPI y complementos ISAPI que permiten que los procesos de aplicación de larga duración manejen más de una solicitud y estén alojados dentro del servidor web.
• FastCGI , SCGI y AJP permiten que los procesos de aplicación de larga duración que manejan más de una solicitud se alojen externamente; es decir, por separado del servidor web. Cada proceso de aplicación escucha en un socket; el servidor web gestiona una solicitud HTTP y la envía a través de otro protocolo (FastCGI, SCGI o AJP) al socket solo para contenido dinámico, mientras que el contenido estático suele ser gestionado directamente por el servidor web. Este enfoque requiere menos procesos de aplicación, por lo que consume menos memoria que el enfoque de extensión del servidor web. Y a diferencia de convertir un programa de aplicación en una extensión del servidor web, los programas de aplicación FastCGI, SCGI y AJP permanecen independientes del servidor web.
• Jakarta EE ejecuta aplicaciones Jakarta Servlet en un contenedor web para servir contenido dinámico y, opcionalmente, contenido estático. Esto reemplaza la sobrecarga de crear y destruir procesos con la sobrecarga mucho menor de crear y destruir hilos . Además, expone al programador a la biblioteca que viene con Java SE, en la que se basa la versión de Jakarta EE que se está utilizando.
• Servidor HTTP independiente
• La interfaz de puerta de enlace del servidor web (WSGI) es un enfoque moderno escrito en el lenguaje de programación Python . Está definida por la PEP 3333 ^{[ 11 ]} y se implementa a través de varios métodos como mod_wsgi(módulo Apache), servidor web Gunicorn (entre Nginx y scripts/frameworks como Django), UWSGI , etc.

La configuración óptima para cualquier aplicación web depende de detalles específicos de la aplicación, el volumen de tráfico y la complejidad de la transacción. Es necesario analizar estas ventajas y desventajas para determinar la mejor implementación para una tarea y un presupuesto de tiempo determinados. Los frameworks web ofrecen una alternativa al uso de scripts CGI para interactuar con los agentes de usuario.

• CGI.pm – Módulo Perl para aplicaciones web 
• Interfaz de puerta de enlace de DOS : navegador web gráfico para páginas de DOS y Linux que muestran breves descripciones de los destinos de redireccionamiento. 
• Función como servicio : categoría de servicios de computación en la nube. 
• Interfaz de puerta de enlace del servidor web Perl : marco de aplicaciones web. Páginas que muestran breves descripciones de los destinos de redirección. 
• Rack (interfaz de servidor web) : especificación de API para aplicaciones web en el lenguaje de programación Ruby. 
• Inclusiones del lado del servidor : lenguaje de scripting interpretado del lado del servidor 

• La invención de la CGI
• RFC 3875 – Interfaz de puerta de enlace común (CGI) Versión 1.1 
• Programación CGI 101: ¡Aprende CGI hoy mismo! , un tutorial de CGI