CGI Common Gateway Interface

untitled

CGI (Common Gateway Interface), ejecución de binarios.

CGI no es un lenguaje. Los cgi-bin son programas que se ejecutan en el servidor, pueden servir para tratar información, como pasarela con una aplicación o base de datos o para generar documentos html de forma automática.

La interfaz de pasarela común (Common Gateway Interface, CGI) es un protocolo genérico que permite extender las capacidades de HTTP. Los programas en CGI añaden funcionalidad al servidor Web, funcionalidad que podría abrir agujeros de seguridad en el servidor, ya que una aplicación en CGI mal diseñada podría permitir acceso total o parcial al servidor.

Es una especificación para permitir a un servidor de WWW ejecutar un programa externo y devolver los resultados al navegador. Mediante esta interfaz es posible correr cualquier programa que se encuentre accesible al servidor, de modo que no hay límite para las tareas que se pueden realizar. El programa de CGI obtiene información del usuario a través de una "forma", que es un conjunto de botones, espacios de texto y menús que se despliegan en la pantalla de un navegador.

En general, es necesaria la presencia de dos elementos, una página Web en formato HTML con un formulario donde el usuario introduce sus datos, y un programa CGI en el servidor, que recibe y procesa los datos del usuario. Cuando la forma se encuentra llena, el usuario lo envía utilizando un botón. El servidor recibe los datos, los pasa al programa externo y éste devuelve los resultados de la operación, para que el servidor los regrese a su vez al usuario.

Las aplicaciones del CGI son numerosas: herramientas de búsqueda, formas de registro, libros de visitas, contadores de accesos, sistemas de bases de datos, grupos de discusión, personalización de páginas, tiendas y catálogos electrónicos, y más. La gran mayoría de las aplicaciones que existen en la WWW actualmente, dependen exclusivamente del CGI.

Como se vio con anterioridad, una de las principales utilidades de los cgi-bin es tratar los resultados de un formulario (FORM). Estos programas pueden ser escritos en cualquier tipo de lenguaje de programación y son ejecutados en el servidor cuando se realiza su referencia. Algo importante es que el programa debe ser ejecutable en el servidor, por tanto al ser el servidor una maquina UNIX, no se puede utilizar por ejemplo los compiladores de los PC, sino los del servidor. Los lenguajes más comunes para escribir estos programas son el lenguaje perl, C ó bien un script escrito en cualquier shell (csh, sh, ksh ó zsh).

Un script CGI puede ser escrito en cualquier lenguaje que pueda leer de STDIN, escribir en STDOUT, y leer variables de entorno como virtualmente cualquier lenguaje de programación. Algo importante es que los cgi-bin deben tener una extensión especial .cgi, o bien, encontrarse en un directorio especial llamado cgi-bin. Cuando se referencie en una pagina html un binario, cualquier fichero con la extensión cgi, en el servidor se ejecutará este programa y la salida se enviará al cliente de la WWW.

Objetivos al escribir CGI’s

Los objetivos que nos guiarán a la hora de escribir CGI's seguros se resumen en los siguientes:

Los programas SOLAMENTE deben ejecutar aquellas acciones para las que ha sido concebido.
No se debe revelar más información al cliente que la que DELIBERADAMENTE se desee suministrar.
No se debe confiar en la información procedente de los datos introducidos por el cliente.
Se debe minimizar el daño potencial al sistema en su conjunto si se produce un ataque con éxito.

Mecanismo de entrega y procesamiento de datos de un CGI

En la figura está representada de manera simplificada el proceso que tiene lugar desde que al usuario se le presenta el formulario de entrada de datos hasta que obtiene la página de resultado de procesar esos datos:

Al usuario se le presenta a través de su navegador una página en formato HTML que contiene un formulario, codificado mediante las etiquetas <FORM> y </FORM>. Una vez que el usuario ha rellenado los campos del formulario, pulsa el botón de enviar, que invoca al programa CGI en el servidor.
Los datos del formulario se envían al servidor utilizando bien el método POST o el método GET, cuyas ventajas/desventajas para la seguridad veremos próximamente.
Los datos llegan hasta el servidor a través de la Internet, donde la aplicación CGI invocada los procesa.
Una vez convenientemente procesados, el programa CGI debe ejecutar alguna acción o generar una respuesta, generalmente en la forma de una página en formato HTML, que será enviada de vuelta al navegador.
Se añaden las cabeceras HTTP necesarias y se envía de vuelta a través de Internet el archivo HTML con la respuesta a los datos del formulario convenientemente presentada.
El navegador Web recibe el archivo HTML y lo visualiza en pantalla. Es común que la página contenga alguna información relacionada con el resultado del procesamiento de los datos, junto con algún enlace para regresar a la página del formulario, en el paso 1.

Es importante resaltar que no es imprescindible la presencia de un formulario para invocar desde el navegador al CGI del servidor. Muchas veces, basta con pinchar en un enlace para llamar al CGI y también es posible llamarle directamente desde la ventana de URL, introduciendo el URL completo del programa CGI.

Qué lenguaje utilizar

A menudo se plantea la discusión de qué lenguaje resulta el más adecuado a la hora de escribir CGI's seguros. En una primera aproximación, puede considerarse a los lenguajes compilados como más seguros por las siguientes razones:

Impiden el acceso remoto al código fuente del CGI, lo cual limita las posibilidades de un hacker de conocer cómo funciona internamente el programa.
Los guiones escritos en lenguajes interpretados son más complejos y propensos a errores cuando crecen, aumentando la probabilidad de que contengan agujeros de seguridad.
Los lenguajes interpretados facilitan la labor de abrir shells, ejecutar comandos y capturar sus resultados, lo que constituye uno de los mayores riesgos potenciales de los CGI's. Por el contrario, en C supone un esfuerzo mayor invocar comandos del sistema y es más difícil que la entrada del usuario engañe al programa.

