Climens Codelog

Para los que llevamos tiempo en el mundo de Linux seguro que hemos visto más de una vez mensajes en listas de correo o foros o por ejemplo últimamente para firmar la autenticidad de los paquetes de Ubuntu, las siglas PGP o GPG.

PGP es un algoritmo criptográfico de clave asimétrica que se creó alrededor de 1991 (aunque ha ido evolucionando) y ha llegado, no sin algunos entresijos legales, hasta nuestros días como uno de los mejores mecanismos de firma y encriptación existentes y de implementación abierta a través de OpenPGP y la RFC2440. Y GPG no es más que una de las implementaciones más populares del algoritmo, disponible para varias plataformas.

Y gracias a GPG tenemos en Firefox una estupenda extensión llamada FireGPG, como no podía ser de otra manera. De este modo, GPG se encarga de gestionar nuestras claves mientras que la extensión nos ofrece un menú contextual para encriptar o firmar el texto seleccionado y integración con Gmail.

Por un lado, el menú contextual permite firmar y verificar firmas, encriptar, encriptar y firmar y desencriptar, así como importar (seleccionando el texto de la fiarma) y exportar (pegando la clave pública) firmas.

A la hora de firmar, deberemos seleccionar la clave privada con la que queremos realizar la operación y nos preguntará la palabra secreta para poder desencriptar nuestra clave privada (se guarda cifrada en el disco) y firmar el mensaje. En este caso, cualquier persona con nuestra clave pública, que podemos haber facilitado nosotros o haberla colgado en un servidor de firmas (como puede ser el de RedIris o el de PGP.com).

Si lo que queremos es encriptar, deberemos seleccionar una o varias claves públicas de los destinatarios del mensaje (y si además queremos firmar, una clave privada). Solamente los propietarios de las claves privadas que corresponden a las claves públicas usadas podrán leer el mensaje, por lo que si no nos añadimos a nosotros mismos, no podremos saber qué hemos encriptado una vez lo hagamos.

En cuanto a la integración con Gmail se hace de dos modos. El primero es el modo de lecutra, en el que aparece un pequeño texto al lado de Reenviar que pone "Descrifar el mensaje" o nos indica si la firma es válida o no.

El segundo modo es a la hora de escribir. Aparecen una serie de botones al lado de los típicos de Gmail con las mismas opciones que encontramos en el menú contextual. Pulsando uno de ellos realizaremos la misma acción pero automáticamente seleccionará todo el texto, lo firmara y/o encriptará y después lo volverá a pegar en el cuadro de texto (y si además pulsamos en la opción más enviar, enviará el correo automáticamente). Por las pruebas que he hecho, es más fiable usar la opción de enviar automáticamente porque nos aseguramos que no escribimos texto adicional que pueda alterar el mensaje.

Existe también una extensión para Thunderbird llamada Enigmail que básicamente hace lo mismo que FireGPG pero para el cliente de correo y me consta que hay también otros plugins para Outlook y otros clientes de correo populares.

En resumen, es una buena forma de conseguir firma digital. Evidentemente no existe una gran empresa que verifique de nuestras firmas son válidas y reales, pero tampoco tienen el coste que tienen algunos certificados digitales de entidades reconocidas. Aun así, se pueden crear redes de confianza entre propietarios de firmas si por ejemplo se ven en persona y intercambian sus claves públicas.

Habrá que ver si son la popularización de las firmas digitales como las que vienen en el DNI-e (aunque hay que sacarlas del carné, lo que no es una tarea tan simple) se empiezan a firmar los correos electrónicos, por lo menos a nivel institucional y coporativo, para aumentar la confiabilidad de los correos electrónicos y evitar el fraude. O, qué narices, por divertirnos un poco.

Enlace | FireGPG

De un tiempo a esta parte habían empezado a llegar a una cuenta de correo que tenemos configurada para recibir los informes de error de las distintas aplicaciones web una serie de errores bastante sospechosos. Eran todo URLs con cadenas de texto en parámetros numéricos que hacían fallar la página. Esto se producía evidentemente por nuestra pobre comprobación de los parámetros que producía que en algunos casos el valor numérico en cuestión llegase tal cual a una consulta en la base de datos, fallando estrepitosamente.

Lo curioso del caso es que solamente ocurría en algunas webs concretas y siguiendo siempre el mismo patrón: claramente usaban una herramienta que buscaba posibles vectores de inyección SQL o similares. Era un mecanismo bastante burdo pero seguro que en algún sitio algo encontraron. Además las IPs eran variadas así que posiblemente se debía a la aparición de alguna herramienta en algún foro de script kiddies.

