Archivo de la etiqueta: cms

Relanzando Caminayven, otra historia de éxito con WordPress

Posted on by

Caminayven

Como comentaba en el artículo "Primeras experiencias con WordPress… y muchas nueces ;-) ", me estoy introduciendo en el mundillo de WordPress. Nueces San Ignacio no ha sido el único proyecto que he realizado con este gestor de contenidos. Hoy quiero contarte mi experiencia en otro proyecto un poco más grande: Caminayven. Se trata de una revista católica on-line, que lleva más de cinco años on-line sobre PHP-Nuke con más de mil artículos, un montón de redactores y, afortunadamente, un número creciente de visitas.

Hace dos años que empecé a trabajar en un nuevo gestor de contenidos para Caminayven. Empecé programando desde cero un CMS bastante ambicioso, y aproveché para hacer mis primeros pinitos con JavaScript-RPC (una especie de alternativa a AJAX para comunicación asíncrona, basada en carga dinámica de scripts e iframes). El resultado fue desastroso, aunque aprendí la valiosa lección de que no es bueno reinventar la rueda.

Pero —cabezón de mí— volví a la carga a principios del año pasado ayudado por CakePHP, un framework que me facilitó bastante las cosas, pero que seguía sin ser suficiente. Por falta de tiempo e ilusión el proyecto volvió a quedar abandonado, hasta que hace unos pocos meses empecé a preguntarme si WordPress cubriría las necesidades básicas de Caminayven: publicación de artículos, galerías de fotos, acceso sencillo y elegante a la información (archivos, destacados, relacionados…) y poco más.

De nuevo, un análisis realista y concreto de la Arquitectura de la Información para el proyecto puso las cosas en su lugar. ¿Para qué programar una gestión de usuarios, workflow, editor WYSIWYG, feed RSS, categorías y tags… si WordPress ya lo hace? Dicho y hecho: convertir las antiguas plantillas de CakePHP en un theme para WordPress fue cuestión de dos tardes (copiando y modificando Kubrick).

Aunque he tenido algunos problemillas en el theming, quizá causados por mi ignorancia sobre WordPress o por su estructura interna —en mi opinión poco elegante—: el formato de las fechas y la internacionalización. El formato de las fechas, aunque se especifica en el dashboard no se respetaba en el tema Kubrick, además de que los nombres de los meses no se traducen. Con respecto a la internacionalización (más concretamente la traducción), utilizo la versión en castellano de WordPress, pero aun así muchos mensajes están sin traducir, por lo que he tenido que traducir manualmente algunos fragmentos del theme.

En lo que respecta a la funcionalidad, he utilizado el plug-in Author Image y un código propio en el theme para mostrar, a la derecha de cada artículo, una breve ficha de su autor.

Galería

Caminayven también destaca por sus reportajes gráficos, la mayoría de ellos realizados por nuestro querido Javier Cebreros. Para publicarlos probé en primera instancia Awsom PixGallery. Aunque era sencillo utilizarlo y bonito ver una página para cada álbum/foto, el rendimiento es horrible (regenera continuamente las miniaturas), el código es patético (un único y monolítico script de miles de líneas, mezclando PHP y HTML) y el manejo de URL fallaba como una escopeta de feria. Ahora utilizamos NextGEN Gallery, que es justamente lo contrario: un buen rendimiento, mucha flexibilidad a la hora de subir fotos (subida múltiple por HTTP, FTP, etc) y una forma de mostrar los álbumes muy chula. Una posible mejora a este plug-in sería la construcción de colecciones a partir de álbumes en Flickr o Facebook (en Caminayven alojamos algunas fotos en estas redes sociales), y lo añado a mi lista de cosas-que-haré-algún-día.

Otros plug-ins

También he añadido WP-Cache y All-in-One-SEO-Pack para optimizaciones de rendimiento y SEO, respectivamente. Ambos funcionando muy bien y sin problemas. WP-Cache y los consejos de YSlow me han ayudado a hacer Caminayven más rápida, y aún se puede optimizar mucho más.

Migración

Hasta aquí la parte bonita. Pero no hay que olvidar que Caminayven es un proyecto de cierta envergadura y con una trayectoria de cinco años sobre PHP-Nuke, un gestor de contenidos que odio por ser el perfecto compendio de malas prácticas (de hecho, hace dos años nos colaron una inyección SQL que permitió a un niñato destrozarnos la página…). Así que la migración no se plantea fácil. Por una parte, los artículos se escribieron desde el editor WYSIWYG de Internet Explorer y desde Word, así que te puedes hacer una idea de la impeorable calidad del marcado HTML. No se puede copiar y pegar el contenido de una tabla de PHP-Nuke en otra de WordPress, así que la solución aparente está filtrando el HTML con unas decenas de expresiones regulares caseras y las funciones de inserción del API de WordPress. Además, las categorías han cambiado, y he tenido que hacer una tabla de “traducción” de las viejas a las nuevas categorías.