No obstante, no hay que olvidar que los lenguajes interpretados son más sencillos de entender y rápidos de probar (ya que no necesitan pasar por todo el proceso de compilación y enlazado), y además su manejo de cadenas es mucho más sofisticado, lo que los hace menos propensos a errores con búferes de texto.

Llamada a programas

Uno de los aspectos más potentes de la programación en CGI es la capacidad de las aplicaciones de invocar utilidades del sistema u otros programas, con la posibilidad de capturar su salida. Sin embargo, desgraciadamente, esta libertad puede convertirse en un arma de doble filo, ya que resulta igualmente sencillo subvertir los argumentos de esos comandos, de manera que se produzcan acciones inesperadas e indeseables.

Dependiendo del lenguaje de programación empleado, existen varias formas de invocar comandos:

En C, las funciones popen( ) y system( ) sirven para abrir un shell que procese los comandos que se le pasen como argumentos.
Por su parte, en Perl, además de las funciones anteriores, se dispone de open( ) con tubería, exec( ) y eval( ), así como de las comillas hacia atrás "`".

En la medida de lo posible se debe evitar abrir un subshell, pero en el caso de que fuera estrictamente necesario, ya que las acciones requeridas no se pueden realizar usando las capacidades del lenguaje de programación, entonces se debe evitar pasar como argumentos al proceso la entrada del usuario. Desgraciadamente, esto también es inevitable, por lo que se deberá filtrar la entrada que suministra, en busca de metacaracteres como `$|;>*<& ['\]"( ~?)\n\r.

No obstante, suele resultar más conveniente especificar una lista de caracteres permitidos que de caracteres peligrosos, ya que si te olvidas de especificar un carácter, no ocurre nada desastroso; mientras que si te olvidas de especificar un carácter peligroso, como los retornos de carro, se puede comprometer la seguridad de todo el sistema.

Los cgi-bin se podrán escribir con las instrucciones normales del lenguaje de programación pero hay ciertos aspectos a tener en cuenta:

Variables de entorno
Entrada de datos al cgi-bin
Salida de datos del cgi-bin

Variables de entorno

Para pasar datos el servidor al cgi-bin utiliza una serie de variables de entorno, que quedan definidas al ejecutar el script. Las variables de entorno más interesantes son:

REQUEST_METHOD—El método por el que se realiza la llamada al script, este puede ser GET o POST como se explicó anteriormente cuando se habla de los formularios.

PATH_INFO—El cgi-bin puede ser llamado directamente desde el cliente, en esta variable se incluirá toda la información que siga al nombre del cgi-bin, por ejemplo:

http://www2.uca.es/binarios/cgibin.cgi/camino/fichero

PATH_INFO = /camino/fichero

Será la información adicional que se añade tras el nombre de cgi-bin.

La información que se incluye será pasada de forma codificada al cgi-bin, de forma que los espacios se convierten en signos '+' y los caracteres especiales se codifican de la forma %xx, donde xx el código ASCII en hexadecimal del caracter. Esto debe ser tenido en cuenta cuando se interprete la información obtenida en formato URL.

PATH_TRANSLATED—Una versión decodificada de PATH_INFO, obtiene el camino y lo convierte de camino virtual (en referencia del servidor) a camino real (camino completo).

SCRIPT_NAME--Nombre por el que fue llamado el cgi-bin.

QUERY_STRING—La información que sigue al símbolo ? en la URL que referencia al cgi-bin. Será algún tipo de consulta que se realice al cgi-bin. No necesita ser decodificada de ninguna manera. Cuando se utiliza el método GET las variables del formulario se pueden interpretar con esta variable de entorno. El formato en que se envían estas variables es el siguiente:

?variable1=valor1&variable2=valor2& ... &variablen=valorn

REMOTE_HOST—El ordenador desde el que se ejecuto el cgi-bin.

REMOTE_ADDR—Dirección IP del ordenador remoto que ejecuto el cgi-bin.

CONTENT_LENGTH—El número de caracteres enviados por el cliente al cgi-bin.

HTTP_USER_AGENT—El cliente de la WWW que ejecuta el cgi-bin,

el formato general es:

programa/versión libreria/versión

El cgi-bin podría enviar un distinto código HTML según cada cliente.

Entrada de datos al cgi-bin

Para los formularios que utilizan el método POST, la información es enviada al cgi-bin por la entrada estándar (stdin). El servidor envía las variables de entorno CONTENT_LENGTH y CONTENT_TYPE indicando la longitud y el tipo de datos enviados. El servidor no esta obligado a enviar una marca de final de fichero tras los datos enviados, por tanto la variable CONTENT_LENGTH debe ser tenida en cuenta para determinar la cantidad de datos enviados. CONTENT_TYPE suele contener el valor application/x-www-form-urlencoded, que indica que se trata de información con codificación URL.

En esta codificación como se vio antes los espacios se convierten en signos '+' y los caracteres especiales se codifican de la forma %xx, donde xx el código ASCII en hexadecimal del carácter. Por tanto esto debe ser tenido en cuenta cuando se interpreten los datos enviados del formulario. Las variables del formulario se enviarán de la forma:

variable1=valor1&variable2=valor2& ... &variablen=valorn

Salida de datos del cgi-bin

El cgi-bin debe enviar sus datos a la salida estándar (stdout), esta salida puede ser un documento generado por el cgi-bin o instrucciones al servidor para obtener el documento correcto.

La salida del cgi-bin debe comenzar con una pequeña cabecera que identificará al documento. Las directivas que definen esta cabecera serán:

Content-type: Es el tipo MIME del documento que se retorna. Si tuviera el valor text/html la salida se interpretaría como código html. Por tanto la salida del cgi-bin podría contener instrucciones HTML que serian interpretadas correctamente por el cliente. Otros valores que puede tomar son: text/plain para texto normal ó image/gif, la salida se interpreta como una imagen GIF.

Por ejemplo:

printf ( "Content-type: text/html\n\n" );

Sería el comienzo de la salida de cgi-bin escrito en C que comienza a generar código html.

Location: Indicará al servidor que se esta enviado la referencia a un documento en lugar del documento en sí. Si el valor es una URL, el servidor indicará al cliente que debe realizar un redireccionamiento a esa dirección. Esta permitido el uso de información adicional (PATH_INFO) y la directiva ?, pero no la directiva # para indicar un punto determinado dentro de un documento.

Status: Indicará un código de estado para indicar errores. El formato será nnn xxxxxxx, donde nnn es un número de tres dígitos y xxxxxxx es una cadena de caracteres.

Tras la cabecera se incluirán dos caracteres de retorno de carro (\n), siendo obligatorio para que sea bien interpretada la cabecera de cgi-bin, si no se respeta esto la salida del cgi-bin podría indicarnos el error "Server Error 500". Después de definida la cabecera se podrá generar la salida del cgi-bin, que se interpretará según el valor dado a Content-type.

Dónde poner los CGI

Existen dos prácticas generalizadas. La primera de ellas, y más recomendable, consiste en designar un único directorio donde se almacenarán todas las aplicaciones en CGI, típicamente el directorio cgi-bin, con privilegios limitados, de manera que los usuarios locales no puedan instalar, eliminar ni editar programas. Por el contrario, la segunda permite la ejecución de cualquier fichero con la extensión, p.e., .cgi como un programa CGI, lo cual lo considero desaconsejable. La primera práctica presenta las siguientes ventajas:

Facilidad de seguir la pista a los CGI's, especialmente en servidores con muchos usuarios, con capacidad de escribir sus propios CGI's. Si cada uno los almacenase en su propio directorio y se produjera una brecha de seguridad, sería más difícil localizar al culpable.
Protección frente a hackers creando sus propios CGI's, ya que aunque puedan acceder a la cuenta de un usuario no gozarán de privilegios para poner su propio CGI, cosa que sí podrían hacer si se ejecutasen como CGI los programas de una extensión determinada.
Permite borrar de golpe y cómodamente todas las copias de seguridad, ya que están agrupadas en un único directorio y no hay que rastrearlas por todo el servidor.
Impide que se puedan leer las copias de seguridad, ya que al ser la política el ejecutar cualquier fichero el directorio cgi-bin, las copias de seguridad también se ejecutarán. En el otro caso, al ejecutarse sólo los ficheros con determinada extensión, las copias de seguridad se recuperarían como un fichero de texto, lo que permitiría a un atacante estudiarlas en busca de debilidades.

Para que sea posible ejecutar el binario (cgi-bin), será necesario que el fichero tenga los permisos de forma correcta, Tu programa CGI debe ser ejecutable para ese nombre de usuario, además de poder ser leído si es un script Perl o un shell script. En Unix, fija los permisos correctos con "chmod 750 *.cgi" (o "chmod 755 *.cgi", si tu servidor no tiene accesos de grupo a tus archivos-- intenta ambos, o pregunta a tu webmaster).

Ejemplo—tendrá que ejecutar en Unix el siguiente comando:

www2> chmod 755 programa.cgi

Con esto el programa será ejecutable por el servidor.

Si tu script no corre:

Para scripts Perl, verifica la sintaxis con "perl -cw myscript.cgi".
Asegúrate que la ruta al intérprete Perl (o shell) es correcta en la primera línea del script. Por ejemplo, encuentra el intérprete Perl con el comando Unix "which perl".
Por supuesto, asegúrate que tu archivo HTML llama correctamente al script ya sea una llamada relativa o absoluta.
Para pistas, córre el script desde la línea de comandos y vé cómo falla. Esto no siempre funciona, porque las variables de entorno CGI no están correctamente fijadas. Avanza un poco más probando una copia de tu código fuente. Algunas herramientas, como las del módulo Perl CGI.pm proveen caminos para depurar scripts CGI desde la línea de comandos.

Cómo configurar el servidor, Cómo correr el servidor

Cuando se ejecuta un CGI, corre con el UID del propio servidor Web, lo cual significa que un CGI con errores permitiría a un atacante correr otros programas con el UID del servidor. En estas circunstancias, resulta evidente que el servidor Web nunca deberá correr como root. Aunque el servicio de Web, típicamente en el puerto 80, debe ser iniciado por el root, el fichero http.conf no debería contener la línea "User root". Si lo hiciera, entonces cualquier guión que se ejecutase en el servidor Web lo haría como el superusuario, con los riesgos que eso conllevaría.

Una solución común es correr el servidor como el usuario genérico nobody, que carece de privilegios. Si bien representa una mejora respecto a root, el inconveniente que presenta es que otros procesos corren asimismo como nobody, por lo que todos gozarían de los mismos privilegios. En su lugar, es más conveniente correr el servidor como un usuario real, por ejemplo www, perteneciendo al grupo www.

Enviando un Archivo Existente como Respuesta

Si tu respuesta HTML siempre es la misma, o si quieres responder con uno de los archivos existentes, puedes encontrar útil el encabezado de respuesta "Location:". Úsalo para redireccionar el navegador a otro URL.

Como ejemplo, si tu script CGI escribe la siguiente línea a STDOUT:

Location: response.html

seguida de una línea en blanco, entonces el navegador remoto obtendrá a response.html y lo tratará como respuesta de tu script CGI. Puedes redireccionar al navegador a un URL ya sea relativo o absoluto.

En esta situación, no imprimas el encabezado de respuesta "Content-type:".

Regresando una Imagen u Otra Respuesta No-HTML de un Script CGI

La mayoría de los scripts CGI regresan datos HTML, pero puedes regresar cualquier tipo de datos que tú quieras. Solamente usa el tipo MIME correcto en la línea "Content-type:", seguida por la línea en blanco requerida, seguida por los datos de los recursos que estás enviando de regreso. En el caso de los archivos HTML, esos datos es el texto HTML.

En el caso de imágenes, audio o video son datos binarios. Por ejemplo, para responder con un archivo gif, usa:

Content-type: image/gif

GIF89a&%*$@#--- contenido binario del archivo GIF aquí ---$(*&%(*@#......

Tu archivo HTML puede cargar una imágen generada por script con

Uno de mis ejemplos favoritos es was el Render Interactivo de Gráficas, que renderea íconos 3-D de acuerdo con los colores, forma, textura, iluminación, etc. que definas. Puedes usar el ícono de resultado en tus páginas Web como balas de lista o reglas horizontales mejoradas.. Nota: Este sitio ha perdido temporalmente su lugar; el autor dice que éste será eventualmente el punto de la nueva localización.

Tipos MIME

Los tipos MIME son cadenas de caracteres estándar de caso sensitivo que identifican el tipo de datos usado a través de Internet para muchos propósitos. Comienzan con el tipo general de datos (como text, image, o audio), seguido por un slash, y terminando con el tipo específico de datos (como html, gif, or jpeg). Los archivos HTML se identifican con text/html, y los GIFs y JPEGs se identifican con image/gif y image/jpeg.

Ganando Más Control con Scripts de Encabezado No-Analizados

Normalmente, cuando tu script CGI imprime los encabezados "Content-type:", "Location:", u otros, el servidor analiza estos encabezados y genera la respuesta HTTP apropiada para el usuario. Ocasionalmente puedes querer un control más fino sobre la respuesta HTTP. La mayoría de los servidores Web soportan scripts de encabezados no-analizados (o "NPH"), que generan una respuesta HTTP completa y omite el análisis normal del servidor.

Para usarlos, necesitas saber un poco de HTTP-- específicamente, los formatos de líneas de estado y líneas de encabezado.

En tu script de encabezado no-analizado, solamente imprime el HTTP completo de las líneas de estado y encabezado donde un script normal imprimiría la línea "Content-Type:". Incluye la línea en blanco de trailer. Cualquier cosa que imprima tu script se envía al usuario verbatim, como la respuesta HTTP completa, sin modificaciones del servidor.

Nombra tus scripts NPH comenzando con algo con "nph-", como "nph-miscript.cgi"; cada script cuyo nombre comienza con "nph-" será manejado como un script NPH. Esto funciona en la mayoría de los servidores, inlcuyendo Apache y NCSA. Otros servidores pueden usar esquemas diferentes para identificar scripts NPH; lee los documentos o pregunta a tu webmaster.

Como un ejemplo de un script NPH, ve CGIProxy.

Desventajas

La mayor desventaja es que es necesario conectarse al servidor cada vez que se quiera ejecutar un programa y además debe crearse una página nueva para mostrar los resultados. Esto afecta seriamente el tiempo de respuesta y hace muy difícil la programación de algunas aplicaciones, como charlas en tiempo real y juegos. Además, para utilizar el CGI se requiere acceso directo al servidor y conocimiento de las especificaciones de la interfaz y de algún lenguaje de programación como C, Perl o Visual Basic.

Dónde está el riesgo

Cuando los usuarios envían un formulario o invocan un CGI de alguna otra forma, en definitiva se les está permitiendo ejecutar remotamente un programa en el servidor. Es más, puesto que la mayoría de CGI's aceptan datos de la entrada de usuario (bien después de rellenar un formulario o directamente desde la línea de URL), en esencia se les brinda a los usuarios la oportunidad de controlar cómo se ejecutará el CGI, de manera que podrían intentar la introducción de una serie de parámetros inesperados hábilmente manipulados para que el CGI funcionase maliciosamente.

Vulnerabilidad de los CGI’s

El punto vulnerable de la programación en CGI, es decir, la amenaza que representan para la seguridad del servidor, es doble:

Por un lado, la posibilidad de que el CGI sea engañado por la entrada del usuario para que ejecute comandos imprevistos, pudiendo llegar a causar graves daños en el servidor;
del otro, la posibilidad de revelar innecesariamente información acerca del servidor, que permitirá al atacante conocer mejor la configuración del sistema y estar así mejor equipado para buscar posibles agujeros por los que colarse.

Nunca fiarse del usuario

Uno de los medios de ataque más utilizados por los hackers consiste en enviar parámetros a un programa, de manera que no pueda procesarlos y entre en un estado inestable o bien ejecute acciones indeseadas.

El ejemplo más explotado en el mundo de los CGI es la manipulación de formularios: los formularios normalmente presentan una serie de campos dentro de los cuales se puede escribir texto, así como listas desplegables, botones de selección, etc. Un error muy común entre los programadores novatos consiste en asumir que la entrada del programa CGI provendrá de los datos rellenados por el usuario a partir del formulario.

Sin embargo, resulta muy sencillo cargar en el disco local la página HTML con el formulario y manipularla a voluntad (por ejemplo variando los campos ocultos), o bien directamente introducir los datos manipulados en la ventana del URL, modificando los argumentos esperados por el CGI. Por lo tanto, debe tenerse en cuenta lo siguiente:

Si se crea una lista de selección, la entrada de ese campo puede no ser una de las opciones de la lista.

Si se especifica la máxima longitud de un campo, el usuario podría enviar más caracteres de los prefijados, manipulando el formulario o invocando al CGI directamente.

Los campos que el CGI espera encontrar en la variable QUERY_STRING podrían ser distintos de los presentados por el formulario, ya que el usuario los puede alterar, añadiendo o borrando campos.

Los valores de las variables de entrada al CGI podrían contener caracteres especiales, como <, >, ¡, -, #, @, ', `, /, etc. Esto incluye a variables de entorno como el HTTP_REFERER, nombre de host, dirección de host, etc.

