Inicio > administración, internet, píldoras > El XSS del Senado es lo de menos

El XSS del Senado es lo de menos

noviembre 12, 2012

Apenas salió la web del Senado, ya le encontraron un cuasi XSS. Le siguió una especie de indignación tuitera, como si el bug fuese la pistola humeante que probaba que se ha malgastado dinero. Es un error ir por ese camino.

El XSS conocido (puede haber peores, pero estrictamente éste ni llega a ser XSS, no se ejecuta código en el navegador, se filtran correctamente) es un bug muy estúpido. El programador de esa página quizás se merece un rapapolvo, y el director del proyecto otro más gordo por no insistir lo suficiente en cuidar temas de seguridad, sobre todo en temas básicos y muy conocido, sabiendo que estos bugs lo iban a descubrir pocos minutos después de que se hiciese pública la web. Pero no deja de ser uno de los inevitables bug, y por lo visto hasta ahora no es tan serio, no han hackeado el servidor, sólo se logra que inserten un texto del URL en el HTML de la página (sería muy grave si logran insertar javascript que pudiese publicar datos privados).

Algunos argumentan que debido al coste del proyecto, esos bugs no deberían ocurrir, una pista de que no conocen de la complejidad.  La complejidad de los programas no crecen linearmente, sino más próximo a un crecimiento exponencial. Por ello sostengo que es importante, sobre todo a largo plazo, la filosofía KISS (Keep It Simple Stupid), es la mejor forma de mantener la complejidad bajo control, y así reducir las probabilidades de bugs. El que diga que un proyecto de este tipo no puede tener bugs, es que nunca desarrolló un proyecto importante, o se olvida el historial  de bugs de seguridad de proyectos similares, aún estando bajo el escrutinio de miles de programadores, por ejemplo WordPress (y ya ni hablo de los plugins, que aún siendo mucho más simple, fueron un coladero de ataques de seguridad).

Lo del XSS es una anécdota, y que no debería servir más que para el cachondeo, y como una muestra que las decisiones que se tomaron a más alto nivel fueron las erróneas, por ejemplo, por no basarse en gestores de contenidos de software libre que ya llevan años probados, con estos bugs depurados y solucionados.

El desarrollo de una web sea privada, comercial o institucional, debe ser permantente y continua. No se puede desarrollar hoy y esperar que dure una década, para en diez años acometer un proyecto nuevamente desde cero. Así es como tenemos webs anticuados, renovaciones carísimas, con pérdida de información. y que no satisfacen las necesidades de los usuarios (¿alguién probó cómo se ve en móvil, por ejemplo?). Esto lo sabemos desde hace más de 15 años, y lo hemos experimentado con casi todas las webs de la administración, en lo que siempre repetimos el ciclo:

  1. Se saca un concurso de un proyecto “que será la monda molona”.
  2. Se desarrolla un proyecto complejo, desde cero, a un alto coste, por una consultora que subcontrata, que subcontrata… a un becario sin experiencia, sin mentoring ni control de calidad adecuados.
  3. La solución que se saca a producción con acto y sarao solemne es incompleta, con bugs, como era de esperar de algo que no se probó ni evolucionó con uso real.
  4. Quejas e indignación pública.
  5. Se arreglan los bugs importantes, se olvida el tema.
  6. Ya no hay forma de acceder al código o exigir al contratista original que implemente nuevas funcionalidades.
  7. Se vuelven anticuadas, no satisfacen a nadie, quejas constantes de lo mala que es la web.
  8. Se decide volver a #1

Cada ciclo de estos duran de 5 a 10 años, hoy la web del senado está en el punto #4. En unos pocos años llegaremos al punto #8, y vuelta a empezar.