Y me dije: yo quiero hacer lo mismo. Así que me puse a buscar y encontré algunas herramientas, siendo la más interesante Wapiti, un fuzzer sencillo hecho en Python con las siguientes funcionalidades:

• Detección de errores en la gestión de ficheros (fopen, includes...)
• Inyección SQL
• Inyección XSS
• Inyección LDAP
• Ejecución de comandos (eval(), system()...)
• Inyección CRLF (HTTP splitting)

Además muestra un mensaje de alerta cada vez que se produce un error 500, con lo que es ideal para analizar aplicaciones hechas en ASP (ehem).

Así pues hice un testado exhaustivo con esta herramienta a nuestro código base y la verdad que encontré cosas interesantes, como un error de lo más ingenuo que daba paso a un bonito ataque XSS o unas cuantas entradas sin proteger que proporcionaban posibles ataques SQL jugando con los parámetros. Otros errores no eran tan evidentes y se basaban en jugar con los datos enviados por POST, que por cierto para las pruebas encontré imprescindible la extensión Live HTTP Headers que permite ver el tráfico HTTP y luego repetir una llamada modificando las cabeceras (con calculadora automática del Content-Length, afortunadamente).

He de decir que esto evidentemente no es una herramienta de revisión de código pero si me tengo que poner a revisar toda nuestra base de código antiguo apaga y vámonos. Más vale un poco de protección que ninguna protección, por lo menos la valla un poco más alta que la del vecino.

Posiblemente aun queden muchos agujeros que tapar pero en general ya solemos usar protección para todos los parámetros que entran como comprobar que los números son valores numéricos y que las cadenas de texto son como deben ser y no tienen gato encerrado (ver el XSS FAQ para un método bastante competo de protección).

En resumen, que a lo largo de los años se ha descuidado muchas veces la seguridad de aplicaciones web (las prisas, la poca importancia atribuida, el desconocimiento, etc) y cada vez hay más y mejores técnicas para sacar provecho de nuestros fallos, por lo que cualquier comprobación no está de menos.

Actualización 08/03/2008: Kriptópolis se hace eco de un artículo interesante llamado "El mito de la seguridad web total". Interesante lectura.

Puede que muchos no estén de acuerdo con lo mi opinión sobre la extensión de Firefox NoScript pero, y aunque desde el punto de vista de la seguridad puede ser realmente interesante, me crea un problema que no necesito.

Esta extensión permite filtrar absolutamente todos los Javascripts de una página. Funciona a través de una lista blanca a la que se van añadiendo páginas conforme las vamos visitando y autorizamos sus scripts. Todo esto se hace por dominios de modo que si una página, por ejemplo carga un script de estadísticas de otro dominio, pues tenemos que autorizar cada uno de los dominios. Y el caso contrario. Por ejemplo, si autorizamos estas estadísticas y vamos a una web que no hemos visitado, solamente se ejecutará este script.

Además, ofrece cierta protección adicional contra ataques de XSS (ya que limita los dominios de ejecución, se puede decir que imposibilita estos ataques) y incluso añade algún parche que el propio Firefox aun no implementa. En resumen, desde el punto de vista de la seguridad es realmente valiosa: ejecutamos solamente los Javascripts de los dominios en los que confiamos.

Y hasta aquí las que considero que son las bondades de esta extensión. Pero tiene un gran inconveniente: es molesto. Sus fans dicen que total, siempre navegamos por los mismos sitios y que al final acabas teniendo una bonita lista blanca con lo que en general no molesta. Y además puedes eliminar el aviso de bloqueo de scripts en la parte inferior y ya ni molesta. Pues no: molesta, molesta y molesta.

Me paso el día visitando nuevas webs, descubriendo nuevos blogs, haciendo búsquedas en Google que me llevan a sitios insospechados y cada vez que llego a un sitio nuevo: scripts bloqueados. Dale al botoncito y autorízalos. Después espera a que la página vuelva a cargarse de nuevo con la nueva configuración. Y así sucesivamente.

Por otro lado, como creador de contenidos para web, me gusta que la gente vea las cosas tal y como yo he pensado que las vean. Vale que esto es complicado con la gran cantidad de navegadores y dispositivos que hay pero francamente, me esfuerzo en hacer bonitas páginas, aprender a usar técnicas AJAX, empaparme los diversos frameworks, probar en múltiples configuraciones, etc... para que luego al final entre alguien con el Javascript desactivado y se vaya todo al garete. No, no me gusta.

Igual no lo he configurado correctamente pero vistas las quejas y las justificaciones de sus seguidores, creo que está funcionando correctamente. En definitiva: no lo volveré a instalar. Puedo asumir los riesgos.

Enlace: NoScript Firefox Extension