El usuario puede ver los datos presentes en campos ocultos.

Si se utilizan cookies para mantener el estado de la sesión en el servidor, el programa CGI podría recibir cookies que nunca creó.

Caminos y nombres de ficheros

Caminos

No se debe confiar en los caminos contenidos en la variable PATH a la hora de ejecutar ciertas acciones, ya que esa variable podría contener cualquier cosa, truco comúnmente usado por atacantes para que la variable apunte al programa que desean que sea ejecutado por el CGI en lugar del esperado. Por este motivo es mejor utilizar caminos completos.

En su defecto, si se necesitan caminos relativos, se puede especificar el valor de la variable PATH al principio del CGI.

Por idénticas razones, es conveniente no añadir "." en el camino.

Nombres de ficheros

Presumiblemente, los nombres de ficheros que aparecen codificados en el programa CGI son seguros, siempre que no se usen caminos relativos (los servidores NT no permiten caminos relativos). Por esta razón no se debe confiar en las variables PATH o PATH_INFO. También se puede considerar el prohibir caracteres como "..", para evitar que se puedan producir ataques que obliguen a abrir archivos confidenciales (v. ejemplo). Asimismo, suele constituir una buena práctica el asegurarse de que los archivos creados son los que se pretendía crear.

Si el programa CGI maneja datos confidenciales, suele convenir no utilizar el directorio /tmp, ya que podría quedar en él información valiosa.