Por ello, la “indignación” con la web del senado no debería basarse en los bugs de un programador inexperto (o bajo presión), sino en las cuestiones que hacen que siempre estemos en estos ciclo repetitivo:

  • Por qué se decide un desarrollo independiente del Congreso, cuando son muy similares y deberían compartir software e infraestructura, sobre todo con esta crisis cuando se está recortando por todos sitios (en algunos temas más importantes que una web) y que los representantes deberían ser los que dan ejemplo. Es un tema político fundamental.
  • ¿El software se desarrolló desde cero? ¿Por qué habiendo tanto software gestor de contenido libre que puede servir perfectamente?
  • ¿Qué framework se usó para el desarrolló? ¿Por qué no se usó uno de los tantos existentes en software libre que son de muy alta calidad? (Rails, Django, CodeIgniter, etc.)
  • ¿Tiene el Senado todo el código para poder ir mejorando y adaptando el software progresivamente? ¿puede contratar a otros para que lo mejoren o corrijan problemas? ¿o dentro de unos años se volverá a hacer todo desde cero?
  • Cómo se distribuyó el dinero, qué parte es del web, qué parte de otros servicios digitales.
  • Cuáles son los demás servicios incluidos, y qué utilidad tienen.

El problema de estos proyectos es la creencia absurda de que “ahora sí sabemos lo que queremos”, “ahora sabemos cómo hacerlo”, “el dinero adecuado asegurará que se haga correctamente”, “ahora tenemos la tecnología y partner adecuados”, “los del otro sector de la administración no saben de nuestra casuística tan especial, por lo que mejor hacerlo desde cero.”

Esto es lo que hay que detener de una vez, pero las taras no son sólo políticas, también de los técnicos informáticos responsables.

PS: Y yo me pregunto la mayor, ¿qué información de utilidad genera el Senado? ¿qué hacen de utilidad además de ser el cementerio de elefantes?

