Prevenir ataques XSS e inyecciones de código y SQL con EuropioCode

Riesgos y problemas actuales, aún no resueltos

Actualmente, los ataques XSS, las inyecciones de código y las inyecciones SQL, se suelen prevenir, mayormente, de dos formas:

1) Filtrando las entradas del usuario a nivel de la aplicación: utilizando funciones propias del lenguaje y funciones definidas por el usuario, en los algoritmos de la aplicación.

2) Aplicando herramientas como ModSecurity en forma conjunta con las reglas de OWASP, a nivel servidor, para prevenir el envío de datos que puedan resultar sospechosos.

En el primer caso, los programadores se ven forzados a efectuar trabajos de diseño realmente extenuantes. Muchas veces, se efectúa un filtrado sencillo a nivel de la aplicación, mediante el uso de funciones como strip_tags() o htmlentities() en PHP, pero cuando comienzan a aparecer requerimientos fuera de lo común en la aplicación, todo se complica. Y así nos encontramos con necesidades puntuales como por ejemplo:

• Necesidad de facilitar y permitir el ingreso de texto con preformato (tags HTML permitidos)
• Necesidad de permitir al usuario, el ingreso literal de código fuente en diversos lenguajes;

Y aquí, el trabajo a nivel aplicación, comienza a complicarse. No todo diseño suele ser suficiente ni todo diseño deja confiados a sus programadores. Siempre se estará alerta.

En el segundo caso y sin siquiera mediar alguna de las necesidades puntuales mencionadas anteriormente, ModSecurity termina convirtiéndose en un problema tanto para los programadores como para los administradores de sistemas. La mayoría de las veces, el servidor comienza a arrojar errores 403 al usuario y los logs de Apache, se llenan de lo que a simple vista, parecen ser falsos positivos de ModSecurity haciendo referencia a supuestos intentos de ataques por diversos tipos de inyecciones.

Pero, como siempre digo a mis alumnos:

Los falsos positivos de ModSecurity por intentos de inyección de código o SQL, son en realidad, errores de diseño a nivel de la aplicación.

La realidad, es que la mayoría de los programadores, aún en épocas donde arquitecturas como MVC son el auge de la moda en la ingeniería de Software y sobra documentación al respecto, continúa confundiendo los requerimientos visuales de la aplicación con la lógica algorítmica de la misma.

Los falsos positivos de ModSecurity se producen por errores de diseño cuando los programadores confunden un requerimiento visual con la lógica de negocios de la aplicación.

Necesitar poder permitir al usuario el ingreso de código fuente, es una necesidad visual. Es el usuario quien DEBE CREER que está ingresando código fuente. Es, a los ojos del usuario, que se debe mostrar una cadena de texto que luzca de forma idéntica (o similar) a un código fuente. Sin embargo, una aplicación JAMÁS debe permitir que se le inyecte código fuente. Y lo mismo, aplica al texto con preformato.

Entonces aquí es donde radica el problema. Los programadores no encuentran una alternativa lateral a lo que conocen y todo concluye en la ERRÓNEA anulación de las reglas de ModSecurity.

Anular las reglas de ModSecurity, es el peor error que un SysAdmin puede cometer

La idea de este post, justamente, es brindar esa solución lateral que «le de el gusto» a todos, sin comprometer la seguridad del sistema.

Una solución que conforma a todo el mundo

La solución consiste entonces, en encontrar una manera de permitir al usuario ingresar código fuente en la aplicación, sin que lo que se envíe sea código fuente.

Y para ello, la única alternativa es:

Convertir las entradas del usuario en cadenas alfanuméricas.

Solo las cadenas de texto puro, son las que nos darán la seguridad y tranquilidad que necesitamos. Si lográsemos convertir luego, esa cadena de texto alfanumérico en algo que VISUALMENTE, se asemeje a lo que originalmente ingresó el usuario, estaríamos hallando una forma 100% segura de prevenir las inyecciones de todo tipo.

Y a tal fin, es que creé a  EuropioCode, un nuevo algoritmo de codificación alfanumérica, que puede ser aplicado a cualquier cadena de texto.

EuropioCode -actualmente en fase beta-, cuenta con dos librerías:

1. Una librería JavaScript para codificar los campos de un formulario del lado del cliente (es decir, codificar el/los campo/s antes del envío del formulario al servidor);
2. Una librería PHP que por un lado, refuerza la codificación del lado del servidor (en caso que la librería JS sea ignorada y ModSecurity no se encuentre operativo) y por otro, decodifica la cadena como entidades HTML hexadecimales, de forma tal que dicha entrada solo se interprete visualmente pero sea incapaz de ejecutarse.

En el repositorio oficial en Launchpad, se pueden obtener tanto las librerías JS y PHP como códigos con ejemplos de uso.

Actualmente, está en constante desarrollo por lo que recomiendo a los programadores, hacerse un branch del repositorio:
bzr branch lp:~eugeniabahit/europiocode/trunk
El repositorio está manejado con Bazaar, el sistema de control de versiones desarrollado por Canonical (fabricantes de Ubuntu), que forma parte oficial del proyecto GNU.

Si utilizas Git, otro sistema de control de versiones o simplemente, nunca has utilizado un sistema similar, aprender a usar Bazaar te llevará solo 5 minutos con este tutorial.

Para implementar EuropioCode, solo necesitas unas pocas líneas de código. Te recomiendo mirar (y probar) los ejemplos de uso incluidos en el repositorio.

Por favor, ten en cuenta que EuropioCode:

• No es un encriptador de texto y por lo tanto, no cifra la información. Solo convierte caracteres NO alfanuméricos en código que sí es alfanumérico.
• No es una librería pensada para proveer privacidad al usuario ni salvaguardar datos. Es un pseudo-código alfanumérico para reinterpretación de caracteres NO alfanuméricos.

Esta vez sí, Happy Hacking!