CGI (Common Gateway Inteface)

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.
1
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:
2
• 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
3
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?
4
• ¿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
5