Y, por si fuera poco, nuestros artículos salen en Google News y perder las antiguas URL (modules.php…) sería desastroso para nuestro posicionamiento, tanto en Google News como en los buscadores en general. Así que ha habido que hacer redirecciones 301 e intentar encontrar el artículo por su antiguo ID… también he tenido que añadir el ID de los artículos a las URL, por exigencia de Google News (un poco caprichoso, sí).

Analítica y redes sociales

Al igual que con Nueces San Ignacio, mi trabajo en este proyecto ha ido más allá de lo puramente ingenieril, ya que he diseñado, redactado y otras actividades. Las dos más importantes para el éxito del proyecto han sido la analítica web y la promoción en redes sociales. En cuanto a lo primero, Google Analytics es una gran herramienta pero se está quedando corta para alguna información que necesito saber (los referer exactos cuando un usuario encuentra un error 404 o cosas así), así que estoy introduciendo pequeños códigos de seguimiento propios en la parte del servidor.

Con respecto a las redes sociales, hemos redefinido nuestra estrategia en Facebook, pasando de grupo a usuario corriente. El motivo primario es la visibilidad, ya que todas las novedades que publiquemos con el usuario Caminayven aparecerán en el timeline de nuestros amigos. En cuanto al contenido, enlazamos los artículos más destacables en el status, publicamos todos los posts con NetworkedBlogs y subimos los reportajes gráficos. La estrategia está funcionando en parte, ya que las visitas desde esta fuente han aumentado, pero nuestros seguidores (alrededor de 200) no son muy activos corriendo la voz… es decir, que la regla del 90-90-1 no se cumple del todo.

También nos hemos dado de alta en Twitter (@caminayven), aunque todavía no hay mucha actividad. Esperemos que en los próximos meses la cosa vaya aumentando.

Conclusiones

  • WordPress mola. No es la panacea, pero mola.
  • Hacer una revista católica en internet no es fácil, y crear una comunidad alrededor de la misma mucho menos, pero estamos en el camino.
  • Caminayven es un proyecto apasionante al que siempre se le puede sacar punta, quedan muchas cosas por hacer, pero de momento he cumplido con mi deber ;-)
  • La audiencia está respondiendo: las visitas, en general, han aumentado, y en particular, el promedio de páginas por visita. Pero, sobre todo, los comentarios, ese elemento mágico y maravilloso que da vida a un sitio web :-)

En fin, otro proyecto cerrado por el momento… dentro de un mes te cuento el siguiente… ¡más ambicioso y emocionante todavía!.

El ataque de eu2010.es en otra web de la administración

Posted on by

Mucho revuelo se ha armado con el ataque a la web de la presidencia europea de turno. Llegó incluso a estar en la portada de El Mundo (edición impresa).

Por su parte, desde la Secretaría de Estado de Comunicación reiteraron que la página no ha sido alterada por ningún intruso, ya que la imagen mostrada en el engaño ha sido cargada desde un servidor remoto y no es posible acceder a ella usando normalmente la web.

Y la verdad es que, aunque 11,9 millones por adaptar un OpenCMS y darle mantenimiento y “seguridad” es el robo del siglo, hay que admitir que el error era del propio OpenCMS (el gestor de contenidos que utilizan… que no es PHP :-P ), y además un XSS, si no se utiliza para robar cookies o hijacking es prácticamente inofensivo.

No obstante, este error de principiante no es el único pecado de Telefónica (o de la cárnica que haya subcontratado para el proyecto). Santi Saez nos desvela que la web fue alojada en un servidor con un sistema operativo obsoleto (Debian 4), el panel de control Plesk accesible públicamente, el SSH accesible públicamente y permitiendo el login a root y un BIND (servidor de DNS) vulnerable. Además, el servidor de nombres no era dedicado. Ahora han intentado arreglarlo externalizando el hosting en Akamai.

Pero no nos desviemos del tema, que es explicar cómo funciona esta vulnerabilidad, y cómo explotarla en otra web de la administración que todavía no ha parcheado el OpenCMS.

Qué es XSS

Un ataque XSS o cross-site scripting es una vulnerabilidad de aplicaciones web que consiste básicamente en conseguir que en la página víctima se cargue un script de otro sitio. Como sabemos que los scripts (casi siempre JavaScript) se ejecutan en el navegador del cliente, es evidente que este ataque no va a alterar el servidor en nada.

