No es un secreto para nadie que una parte importante de los problemas de seguridad de los sistemas de información tiene su origen en defectos de las aplicaciones que éstos ejecutan. Tampoco lo es que estos defectos, que se manifiestan en forma de vulnerabilidades, se introducen en el software durante su proceso de desarrollo. Lo que a día de hoy no es algo aún suficientemente conocido, es la solución a este problema.

Históricamente, la industria del software ha funcionado usando una dinámica de liberar al mercado productos con un escaso nivel de madurez y se ha ocupado sobre la marcha de corregir los defectos que fueran apareciendo (véase el enfoque de Berkeley frente al del MIT en la entrada de Javier Vela al respecto, ¿Peor es mejor?). La situación actual es algo distinta ya que la capacidad del entorno de encontrar y explotar vulnerabilidades es muy elevada. Por tanto, liberar una aplicación al mercado, especialmente si está destinada a ofrecer servicios al público a través de Internet, sin haber tomado un mínimo de medidas para evitar la aparición de vulnerabilidades, es sin lugar a dudas una invitación al desastre.

La presión por cumplir con el calendario y el presupuesto de proyecto y la exigencia de los usuarios por disponer de nuevas funcionalidades, provocan con frecuencia que la seguridad no esté precisamente en la parte alta de la lista de prioridades de los equipos de desarrollo. Además, la eliminación de vulnerabilidades se suele entender como una tarea de la que alguien se encarga en la fase de testeo al final del ciclo de desarrollo, cuando la fase de programación ha concluido.

Como todos los veranos, este año se ha celebrado la Black Hat, un conjunto de conferencias donde se desvelan las ultimas tendencias en seguridad, cubriendo con detalle la parte técnica aunque también cada vez mas la parte organizativa y social. Aunque desgraciadamente no he podido asistir a estas charlas, tantos los papers comos los slides están disponibles en la web en la parte de archivos Blackhat.

Muchos equipos investigadores esperan a este evento para desvelar sus descubrimientos, por lo que creo que son de lectura obligatoria para aquellos que quieren ver por dónde van las ultimas tendencias y el “state of the art” en el mundo de la seguridad.

Tras echar un vistazo a las presentaciones, uno tiene la impresión que nada es seguro, ya sean teléfonos móviles, parquímetros, infraestructuras eléctricas, medidas antihacking, certificados SSL, la virtualización, la nube, o cualquier tipo de hardware que puedan imaginar. Los malos pueden incluso leer tu teclado desde el enchufe de tu ordenador, así que la única opción parece ser volver a las cuevas. En fin, que para cualquier “maldad” que puedan imaginar ya hay quien se dedica a aplicarla… y en estas charlas se pueden ver muchas de ellas.

(La entrada de hoy es la primera —pero no última— colaboración de Francisco Benet, un amigo de algunos de nosotros —y familia de algún otro— que tiene gran experiencia en la gestión e integración de sistemas, protección de datos de carácter personal y evaluación de soluciones de integración de software y hardware, entre otros aspectos. Esperamos que les guste.)

Habitualmente estamos acostumbrados a hablar de firewalls, defensa en profundidad y perimetral, detectores de intrusión y otros tantos artilugios tecnológicos que nos van a ayudar a mejorar la seguridad de nuestros sistemas. Pero nos dejamos por el camino puntos que son al menos igual de importantes; que no sustituyen pero se complementan entre ellos: la seguridad del código.

El otro día, mirando los archivos que tengo en el ordenador de casa encontré algunos proyectos antiguos en Visual Basic que diseñé hace algunos años. En aquella época trabajaba en una empresa muy pequeña (dos desarrolladores, un administrador de sistemas y “el jefe”), para nosotros todo lo que hacíamos era la mejor opción y los clientes quedaban bastantes satisfechos con nuestro trabajo. Los desarrollos los hacíamos con Visual Basic 6.0 contra bases de datos Microsoft Access y en el mejor de los casos SQL Server 2000; todo Microsoft, por supuesto.

Con los conocimientos de seguridad que he ido adquiriendo a lo largo de mi vida laboral me doy cuenta de que los proyectos que diseñábamos de manera tan “perfecta” tenían… ¡más vulnerabilidades que código escrito!, y que si un usuario malintencionado se hubiera entretenido en explotarlas hubiera destrozado el sistema en cuestión de segundos. Pensando en todo esto me pregunto: ¿Por qué diseñabámos así? ¿No teníamos los conocimientos necesarios? La respuesta es que en ningún momento del desarrollo nos planteábamos la posibilidad de que existieran usuarios malintencionados, o en otras palabras, asumíamos que “los usuarios de nuestra aplicación son demasiado torpes como para hacer esas cosas”. Obviamente, no puedes confiar en que los usuarios de tus aplicaciones vayan a ser “buenos” y no salirse del camino que les dibujas, porque si encuentras uno curioso, puedes llevarte más de una sorpresa desagradable.

Pasamos una época complicada en el tema económico, en la que diversos estudios aseguran que aumentan las depresiones y las visitas al psicólogo, mientras que otros destacan el aumento del dinero destinado a juegos de azar por parte de las familias. Una de las alternativas de estos juegos de azar que muchos de ustedes conocerán son las apuestas por Internet, que quizá algunos incluso hayan probado.

El procedimiento de uso suele ser sencillo: un registro, un depósito monetario mediante tarjeta de crédito o similares y a buscar rentabilidad en las apuestas (no se preocupen, que ya les hablaré de eso otro día). Supongo que convendrán conmigo en que en esta época en la que el tema de la seguridad informática es tan candente, se le debe dar mucha importancia a las compañías que demuestran rigor al menos en la seguridad de sus portales. Al fin y al cabo parte de los ahorros —o no— de los usuarios va estar un tiempo en sus cuentas bancarias, hasta que éstos puedan recuperarlo.