Llamada a programas

Uno de los aspectos más delicados de la programación con CGI, es la llamada a otros programas o comandos del sistema desde la aplicación CGI. Un ejemplo típico sería el enviar un correo a un usuario a la dirección que éste ha introducido a través de un formulario. Para ello puede invocarse al programa sendmail, abriendo un shell mediante diversos mecanismos. Ya veremos cómo estas llamadas pueden ser subvertidas por un atacante, de manera que se ejecuten otros comandos además del esperado, con el fin de causar daños al sistema u obtener información sobre el mismo.

Cómo enviar los datos

GET y POST son dos métodos empleados para enviar los datos de los formularios desde el navegador al servidor Web, especificados mediante la directiva METHOD. La principal diferencia entre POST y GET es que el CGI recibirá los datos enviados con POST leyendo la entrada estándar, mientras que los enviados con GET se recibirán por líneas de comandos y la variable de entorno QUERY_STRING. Desde un punto de vista puramente práctico, debido a que muchos sistemas operativos ponen límite a la longitud de la línea de comandos, suele ser mejor usar POST, reservando GET para formularios con pocos datos.

Desde el punto de vista de la seguridad la verdad es que da igual uno u otro, si bien las peticiones enviadas mediante GET quedan registradas en los ficheros de registro, con todos sus argumentos, por lo que si se enviase información confidencial sin cifrar, estos datos quedarían en el fichero log, donde a lo mejor alguien no autorizado podría husmear posteriormente. O lo que es peor, agujeros como el que descubrió Brumleve en Netscape, exponen el cache, con toda la información que almacena, como todos los URLs que han sido solicitados, por supuesto con los datos con que se rellenaron los formularios, como podría suceder con el número de la tarjeta de crédito.