Pero ¿cómo hacer que una página cargue un script? Para buscar vulnerabilidades XSS y cualquier otra vulnerabilidad web es esencial que encontrar puntos de entrada de datos por parte del usuario. Estas puertas por las que introducimos datos suelen ser:

  • URL (casi siempre parámetros): la dirección de una página la introducimos nosotros y la interpreta el servidor. Habitualmente suelen dar más juego los parámetros (en PHP, lo que se obtiene con $_GET[]). Es el que usaremos en nuestro caso práctico.
  • Formularios: en los formularios de login, búsqueda, etc se nos piden datos que después el servidor interpreta. Por aquí se suelen colar las inyecciones SQL, otro ataque que veremos en futuros posts y que puede llegar a ser muuuuy peligroso, a la vez que sencillo.
  • Cabeceras: son manejadas por los servidores. No suelen dar problemas, porque los desarrolladores web no suelen tocar ahí ;-)
  • Cookies: más complejas y difíciles de atacar, aunque pueden llegar a ser también muy peligrosas (autenticación falsa, etc). Es un tema interesante para un futuro post.

Pues bien, entremos en materia. Imagina un formulario de búsqueda de una web cualquiera. Hay un cuadro de texto en el que tú introduces una palabra, por ejemplo, ‘normativas calidad’ porque quieres buscar las normativas de calidad de un organismo público. Cuando pulsas “buscar”, aparece una página de resultados en el que arriba dice “se han encontrado x resultados para ‘normativas calidad’”. Es decir, repite lo que le has dicho. Ha puesto en la página lo que tú habías introducido en el cajetín de búsqueda.

Vale, pero ¿y si en lugar de ‘normativas calidad’ pones ‘<img src=”http://bean.com/mister-bean.jpg”>’? En teoría la página debe repetir lo que has escrito. Si la web no está protegida, entonces verás una linda foto de Míster Bean en la página de resultados, ya que el navegador interpreta el HTML que has introducido y el buscador ha repetido. Acabas de inyectar HTML, pero no has manipulado el servidor. Esa foto de Míster Bean la ves tú en tu navegador y nadie más.

Si en lugar de HTML plano introduces un script (bien por invocación bien por introducción directa del código), ese script se ejecutará en el navegador, y podrás manipular los elementos de la página, hacer redirecciones… lo que quieras, pero siempre sabiendo que eso se está ocurriendo en tu navegador y sólo en tu navegador.

En los formularios de búsqueda —como ocurrió con eu2010.es— esto no constituye un peligro real para la página (aunque si el sitio es famoso o asociado a política no te dará muy buena imagen), pero si esta inyección la introduces en un cuadro de texto para publicación (un foro, un comentario en un blog, etc), entonces las manipulaciones que hagas las verán todos los que accedan a esa página, y eso ya empieza a ser peligroso.

Tutorial para ser hacker en 5 minutos

Vamos a ver este ataque en la práctica. La web del Centro de Investigaciones Sociológicas, construida sobre OpenCMS, tiene un lindo buscador. Si introducimos una palabra clave como “hola mundo”, la página de resultados repetirá nuestras palabras como un loro:

Página de resultados de búsqueda

Aquí tenemos el código fuente:

Primer fallo... no poner comillas para los valores, como exige el estándar HTML. Bueno, más fácil nos lo ponen. Si en lugar de 'hola mundo' ponemos '>hola mundo <', entonces el código generado será 
<input class="txt" type="text" size="15" name="query" value=>hola mundo <>

Lo que acabamos de hacer es inyectar código cerrando la tag input con el símbolo '>', y el resultado será que vemos el texto box de búsqueda vacío y nuestro mensaje, 'hola mundo' a su lado. Bien, vamos a divertirnos. Si introducimos '><script>alert("Hola mundo")</script>' inyectamos HTML con un JavaScript (la función alert() muestra un mensaje emergente), que se ejecuta con el siguiente resultado:

XSS con un alert() en JavaScript

Hala, ya somos super-hackers de la CIA —voy corriendo a publicarlo en Meneame :-P —. Ah, no, todavía nos falta el "golpe final", introducir la imagen de Mr. Bean. Ahora simplemente inyectamos una imagen (habiendo cerrado previamente la tag input con el signo '>'):

 ><img src="http://blog.tmcnet.com/blog/tom-keating/images/mr-bean.jpg">

Mr. Bean en la web del CIS

Si aparece repetida es porque en la página de resultados se muestra el mensaje de "buscar otra vez" en varios idiomas.