—Buenos días, Maestro, hoy vengo a traerte una ofrenda.
—Vaya, una tira cómica de xkcd… son un tanto curiosas.

(…)

—Perdona por la interrupción. Como te decía, desde el punto de vista de Alicia, hay poco que pueda hacer. Puede desactivar la ejecución de script en su navegador, lo que la dejará sin poder visitar muchas de las páginas que le interesan. Puede activarlo sólo para los sitios de confianza, asumiendo que éstos no son vulnerables a este tipo de ataques (lo que es mucho asumir) y, por supuesto, ser sanamente desconfiada para evitar la parte de ingeniería social del ataque. Y poco más. La responsabilidad está en quienes han desarrollado el sitio web vulnerable, que deben corregir la aplicación Web para que no lo sea.
—¿Se puede conseguir eso?
—Claro. El éxito del ataque se basa en que el sitio Web devuelve el código script que se le inyecta y que se ejecuta en el navegador de Alicia. Basta con no hacerlo.
—¿No devolver el script que luego se ejecuta?
—Ese es el enfoque que siguen muchos desarrolladores. Aplicar “html encoding“. ¿Sabes lo que significa?
—Sí, claro, se trata de “escapar” un carácter especial de un código html para que se muestre como tal, en lugar de ser interpretado por el navegador. Se utiliza siempre que se muestran ejemplos de html en un sitio Web.
—Exacto. Si quiero que en una página salga “<br />” en lugar de un salto de línea en el navegador, debo escribir “&lt;br /&gt;”, ya que esa secuencia tiene un significado especial. He de indicarle al navegador que no debe interpretarla, sino mostrarla, utilizando &lt; para “<” y lo mismo con el resto de caracteres.
—Entonces, basta con “escapar” todos los caracteres especiales.
—En principio. Claro que eso tiene el inconveniente de no permitir al usuario que introduzca negritas, cursivas o enlaces dentro de su texto. Quizás un inconveniente aceptable.
—Bueno, se pueden permitir algunos de los caracteres especiales o, mejor dicho, determinadas combinaciones, como “<a href=”, pero no otras, como “<script>”.
—Sí, claro. Es la táctica de detectar las entradas no deseables y eliminarlas o neutralizarlas. El problema es que hay más formas de introducir un script en un texto de manera que no se detecte con facilidad. Por ejemplo, se puede introducir “%3D%3C%73%63%72%69%70%74%3E”, que es lo mismo que “<script>”, como parte de una URL. Pero lo peor es que puedes estar protegiendo la aplicación frente a determinadas formas de introducir un script, pero luego aparecer en el futuro otras que no tenías previstas y no ser capaz de detectarlas.
—Pero seguro que sabes una solución y me la vas a contar…
—Pues la solución es obvia, si aplicamos una de las buenas prácticas de programación que cualquier buen desarrollador conoce: validar cualquier entrada del usuario contra una especificación de las entradas correctas. O sea, admitir lo que es correcto según las especificaciones del programa y rechazar cualquier otra cosa.
—Usando expresiones regulares.
—Es uno de los métodos más útiles, sí.
—En resumen, que el XSS se evita controlando bien todas las entradas a la aplicación, validándolas según la especificación de lo que se considere una entrada correcta.
—Ni más, ni menos.

Hace unos meses leía en la web de Bruce Schneier un artículo en el que hablaba de la responsabilidad -o irresponsabilidad- de los generadores de software (por “generadores” me refiero a programadores, empresas de desarrollo, analistas, etc.) en la seguridad de la información. Bajo mi punto de vista, el software -en especial las aplicaciones- fallan. Fallan y mucho. Y demasiado. No únicamente desde el punto de vista de seguridad -que también-, sino incluso desde el punto de vista de la funcionalidad. Y lo peor, es que todos lo asumimos como algo habitual, como lo más normal del mundo, y como decía Schneier, incluso parcheamos nosotros mismos las aplicaciones (algo impensable con un coche, por ejemplo).

¿Por qué falla el software? Mi opinión es que en términos generales el software falla por cuatro grandes motivos; los comento, sin ningún orden particular:

Es complicado trabajar en el mundo de la seguridad. Estaba pensando emplear la palabra “duro”, en lugar de complicado, pero para ser justos creo que debemos dejar ese tipo de términos para otros trabajos que son “realmente duros”. Lo dejaremos simplemente en complicado.

Normalmente, los que nos dedicamos a estos menesteres, trabajamos para evitar que las cosas sucedan. Somos trabajadores incansables y silenciosos. Lo mejor es que se sepa que estamos pero que no se note. Este suele ser nuestro trabajo, pero digo suele porque no en todas las disciplinas nos ocurre lo mismo, como luego comentaremos. En los sistemas en explotación distribuimos sensores para enterarnos de las cosas, bastionamos equipos, configuramos redes y sistemas, diseñamos arquitecturas seguras, dibujamos nuestras trampas en las redes para que los “malos” caigan en nuestras redes y podamos “pillarlos con las manos en la masa”, compramos y ponemos hardware y software específico para levantar murallas virtuales (más feas que las de Carcassonne —véanlo ustedes mismos en la imagen adjunta— pero murallas al fin y al cabo). Todo con el fin último de defender nuestros bienes más preciados: nuestra información, nuestro conocimiento.