Tabla comparativa entre GET y POST

Acción	GET	POST
¿Añade los datos con que se rellena el formulario al URL solicitado?	S	N
¿Limitado en la cantidad de datos que se pasan al URL solicitado?	S	N
¿Usado típicamente fuera de formularios HTML?	S	N
¿Utiliza la variable de entorno QUERY_STRING del servidor?	S	N
¿Envía los datos al URL solicitado en una transacción separada con el servidor?	N	S
¿Utiliza las variables del servidor CONTENT TYPE y CONTENT LENGTH?	N	S
¿Puede escribir datos en el servidor?	N	S

Consejos y Orientaciones (Consejos de Lincoln Stein)

¿Cómo decir si un CGI es seguro?

1. ¿Es muy complejo?

2. ¿Lee o escribe ficheros en el servidor?

3. ¿Interactúa con otros programas del sistema?

4. ¿Corre con privilegios suid?

5. ¿Se valida la entrada procedente de formularios?

6. ¿Se emplean nombres de camino explícitos?

Preguntas tomadas de la FAQ sobre seguridad en WWW.

A evitar

Nunca se debe pasar como argumento a un comando del shell la entrada del usuario sin filtrarla antes.
Ni siquiera se puede confiar en las variables de entorno.
No revelar demasiada información sobre el sistema, con servicios como:
finger
w
ps
En lenguajes compilados, evitar suposiciones acerca del tamaño de la entrada del usuario, ya que en caso contrario pueden ocurrir desbordamientos de búfer.