(Lo que viene ahora no es muy importante): hay una particularidad en este caso, y es que, nuestra inyección la podemos hacer tanto con la casilla de búsqueda (es decir, enviando el formulario por POST) como introduciendo el parámetro query —el nombre del campo de texto— en la propia URL (es decir, haciendo petición GET). Esto ocurre porque los servlets—eso que se utiliza en Java para hacer aplicaciones web— mete en el mismo "saco" (el método getParameter()) los parámetros introducidos por formularios y URL. Eso, combinado con la mala práctica de poner doPost en doGet y viceversa —o sea, decirle a Java que haga lo mismo para las peticiones GET y POST— hace que podamos inyectar código no sólo a través del campo de texto de búsqueda, sino también desde la URL. Así podremos distribuir nuestro super-hackeo a nuestros amigos, y al igual que pasó con eu2010.es, decir/tuitear...

¡Mira, mira! ¡Mr. Bean también se fue al CIS! http://is.gd/679lU

¿Cómo prevenir esta vulnerabilidad?

Si eres webmaster o desarrollador, ve y corre a comprobar si tus webs son vulnerables a este ataque. En caso de que hayas recibido una desagradable sorpresa, no tranquilizará saber que prevenirlo es tan sencillo como filtrar con una función la entrada del usuario. Imaginemos que tenemos un buscador en PHP que recibe las palabras clave por un formulario y un campo de texto llamado "busqueda". Si en nuestra página de resultados tenemos algo como

Se han encontrado <?php echo $numero_de_resultados ?&gt; resultados para &lt;?php echo $_POST['busqueda'] ?>

sólo tendremos que sustituirlo por

Se han encontrado &lt;?php echo $numero_de_resultados ?&gt; resultados para &lt;?php echo htmlentities($_POST['busqueda']) ?&gt;

...y estaremos a salvo (más información sobre htmlentities()). Aunque hay métodos más sofisticados y completos, este funciona muy bien, ya que sustituye los caracteres especiales de HTML en sus entidades correspondientes, de tal forma que el atacante no verá su código interpretado, sino mostrado tal y como lo escribió.

Moraleja

¡No te fíes de los usuarios! Filtra todas las entradas (¡todas! formularios, URL, etc). Si esperas un valor numérico en un campo de texto, comprueba que es un número; si esperas una dirección de email, comprueba que es un email (pero con expresiones regulares ¿eh? nada de cosas raras).

Conclusión

Vivimos en la era del ladrillo, y en contra de lo que nuestros torpes políticos digan, el modelo de negocio del ladrillo no sólo no ha muerto, sino que se ha extendido como un cáncer hacia la industria informática. Nuestro negocio está lleno de gente con talento que cobra poco, y políticos corruptos que chupan generosas subvenciones y concursos públicos de una administración a la que no le importa malgastar un dinero que nos pertenece a todos.

Como dice un amigo... en España la ingeniería informática tiene tres principales salidas: por tierra, mar y aire.

Los CMS más populares

Posted on by

El ritmo de publicación del blog está algo bajo últimamente, y seguirá así en las próximas semanas ya que estoy bastante ocupado con diversos proyectos, alguno de los cuales contaremos en detalle ;-)

Descargas semanales de WordPress, Joomla, Drupal, eZ Publish y Alfresco

No obstante, me gustaría comentar el informe de CMS Wire sobre los gestores de contenido más en boga en este año 2009, que el creador de Drupal ha comentado con gran acierto. Las encuestas arrojan unos resultados esperables pero muy interesantes.

En primer lugar, la ya tradicional hegemonía de PHP como tecnología más popular para gestión de contenidos. Me sorprende que, en la era de los frameworks no tengan tanta fuerza otras tecnologías como Python con Zope o Django (a excepción de Plone), aunque quitarle el puesto al “trío de ases” es tarea difícil, por el recorrido y la comunidad que tienen.

En segundo lugar, es muy importante notar que el estudio no es un ránking de los mejores CMS, sino de aquellos más populares, con los que más familiarizados están los encuestados. Que WordPress y Joomla sean los más populares no significa que sean los mejores. Tienen grandes bazas como el apoyo de la comunidad, mucha documentación, gran cantidad de plug-in y muy buena aceptación en entornos empresariales.

