TRABAJO

DE

programación

CGI

INTRODUCCIÓN

El lenguaje CGI, es un programa que permite extender las capacidades de HTTP.

Esta es la oportunidad de conocer la distinta funcionalidad al servidor Web.

A lo largo del trabajo hablaremos de aplicaciones y programas en CGI, también veremos como funciona el mecanismo de entrega y procesamiento de datos en un programa CGI. Uno de los aspectos mas 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 inesperadas e indeseables.

QUE ES CGI

La interfaz de paralela 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.

A través de este trabajo hablare en general de aplicaciones y programas en CGI, que a su vez suelen distinguirse entre programas y guiones. Los programas se consideran escritos en algún lenguaje compilado como C, mientras que los guiones son los escritos en un lenguaje interpretado como Perl. También hay ventajas e inconvenientes desde el punto de vista de la seguridad que plantea cada una de las dos formas de escribir las aplicaciones en CGI (programas o guiones).

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.

MECANISMO DE ENTREGA Y PROCESAMIENTO DE 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 a 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 más adelante.

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.

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.

COMO ENVIAR LOS DATOS

GET y POST son dos métodos empleados para enviar los datos de los formularios desde al 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 registros, con todos sus argumentos, por lo que si se enviara 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.

ATAQUE A TRAVÉS DE UNA BASE DE DATOS

Todavía pueden encontrarse muchas bases de datos sencillas, formadas por un único archivo plano (flat file), donde se encuentra en caracteres ASCII la información que contiene la base de datos. El proceso de creación de una base de datos de formato plano se reduce a formar un fichero cuyas entradas se corresponden con los campos de la base de datos. A la simplicidad de creación, se añade la facilidad a la hora de hacer consultas, por ejemplo sirviéndose de herramientas de búsqueda del propio sistema operativo, como grep, que devuelve las líneas que contengan al término de búsqueda suministrado. De esta forma, nos devolvería todos los registros asociados a la palabra a buscar. Un ejemplo típico sería la minibase de datos con las contraseñas de los usuarios en un sistema Unix, el famoso / etc. / passwd.

RIESGOS DE CGI

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), 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 funcione mal.

VULNERABILIDAD

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;

• De 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.

LLAMADA A PROGRAMAS EN CGI

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. Las 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.

SERVER-SIDE INCLUDES (SSI)

Los server-side includes (SSI) son directivas que se pueden agregar en una página HTML, de manera que presentara como parte de la página el contenido de un fichero o la salida de un comando. Aunque los SSI pueden ser mas útiles y dotan de gran flexibilidad a una página Web, también pueden resultar computacionalmente costosos, pueden impedir la portabilidad de las páginas Web y tal vez más importante, pueden llegar a abrir agujeros de seguridad, ya que el autor de la página HTML decide qué programas se ejecutarán y con qué argumentos. En otro caso peor, se podría llegar a ejecutar cualquier comando y así producir daños irreparables o revelar información. Por este motivo, a no ser que se tenga una buena razón para usarlos, lo más conveniente es deshabilitarlos.

PELIGROS DE LOS Server-SIDE INCLUDES

En la práctica, los server-Side Includes permite 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.

SOLUCIONES A LOS PELIGROS DE LOS SERVER-SIDE INCLUDES

Existen varias soluciones para disimular 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 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 ultimo, se pueden mantener los SSI y velar en los programas CGI por que no se produzcan entradas indeseadas, filtrando caracteres como: ;, ¡, -, #, @, “, ` ,°, /, etc.

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 lista despegables, 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ía contener caracteres especiales. 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 al 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.

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 pueden considerar el prohibir caracteres como “..”, para evitar que se puedan producir ataques que obliguen abrir archivos confidenciales. 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 el informe valioso.

CONSEJOS Y ORIENTACIONES

Como decir si un CGI es seguro

¿Es muy complejo?

¿Lee o escribe ficheros en el servidor?

¿Interactúa con otros programas del sistema?

¿Corre con privilegios suid?

¿Se valida la entrada procedente de formularios?

¿Se emplean nombres de camino explícitos?

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 si se lista el codigo fuente en HTML de la página. Por lo tanto, cualquiera puede cargar la página en su disco local y editar, 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 recidida procedente de los campos ocultos.

No fiarse del lugar 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ía faltar parámetros o estar manipulados.

CONCLUSIÓN

Bueno ya que hemos conocido la mayor parte de la programación en CGI podemos decir que es lo mejor en documento Web, pero si se entiende lo del trabajo no tendrá ningún problema y podrá usar su programación en CGI