No fiarse de los campos ocultos

Los campos ocultos se denominan así porque no se visualizan en la pantalla del navegador, pero sí se ven si se lista el código fuente en HTML de la página. Por lo tanto, cualquiera puede cargar la página en su disco local y editarla, modificando los valores de los campos ocultos. En consecuencia, nunca se deben utilizar para contener información confidencial ni confiar en ellos para almacenar información sensible (como precio de un producto). El servidor deberá contrastar la información recibida procedente de los campos ocultos.

No fiarse del lugar de ejecución

Como ya se ha dicho, los CGI's no tienen por qué ejecutarse necesariamente desde el formulario donde aparecen. Pueden mandarse ejecutar directamente desde la ventana de URL, por lo que podrían faltar parámetros o estar manipulados.

Script de correo CGI

Uno de los usos más comunes de un script CGI es enviar por correo datos a una dirección de email. Así que aquí está un simple script que hace precisamente eso, escrito en Perl, llamado mailer.pl.

Haz estos cambios al script antes de ponerlo en su lugar:

Asegúrate que la ruta a tu programa servidor de perl es correcta en la primera línea. Usualmente encuentras esto con el comando Unix "which perl".
Cambia las dos variables $mailprog y $recipient para ajustarse al programa de correo de tu servidor y tu dirección de correo respectivamente.
... seguramente puedes incluir una salida HTML más imaginativa de la que yo incluí.

Formulario simple:

Para añadir un formulario en su página usted deberá escribir el siguiente código en su página:

<HTML>

<BODY>

<CENTER><H1> Mi primer formulario</H1></CENTER>

<H3>Introduzca su nombre</H3>

<H3>Introduzca su dirección de Correo Electrónico</H3>

<H3>Indique su Hobby</H3>

<INPUT TYPE="radio" NAME="Hobbys" VALUE=" Deporte"> Deporte

<INPUT TYPE="radio" NAME="Hobbys" VALUE=" Música"> Música

<INPUT TYPE="radio" NAME="Hobbys" VALUE=" Cine">Cine

<<h3>su Edad </H3>

<OPTION>Menos de 15</OPTION>

<OPTION>Menos de 25</OPTION>

<OPTION>Menos de 35</OPTION>

<OPTION>Menos de 50</OPTION>

</SELECT><BR>

<i> La dirección a la que van los datos

debe rellenarse en el siguiente campo</i><BR>

<i>Al ser del tipo Hydden (oculto) el usuario que

rellena el formulario no la ve, por lo que no la

puede modificar, si se quiere dar opción al usuario de

cambiarla, debe especificarse como tipo Text</i>

<H3>Y por último los botones </H3><BR>

</FORM>

</BODY>

</HTML>

Contadores

Añadir un contador resulta extremadamente sencillo. Tan sólo deberá insertar el contador como si de una imagen se tratase (realmente lo es) con la salvedad de añadir una serie de parámetros:

Para identificar el contador debe asignarle un nombre, que debe coincidir con su nombre de usuario.
Escoger el formato de los números que aparecerán
Suponiendo que su nombre de usuario fuera juan usted tendría que insertar esta línea:

Además, usted puede elegir entre diferentes formatos de números. Estos son los formatos que hay a su disposición:

57chevy

emboss

fatpt

katt011

katt078

odb

pdw

fuego

thunder

Por lo tanto si usted quiere utilizar el tipo de letra Katt011, y si su nombre de usuario es juan, la línea que deberá introducir en su página sería:

Hiperenlaces (links) en menu desplegable

Para añadir un link en menú desplegable en su página usted deberá escribir el siguiente código:

<CENTER><H1> Mi primer Link en un Menu desplegable<H/1></CENTER>

<OPTION SELECTED VALUE="http://www.futurnet.es">Futurnet

<OPTION SELECTED VALUE="http://www.ole.es">OLE

<OPTION SELECTED VALUE="http://www.yahoo.com">Yahoo

<OPTION SELECTED VALUE="http://www.lycos.com">Lycos

</SELECT>

</FORM> </BODY></HTML>

Enviando Datos de Formas por Correo sin CGI

Existe una forma bastante pobre de enviar por correo datos de una forma que solamente usa HTML: en la etiqueta <form>, fija el atributo action a "mailto:" URL, y el atributo enctype a "text/plain". La mayoría de los navegadores manejan esto correctamente, por ejemplo, enviar datos en un mensaje de correo. Por ejemplo,

Existen desventajas: no puedes controlar el formato del texto enviado, y no puedes enviar una respuesta de regreso al usuario. Asímismo no todos los navegadores soportan este estilo de etiqueta <form>.

Como crear un CGI en Jet y ponerlo en tu página

Voy a describir aquí los pasos que uso yo para compilar, copiar y ejecutar un CGI en C y en PERL. Se supone que eres cliente de Jet Internet. Si no lo eres, puede que los pasos a seguir sean diferentes pero no deberían variar mucho. Si tienes algún problema, consulta con tu proveedor.

Si usas C...

Compilando tu CGI

Para compilar el fichero en el servidor, hay que pedir amablemente a los de jet que nos den una cuenta personal en users.jet.es para compilar CGIs. Una vez obtenido el permiso, podemos seguir con el ejemplo. Tenemos el fichero 'prueba.c' en el directorio c:\pruebas.

Contenido del fichero 'prueba.c':

#include<stdio.h>

main()

{

printf("Content-type: text/html\n\n");

printf("¡Esto funciona!");

}

Este fichero imprime crea una página web en la que pone:

¡Esto funciona!

Fijaros que en un CGI lo primero que hay que poner es la cabecera, en este caso : Content-type: text/html\n\n

El '\n' es un retorno de linea. Siempre debe de haber 2.

Ahora nos conectamos con un programa de FTP (recomiendo el FTP Cute) al directorio que se nos ha asignado en users.jet.es

Copiamos el fichero 'prueba.c' en formato ASCII al directorio de users.jet.es que se nos haya asignado.

Una vez copiado y sin cerrar el FTP, abrimos el Telnet. El Telnet lo puedes encontrar en tu disco duro en C:\WINDOWS si usas Windows 95. Una vez ejecutado, nos conectamos a users.jet.es

Después de pasar por la petición de clave, ponemos 'dir' y pulsamos return.

Si lo hemos hecho todo bien, deberíamos de ver nuestro fichero 'prueba.c' en el directorio.

Ahora tecleamos 'gcc -o prueba.cgi prueba.c -s' para compilar el fichero.

'gcc' invoca al compilador de ficheros C

'-o prueba.cgi' le dice el nombre del fichero a crear. Si nos olvidamos de este parámetro, obtendremos un fichero llamado 'a.out'. Si este es el caso, podemos teclear 'mv a.out prueba.cgi' para cambiarle el nombre. 'prueba.c' es el nombre del fichero que vamos a compilar. '-s' indica al compilador que reduzca todo lo posible el fichero de salida.

Después de la compilación y si tecleamos dir, deberíamos ver 2 ficheros: 'prueba.c' y 'prueba.cgi'. Salimos del Telnet.

Copiando el CGI a tu página

Debemos de copiar el fichero 'prueba.cgi' al directorio de nuestra página web. Si todavía tenemos abierta la sesión FTP sólo hay que pulsar el botón actualizar sesión.

Ahora copiamos el fichero 'prueba.cgi' a nuestro disco duro. Podemos cerrar después la sesión FTP.

Abrimos otra sesión FTP, esta vez hacia el directorio de nuestra página web y copiamos el fichero 'prueba.cgi' allí.

Ya tenemos el CGI en nuestra página web. Si ahora vamos a un navegador y tecleamos la dirección donde se encuentra el CGI lo ejecutaremos. Ejemplo:

http://www.jet.es/gregorio/prueba.cgi

Sin embargo recibiremos un molesto error. Tranquilos, no pasa nada. Ahora lo solucionamos.

Darle permiso de ejecución al CGI para ejecutarlo

Los sistemas UNIX tiene activada una opción por defecto que anula la posibilidad de ejecución de cualquier cosa a no ser que le dado a nuestro fichero un permiso especial. Por eso antes recibíamos el molesto mensaje de error.

Para darle permiso, se puede usar el programa de FTP. En el caso del FTP Cute, una vez vemos el fichero al que queremos darle el permiso de ejecución, clickeamos en el con el botón derecho del ratón y seleccionamos 'File Attributes' del menú emergente.

Ahora hay que darle permiso de lectura o lectura/escritura a nuestro CGI 'prueba.cgi'

Deberíamos recibir un mensaje advirtiéndonos que hemos cambiado los atributos de un fichero.

Ahora si ejecutamos el CGI desde nuestro navegador, deberíamos ver el esperado mensaje "¡Esto funciona!".

Si usas PERL...

Creando tu CGI

Como el Perl no es un lenguaje compilado como el C, nos saltaremos la ardua tarea de compilar nuestro fuente. Simplemente, crearemos un fichero de texto llamado prueba.txt. DEBERIAMOS usar el procesador de textos más simple que tengamos a fin de que no nos salve carácteres extra en el fichero como hacen el Wordperfect o el Works. Se supone que vamos a usar el Notepad de Windows 95 (también sirve el EDIT del MS-DOS siempre que no usemos carácteres españoles como los acentos o la eñe).

Contenido del fichero prueba.txt:

#!/usr/bin/perl

print "content-type: text/html\n\n";

print "<HTML>\n";

print "<HEAD>\n";

print "<TITLE>Aprendiendo a crear CGIs</TITLE>\n";

print "</HEAD>\n";

print "<BODY>\n";

print "Enhorabuena. Acabo de crear un CGI ¡y funciona!\n";

print "</BODY></HTML>\n";

Fijaros que en un CGI lo primero que hay que poner es la cabecera, en este caso : Content-type: text/html\n\n

El '\n' es un retorno de linea. Siempre debe de haber 2.

Copiando el CGI a tu página

Debemos de copiar el fichero 'prueba.txt' al directorio de nuestra página web. Abrimos una sesión FTP hacia el directorio de nuestra página web y copiamos el fichero 'prueba.txt' allí.

Ya tenemos el CGI en nuestra página web. Si ahora vamos a un navegador y tecleamos la dirección donde se encuentra el CGI lo ejecutaremos. Ejemplo:

http://web.jet.es/gregorio/prueba.txt

Sin embargo, veremos el fuente del fichero como si fuese un texto normal. Tranquilos, no pasa nada. Ahora lo solucionamos.

Solucionando los problemas

La respuesta es sencilla: el navegador no sabe que eso es un CGI. Pues no tenemos más que cambiar la extensión de txt por cgi. La razón de no haberlo hecho antes, es que nuestro programa de FTP DEBE transferir los archivos con formato ASCII, es decir, simples ficheros de texto, si intentamos copiar directamente el fichero con el nombre prueba.cgi, casi seguro que no nos va a funcionar porque lo intenará transferir en formato BINARIO.

En los sistemas UNIX, ningún programa funciona hasta que le demos permiso de ejecución. Para darle permiso, se puede usar el programa de FTP. En el caso del FTP Cute, una vez vemos el fichero al que queremos darle el permiso de ejecución, pinchamos en el con el botón derecho del ratón y seleccionamos 'File Attributes' del menú emergente.

Ahora hay que darle permiso de lectura o lectura/escritura a nuestro CGI 'prueba.cgi'

Deberíamos recibir un mensaje advirtiéndonos que hemos cambiado los atributos del fichero.

Si ejecutamos ahora el CGI desde nuestro navegador, deberíamos ver el esperado mensaje de enhorabuena.

Cómo probar un CGI en casa

Un CGI que cojas de cualquier sitio no te va a funcionar a la primera. Las diferencias entre las configuraciones de los servidores hacen algunas veces imposibles de "portar" un programa de un servidor a otro.

Sobre todo la diferencia entre servidores Windows y Unix, algunas veces es tremenda. De hecho si coges un CGI en Perl y te funciona en un servidor Unix, lo tienes que cambiar casi por completo para que te funcione con, digamos, el WebSite. La mayor cosa que hay que tener en cuenta, es que el salto de línea del Perl para Unix es diferente al del para Windows.

Yo lo he probado, y después de más de cinco horas (a lo mejor soy un poco torpe) he conseguido poner un contador que me funciona en Jet a la perfección. Es decir, a no ser que te montes tu servidor Unix en casa no hay forma humana para probar los CGI. Justamente por esta razón se hacen CGIs en Perl, ya que no se tiene que compilar el (o los) ficheros cada vez que se haga una modificación (normalmente porque no funciona el CGI). Por esta misma razón (la de no tener que compilar) es bueno el Perl.

Por cierto: el PERL esta disponible para (casi) todas las plataformas, y esta hecho para el manejo de "cadenas".

Usando el Website

¿Cómo puedo probar CGIs escritos en Perl en un servidor WEB como el Website...?

Aquí va un ejemplo para el WebSite.

Crea el fichero hello.pl en el directorio website\cgi-shl que contenga el siguiente texto:

---

require "cgi-lib.pl";

print &PrintHeader;

print '<html>Hello World!</html>';

---

El archivo cgi-lib.pl esta en el directorio website

Crea el fichero hello.htm en el directorio website\htdocs

---

<html>

<body>

</form>

</body>

</html>

---

Una vez que hayas creado los ficheros y tengas el Website activado, teclea esta dirección en tu navegador:

http://localhost/hello.htm

NTPerlb

El NTPerlb es un intérprete Perl para Win32. Un script en Perl se puede probar en Windows95 o NT. El único problema es pasarle los parámetros: con GET es fácil en NT 4 pero en Windows 95 no se pueden meter '=' en las variables de entorno. Con POST hay que poner el CONTENT_LENGTH.

El NTPerlb se puede encontrar en cualquier parte. Puedes buscar en http://ftpsearch.ntnu.no/ftpsearch .

El NTPerlb se puede ejecutar sin tener un servidor web, con lo que se puede probar un CGI en Perl casi del todo antes de ponerlo en una página.

Formularios caseros

¿Hay alguna forma de mandar un formulario sin usar CGIs?

Sí, pero el formulario sólo funcionará si usas Netscape 3.0 o Internet Explorer 4.0 y versiones posteriores. Como ya sabrás, en la etiqueta FORM tienes que decirle un método a usar. Imagínate lo siguiente usando un CGI:

Luego tendrías que pasarle al CGI un parámetro con la dirección a la que mandas el email. Para hacerlo de forma casera, cámbialo por esto:

¿Qué son?

Las directivas de Server-Side Includes (SSI) constituyen poderosas herramientas para aumentar la productividad del programador, ya que permiten al servidor modificar automáticamente el documento solicitado antes de ser enviado al navegador del cliente. Su propósito principal es insertar dentro de las páginas Web el contenido de ficheros de texto, información dinámica sobre ficheros (como por ejemplo su tamaño) o la salida resultante de la ejecución de ciertos comandos del sistema ya preseleccionados o libres.

Los Server-Side Includes pueden contener a su vez otros Server-Side Includes, de forma que se puede llegar a introducir una cantidad enorme de texto en una página con la inclusión de un único comando.

Los Server-Side Includes insertan el texto en el fichero exactamente en el mismo sitio donde aparecen. En otras palabras, se reemplazan a sí mismos en el instante en que se sirven las páginas que los contienen.

Peligros

En la práctica, los Server-Side Includes permiten toda clase de trucos cuando se combinan con CGI’s que modifican páginas Web, como en el escenario del libro de visitas: los visitantes a una página disponen de un "libro" en el que pueden dejar un texto, que en principio podría incluir etiquetas en HTML y también, si la entrada no se filtra, includes como los siguientes:

Soluciones

Existen varias soluciones para paliar estas amenazas.

La más drástica pasa por deshabilitar completamente los SSI del servidor.
Otra solución menos drástica consiste en deshabilitar específicamente la ejecución de comandos con exec.
Otra posibilidad es utilizar como archivos con SSI sólo los que posean una extensión determinada, como por ejemplo .shtml. De esta forma, mientras las páginas posean extensión .html no existe riesgo de ataque mediante fallos en CGI, ya que se limitan a los archivos con extensión .shtml.

En el caso del libro de visitas, para que el ataque tenga éxito, el libro debería tener extensión .shtml, lo cual resulta muy improbable.

Por último, se pueden mantener los SSI y velar en los programas CGI por que no se produzcan entradas indeseadas, filtrando caracteres como ;, <, >, ¡, -, #, @, ‘, `, /, etc.