Pero no nos equivoquemos. WordPress juega en una liga distinta a Plone y Drupal. WordPress es un gestor de blogs, fácilmente personalizable y puede ser utilizado y administrado por gente con muy pocos conocimientos. Sin embargo, no debe ser empleado como gestor de portales o grandes sitios. Tampoco como sistema ECM ni Intranet. Además, las “tripas” de WordPress tienen mucho código spaghetti. No obstante, mi experiencia personal (lo estoy utilizando para dos proyectos, una revista on-line y una web corporativa) es muy positiva, ya que en muy poco tiempo pude montar un pequeño sitio web y estoy bastante satisfecho, especialmente con la API para crear themes.

Un último apunte sobre WordPress: la métrica de popularidad de WordPress está ligeramente inflada ya que muchos de los encuestados confundieron el gestor de contenidos WordPress con el servicio de alojamiento gratuito WordPress.com.

Por su parte, Joomla es un portal bastante ampliable (hay plug-ins para hacer CRM y cosas así), además es fácil de usar para editores y administradores. Pero en mi opinión, no puede crecer a sitios realmente grandes.

Valoración general de los CMS

En otro nivel están Drupal y Plone. Ambos presentan no sólo una solución de gestión de contenidos, sino un framework para desarrollar sistemas de este tipo (Drupal en sí mismo y CMF, que originalmente no forma parte del proyecto Plone), con lo cual la capacidad para ampliar estos CMS es mucho más grande, sobre todo en Plone por estar construido sobre Zope.

En tercer lugar, la gente está entendiendo que el concepto de CMS es demasiado genérico. No se puede comparar Alfresco, que es un ECM, con un gestor de tareas colaborativo o una red social. Todos ellos son gestores de contenido pero es necesario no confundir peras con manzanas. A las PYMES les suelen interesar los gestores de publicación de contenidos, tales como portales, prensa, blogs… soluciones sencillas que permitan crear rápidamente sitios con un diseño propio y contenidos adecuados. Y a organizaciones más grandes, sistemas que puedan crecer hacia la gestión documental (ECM), intranets/portales del empleado o aplicaciones empresariales más grandes.

Otras conclusiones interesantes:

  • En la valoración general, Joomla! desciende por debajo Alfresco y Silverstripe. También sale mal parado Plone, en noveno puesto con sólo un 30% de votos positivos. El otro 70% son los que no fueron suficientemente hombres para plantarle cara a Zope ;-)
  • Drupal es el que más ha crecido en cuanto a profesionales del desarrollo, y WordPress en cuanto a márketing/redaccción. Además, hay casi el triple de libros sobre Drupal (25) que sobre WordPress (9). Sobre Plone, hay 7 libros publicados.
  • En general, en Internet se habla mucho más de Joomla que de Drupal. Este dato se invierte en los medios sociales, sobre todo en Twitter.
  • Este año, en los blogs (Technorati) se habló de Plone un 55% menos que el año pasado. No obstante, Plone es el cuarto CMS en cuanto a repercusión en la web social.
  • Drupal tiene tantos premios como WordPress y Joomla juntos.

Una última cosa… me alegro de que hayan eliminado del top 20 a PHP-Nuke, que lleva bastante tiempo sin publicar una nueva versión. Antaño fue un sistema omnipresente —diría incluso que marcó una generación— pero malísimo en cuanto a seguridad, diseño, calidad del código, etc. Hoy en día la gestión de contenidos es diferente… gracias a Dios.

Drupal 7 será el CMS semántico

Posted on by

Sólo una pequeña nota para informar de lo que he leído en Sitepoint sobre la nueva versión de Drupal. Si hasta ahora era de los mejores CMS (sus premios le avalan), compitiendo directamente con el “monstruo” Plone, con este movimiento, y si todo sale bien creo que se convertirá en el súper-CMS del presente y el futuro (perdona que me ponga en plan gurú-profeta amarillista).

La idea es darle a Drupal la forma necesaria para convertirse en un nodo de la web semántica, perfectamente interconectado por Web Services, REST o HTTP sin más, que sea capaz de tomar y servir información de otros nodos, permitiendo a los usuarios localizar información dentro y fuera del sitio web. Lo que no sé todavía es si el almacenamiento se mantendrá como hasta ahora, en una base de datos relacional, o por el contrario pasarán a usar una base de datos semántica. Si se diera el primer caso (y así parece, según los avances de Carlos Rincón), deberían utilizar una especie de ORM para mapear las descripciones en la BD, y seguramente esa capa fuese reutilizable más allá de Drupal (como pasó con su motor de plantillas).

Linked data en Drupal 7 (datos enlazados)

Drupal pasa dejando huella, haciendo avanzar el ecosistema de programación PHP y la web en general. Gracias y felicidades, Drupal.

PD: la imagen está alojada por Facebook Inc., hosting gratuito de imágenes. Gracias a su falta de privacidad me voy a ahorrar unos eurillos…