En informática , Common Gateway Interface ( CGI ) es una especificación de interfaz que permite a los servidores web ejecutar un programa externo para procesar solicitudes de usuario HTTP o HTTPS . [1]
Estos programas suelen estar escritos en un lenguaje de secuencias de comandos y comúnmente se denominan secuencias de comandos CGI , pero pueden incluir programas compilados . [2]
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 dentro de una solicitud HTTP con una URL que indica un script CGI. Luego, el servidor web inicia el script CGI en un nuevo proceso informático y le pasa los datos del formulario. La salida del script CGI, generalmente en forma de HTML , es devuelta por el script al servidor web, y el servidor la retransmite al navegador como respuesta a la solicitud del navegador. [3]
Desarrollado a principios de la década de 1990, CGI fue el primer método común disponible que permitía que una página web fuera interactiva. Debido a la necesidad de ejecutar scripts CGI en un proceso separado cada vez que llega una solicitud de un cliente, se desarrollaron varias 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 comando en la lista de correo www-talk. [4] [5] [6] Los otros desarrolladores de servidores web lo adoptaron y desde entonces ha sido un estándar para servidores web. Un grupo de trabajo presidido por Ken Coar comenzó en noviembre de 1997 para lograr una definición más formal de CGI por parte de la NCSA. [7] Este trabajo dio como resultado el RFC 3875, que especificaba la versión 1.1 de CGI. En el RFC se mencionan específicamente los siguientes contribuyentes: [3]
Históricamente , los programas CGI se escribían a menudo utilizando el lenguaje de programación C. RFC 3875 "La interfaz de puerta de enlace común (CGI)" define parcialmente CGI usando C, [3] al decir que las variables de entorno "son accesibles mediante la rutina de biblioteca C getenv() o la variable entorno".
El nombre CGI proviene de los primeros días de la Web, donde los webmasters querían conectar sistemas de información heredados, como bases de datos, a sus servidores Web. El programa CGI fue ejecutado por el servidor y proporcionó 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 una colección de documentos, es decir, un conjunto de archivos que se pueden enviar a los navegadores web conectados al servidor. [8] Por ejemplo, si un servidor web tiene el nombre de dominio completo www.example.com y su colección de documentos se almacena en el sistema de archivos/usr/local/apache/htdocs/ local (su raíz de documentos ), entonces el servidor web responderá a una solicitud enviándola al navegador una copia del archivo (si existe).http://www.example.com/index.html/usr/local/apache/htdocs/index.html
Para páginas construidas sobre la marcha, el software del servidor puede diferir las solicitudes a programas separados y transmitir los resultados al cliente solicitante (generalmente, un navegador web que muestra la página al usuario final).
Estos programas normalmente requieren que se especifique alguna información adicional con la solicitud, como cadenas de consulta o cookies . Por el contrario, al regresar, el script debe proporcionar toda la información requerida por HTTP para una respuesta 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 sin formato). , 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 en el servidor que se esperaba que procesaran los datos y, en última instancia, devolvieran un resultado al navegador. Como resultado, existían incompatibilidades mutuas entre diferentes variantes del servidor HTTP que socavaban la portabilidad de los scripts .
El reconocimiento de este problema llevó a especificar cómo se debía llevar a cabo el intercambio de datos, lo que resultó en el desarrollo de CGI. Los programas generadores de páginas web invocados por el software de servidor que cumple con la especificación CGI se conocen como scripts CGI , aunque en realidad pueden haber sido escritos en un lenguaje que no es de scripting, como C.
La especificación CGI se adoptó rápidamente y sigue siendo compatible con todos los 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 para procesar formularios. Al principio de HTML, los formularios HTML normalmente tenían un atributo de "acción" y un botón designado como botón "enviar". Cuando se presiona el botón de envío, el URI especificado en el atributo "acción" se enviará al servidor con los datos del formulario enviados como una cadena de consulta. Si la "acción" especifica un script CGI, entonces se ejecutará el script CGI y el script, a su vez, generará una página HTML.
Un servidor web que admita CGI se puede configurar para interpretar una URL que sirve como referencia a un script CGI. Una convención común es tener un cgi-bin/ directorio en la base 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), entonces, 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 del terminal que inició el servidor web. Otra convención popular es utilizar extensiones de nombre de archivo ; por ejemplo, si a los scripts CGI se les asigna constantemente la extensión .cgi, el servidor web se puede configurar para interpretar todos esos archivos como scripts CGI. Si bien es conveniente y lo requieren muchos scripts preempaquetados, abre el servidor para atacar si un usuario remoto puede cargar código ejecutable con la extensión adecuada.
La especificación CGI define cómo la información adicional pasada con la solicitud se pasa al script. El servidor web crea un subconjunto de las variables de entorno que se le pasan y agrega detalles pertinentes al entorno HTTP. Por ejemplo, si se agrega una barra diagonal y nombres de directorio adicionales a la URL inmediatamente después del nombre del script (en este ejemplo, /with/additional/path), entonces esa ruta se almacena en la PATH_INFO variable de entorno antes de llamar al script. Si los parámetros se envían al script a través de una solicitud HTTP GET?and=a&query=string (un signo de interrogación añadido a la URL, seguido de pares parámetro=valor; en el ejemplo, ), esos parámetros se almacenan en la QUERY_STRINGvariable de entorno antes de llamar al script. El cuerpo del mensaje HTTP de solicitud , como los parámetros de formulario enviados a través de una solicitud POST HTTP , se pasan a la entrada estándar del script . Luego, el script puede leer estas variables de entorno o datos de la entrada estándar y adaptarse a la solicitud del navegador web. [9]
CGI se utiliza a menudo para procesar información de entrada del usuario y producir el resultado adecuado. Un ejemplo de un programa CGI es uno que implementa un wiki . Si el agente de usuario solicita el nombre de una entrada, el servidor web ejecuta el programa CGI. El programa CGI recupera la fuente de la página de esa entrada (si existe), la transforma en HTML e imprime el resultado. El servidor web recibe la salida del programa CGI y la transmite al agente de usuario. Luego, si el agente de usuario hace clic en el botón "Editar página", el programa CGI completa un HTML textareau otro control de edición con el contenido de la página. Finalmente, si el agente de usuario hace clic en el botón "Publicar página", el programa CGI transforma el HTML actualizado en la fuente de la página de esa entrada y lo guarda.
Los programas CGI se ejecutan, de forma predeterminada, en el contexto de seguridad del servidor web. Cuando se introdujeron por primera vez, se proporcionaron una serie de scripts de ejemplo con las distribuciones de referencia de los servidores web NCSA, Apache y CERN para mostrar cómo se podían codificar scripts de shell o programas C para hacer uso del nuevo CGI. Uno de esos scripts de ejemplo fue un programa CGI llamado PHF que implementó una guía telefónica simple.
Al igual que otros scripts de la época, este script hacía uso de una función: escape_shell_cmd(). Se suponía que la función desinfectaría su argumento, que provenía de la entrada del usuario y luego pasaría la entrada al shell de Unix, para ejecutarlo en el contexto de seguridad del servidor web. El script no desinfectó correctamente todas las entradas y permitió que se pasaran nuevas líneas al shell, lo que efectivamente permitió ejecutar múltiples comandos. Los resultados de estos comandos se mostraron luego en el servidor web. Si el contexto de seguridad del servidor web lo permitiera, los atacantes podrí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 desinfectados de los usuarios de la Web podrían conducir a la ejecución de código en un servidor Web. Debido a que el código de ejemplo se instaló de forma predeterminada, los ataques se generalizaron y dieron lugar a una serie de avisos de seguridad a principios de 1996. [10]
Para cada solicitud HTTP entrante, un servidor web crea un nuevo proceso CGI para manejarla y destruye el proceso CGI después de que se haya manejado la solicitud HTTP. Crear y destruir un proceso puede ser costoso: consume más tiempo de CPU y recursos de memoria que el trabajo real de generar la salida del proceso, especialmente cuando el programa CGI todavía necesita ser interpretado por una máquina virtual. Para una gran cantidad de solicitudes HTTP, la carga de trabajo resultante puede abrumar rápidamente al servidor web.
La sobrecarga computacional involucrada en la creación y destrucción de procesos CGI se puede reducir mediante las siguientes técnicas:
mod_perl, mod_phpy mod_python), complementos NSAPI y complementos ISAPI que permiten procesos de aplicaciones de larga duración que manejan más de una solicitud y se alojan en el servidor web.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 los detalles específicos de la aplicación, la cantidad de tráfico y la complejidad de la transacción; Estas compensaciones deben analizarse para determinar la mejor implementación para una tarea y un presupuesto de tiempo determinados. Los marcos web ofrecen una alternativa al uso de scripts CGI para interactuar con agentes de usuario.
{{cite journal}}: Citar diario requiere |journal=( ayuda )