Categorías:administración, internet, píldoras Etiquetas:
  1. Chicho Terremoto
    noviembre 12, 2012 en 3:27 pm

    Lo realmente grave es que el buscador no funciona pues aún redirige los links al dominio de desarrollo supongo nuevaweb.senado.es y Oops! Google Chrome could not find nuevaweb.senado.es … pruébalo tu mismo http://www.senado.es/web/resultadobuscador/index.html

  2. noviembre 12, 2012 en 3:40 pm

    Aquí dan bastantes datos acerca del software usado: http://www.elmundo.es/elmundo/2012/11/06/navegante/1352201162.html

    Gran parte del precio es culpa de las licencias de Oracle. Que además supongo que se tendrán que renovar al cabo de un tiempo.

  3. Bernardo
    noviembre 12, 2012 en 3:41 pm

    A tu pregunta: “¿Qué framework se usó para el desarrolló? ¿Por qué no se usó uno de los tantos existentes en software libre que son de muy alta calidad? (Tails, Django, CodeIgniter, etc.)”

    Quizás es que el responsable del projecto, que posiblemente no tenga ni la más mínima idea del tema, vió que en Disney Channel decían que el Open Source no es seguro (http://www.theregister.co.uk/2012/08/20/disney_sitcom_open_source_insecure/).

    Pero vamos, que estás en lo cierto. A día de hoy no tendríamos que andar reinventando la rueda y caer en errores tan básicos como no tener disponible el código del propio sitio para mantenerlo como a uno le venga en gana.

  4. rafamg
    noviembre 12, 2012 en 4:50 pm

    “¿Tiene el Senado todo el código para poder ir mejorando y adaptando el software progresivamente? ¿puede contratar a otros para que lo mejores o corrijan problemas? ¿o dentro de unos años se volverá a hacer todo desde cero?”

    Esas tres preguntas deberías ponerlas en negrita y tamaño de puño… pero viendo con la alegría que se contratan servicios tiene toda la pinta que la respuesta a las dos primeras es no y la última es por supuesto.

  5. Chicho Terremoto
    noviembre 12, 2012 en 5:25 pm

    Parece que ya han sacado el parche del buscador https://twitter.com/Senadoesp/status/267905837106855936

  6. noviembre 12, 2012 en 6:25 pm

    “¿qué información de utilidad genera el Senado? ¿qué hacen de utilidad además de ser el cementerio de elefantes?”

    Esas dos preguntas ya contestan todas las anteriores.

  7. noviembre 12, 2012 en 7:06 pm

    Buen apunte. Más o menos, eso mismo, pero resumido en cuatro líneas, se lo comenté al jefe de informática del Senado la semana pasada: le expliqué que los “megaproyectos” informáticos de este estilo, que se pasa de nada a todo de un plumazo, son un completo error.

    Desde hace 2 años sigo la evolución de la web del Senado de España.

    En enero de 2011 publiqué un análisis de la accesibilidad de la antigua web (http://accesibilidadweb.dlsi.ua.es/?menu=ej-analisis-senado-parte-1). La accesibilidad era pésima, pero bueno, es que toda la web era pésima. Pero me fijé en esta web porque me parecía bastante vergonzoso que los mismos que habían hecho las leyes en materia de accesibilidad web, no la cumplían

    Posteriormente descubrí que existía la licitación para la nueva web (http://accesibilidadenlaweb.blogspot.com.es/2011/08/la-nueva-web-del-senado.html) y posteriormente señalé que se había cumplido el plazo del proyecto, pero la nueva web no existía (http://accesibilidadenlaweb.blogspot.com.es/2012/05/la-pagina-web-del-senado-de-espana.html).

    Finalmente, la semana pasada me dieron acceso (por pesado) a la versión beta de la nueva web, y volví a señalar algunos problemas que encontraba (http://accesibilidadenlaweb.blogspot.com.es/search/label/Senado).

    Respecto al algoritmo que planteas, coincido con él, pero en este caso no se cumple del todo:

    1. El proyecto tiene una garantía de 2 años (http://www.senado.es/web/contract?id=2010&id2=208&id3=2, página 34). No se explica bien qué supone esa garantía, pero además de la reparación de bugs supongo que también incluirá la modificación de ciertas funcionalidades.

    2. Además, la presentación de una oferta para el proyecto obligaba a presentar también el mantenimiento de la solución propuesta durante los tres años posteriores al período de garantía (http://www.senado.es/web/contract?id=2010&id2=208&id3=1, página 11).

    Por tanto, es de esperar que, al menos durante 5 años, la nueva web del Senado esté “viva”.

    Las condiciones de este mantenimiento no son públicas (al menos yo no las he podido encontrar) y su coste no está incluido en el coste actual de desarrollo.

    Además, el Senado se reserva el derecho a no formalizar el contrato de
    mantenimiento, una vez finalizado el periodo de garantía.

  8. Anonymous
    noviembre 12, 2012 en 8:08 pm

    El argumento de “es caro = debe ser seguro” no me parece tan inválido.

    El dinero per se no hace que una web sea segura, eso es obvio. Pero en el proyecto que se presenta, el jurado que valora la oferta pública debería tenerlo en cuenta. No se trata de que cuanto más se invierta, más en cuenta se tenga la seguridad. Se trata de entender que con una inversión de magnitudes gubernamentales es deseable de forma general que una gran parte de esa inversión se destine a auditorías de seguridad y estudios que no dejen pasar errores obvios.

    Probablemente incluso el alto coste del proyecto ha sido justificado con alguna floritura de marketing tipo: “Nuestra empresa invierte bajillions en tecnologías seguras y auditorías ultra-mega-épicas”.

    En resumen, ese argumento tiene algunas bases válidas una vez se desarrolla con detalle. Y sobre todo implica que ese dinero que se esperaría haber invertido en seguridad (de la forma que quieras, auditorías, formación del equipo de desarrollo, estudios por pares) se ha ido a otras cosas. Esto deja a entrever una mala gestión que creo que es el objetivo mismo del argumento.

  1. noviembre 12, 2012 en 8:54 pm
Los comentarios están cerrados.
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 470 seguidores

%d personas les gusta esto: