Saltar al contenido

Etiqueta: php

Cómo corregí una vulnerabilidad en mi plugin JS Archive List tras un reporte de WordFence

JS Archive List es un plugin que creé hace más de una década para mostrar archivos de entradas de WordPress en un formato más limpio y dinámico usando JavaScript (inicialmente era con JQuery). Pues hace unas semanas recibí un correo de un grupo de hackers y del equipo de Wordfence (correos separados) informándome de una vulnerabilidad en JS Archive List para realizar inyecciones SQL.

Para quienes no lo conocen: JS Archive List toma los años y meses archivados en la base de datos y permite generar un widget o listado que se navega sin recargar la página. Es sencillo, útil y, como muchas herramientas viejas, tenía una parte interna que había quedado congelada en el tiempo, de hecho ese código viene del fork original en el que está basado.

Cómo se descubrió la vulnerabilidad en JS Archive List

Hace unas semanas recibí un mensaje desde la plataforma de investigadores de WordFence. Ellos tienen un programa privado donde reportan vulnerabilidades a desarrolladores antes de hacerlas públicas, y me dieron un plazo de tres semanas para liberar un fix.

El problema estaba en algo básico, la forma de generar la consulta SQL. El plugin recibía un año a través de la API o URL para filtrar los archivos, pero ese valor venía directamente de la base de datos sin sanitización y se insertaba en la query. Resultado: era posible modificar la consulta enviando un año inválido, lo que abría la puerta a inyecciones SQL.

Nada glamuroso ni nada complicado. Pero sí peligroso.

Actualizando una década de código para usar $wpdb

El fix de la vulnerabilidad en JS Archive List estaba claro: había que actualizar una porción del plugin que llevaba más de diez años igual, adaptarla a las funciones seguras de $wpdb y garantizar que todas las consultas pasaran por sus métodos de preparación. Esto no solo eliminó la inyección SQL, sino que dejó la base para que futuras mejoras del plugin también sigan buenas prácticas. Y claro: ahora JS Archive List es más seguro que nunca. Debo admitir que solo en la última semana del plazo pude sentarme a corregirlo (cosas de la vida), pero una vez entré en modo mantenimiento salió bastante fluido.

Luego tuve que entrar al sistema de WordFence y anunciar que el problema estaba corregido en la última versión. Tanto el grupo de hackers como el equipo de WordFence revisaron y confirmaron que todo está bien para cerrar la alerta en el sistema mencionado.

Reflexión final

Este fue un recordatorio amable de que mantener software libre significa estar dispuesto a revisarlo, actualizarlo y cuidarlo. Si usas JS Archive List, te recomiendo actualizar a la última versión. Y si alguna vez te toca lidiar con reportes de seguridad, tómalos como una oportunidad para pulir tu código y ayudar a hacer Internet un lugar mas seguro para todos.

¿Te ha pasado algo similar? ¿Descubriste vulnerabilidades en tu propio software?
Me encantaría leer tus experiencias en los comentarios.

Deja un comentario

Class already exists en PHPUnit

Esta semana en el trabajo me topé con un error de Class already exists en PHPUnit. El cual me sorprendió porque no tenía mucho sentido:

Mockery\Exception\RuntimeException: Could not load mock class MiClase: class already exists

Entonces lo primero que pensé fue: “¡¿Cómo que ya existe si lo acabo de crear?!”. En mi trabajo estábamos creando una serie de pruebas unitarias (como siempre me ha gustado) para una nueva funcionalidad bastante grande, y usamos Mockery como herramienta para simular el comportamiento de clases y objetos. Si no lo conoces, Mockery es una librería para PHP que permite crear mocks, stubs y spies para probar clases de forma aislada, sin tener que depender de la implementación real.

¿Qué es un mock?

Tal vez te preguntes, ¿qué es eso de un mock? Bueno, imagina que tienes una clase llamadaServicioFactura que depende de ServicioCorreo para enviar correos. Pues resulta que cuando haces pruebas unitarias, no quieres que se envíen correos reales (que ningún usuario, inclusive el que está probando, reciba 30 notificaciones de prueba), tanto por costo, como por rendimiento y porque no se esta probando los correos. Entonces usas un mock de CorreoService que simula su comportamiento: no manda correos, pero finge que sí, y hasta puedes verificar si fue llamado o no. Bien útil. De esta forma, cuando se ejecuta la prueba, se ejecutará el mock e intercepta las llamadas y simula el comportamiento original.

Cómo solucionar: Class already exists en PHPUnit

Volviendo al error de Class already exists en PHPUnit, en el fondo, lo que pasaba es que tenia un conflicto con la instancia de un mock ya definido, es decir, habia definido un mock de una instancia de esa clase y aparte otro para la clase. . Si te estás preguntando qué es un mock de una instancia, son algo como esto:

$mock = mock('overload:' . MI_CLASE_MOCKEADA::class);

Cuando mezclas un instance mock con un mock normal, lo que en realidad estás haciendo es intentar redefinir la misma clase dos veces. Y eso ocasiona el error mencionado.

La solución a largo plazo es refactorizar ese código viejo para que nuestros tests no dependan de instance mocks. Pero la solución rápida y sencilla, es ejecutar cualquier prueba que use un instance mock en un proceso separado. PHPUnit hace esto muy fácil con una simple anotación:

/**
 * @runInSeparateProcess
 * @preserveGlobalState disabled
 */
public function pruebaQueIncluyeLosMockupsDeInstancia(): void
{
    // código con los mocks de instancia
}

Ya con eso deberías poder ejecutar la prueba, si necesitas mas información puedes ver la documentación oficial de PHP.Unit. Y si sigues con el problema, puedes probar con cerrar los mocks después de cada test con:

protected function tearDown(): void
{
    Mockery::close();
}

Palabras finales

¿Te ha pasado algo parecido? ¿Tienes otra solución o teoría? ¡Déjamelo en los comentarios, me encantaría leerte!

Gracias por leer hasta el final. Si te encontraste con el error Class already exists en PHPUnit y llegaste hasta aquí buscando respuestas, espero que esto haya sido útil.

Happy Testing! 🧪✨

Deja un comentario

Cambiar la versión de PHP en Laradock

Desde hace un par de años, se libera una versión de PHP cada año y por lo tengo para estar al día, es recomendable estar actualizando el código para que sea compatible con futuras versiones. Si utilizas alguna herramienta de contenedores como Docker y tienes tu stack armado allí tarde o temprano tienes que cambiar de versión. Pero si usas PHP en laradock, el proceso es muy fácil como puedes ver.

Cambio de versión de PHP en laradock

El primer paso es ir a la carpeta raíz de Laradock y buscar el archivo de variables de entorno llamado .env. Ábrelo con tu editor de textos favorito y buscar la variable de entorno denominada PHP_VERSION y escribir la versión deseada, por ejemplo:

PHP_VERSION=8.2

Reconstruir imágenes

Luego debes volver a construir los contenedores de php-fpm que es el que procesa el código PHP en laradock y el de workspace para poder ejecutar scripts de PHP como composer, phpcs, entre otros.

docker-compose build php-fpm
docker-compose build workspace

Luego para que los cambios tomen efecto, debes reiniciar los contenedores. En mi caso como uso un stack LAMP sería:

docker-compose down
docker-compose up -d nginx mariadb phpmyadmin workspace

Comprobar que la versión de PHP en laradock es correcta

Y finalmente ya todo debería estar en la versión definida. Para comprobar, puedes crear un archivo .php con la función php_info() por dentro para imprimir todos los datos de la versión. Para el caso del workspace puedes ejecutar: php –version y ver la versión instalada.

Finalmente, espero que te sirva y puedas usar PHP en laradock con la versión que desees. Si necesitas volver a la versión anterior, simplemente edita de nuevo el archivo .env y comienza de nuevo.

Deja un comentario

Mi charla de la HugoConf 2022: migrar a JAMStack viniendo de un entorno LAMP

Hace unas semanas empecé usar JAMStack para rehacer mi sitio profesional usando tecnologías mas nuevas (el stack original tenía 11 años pero es tema de otro artículo). Al investigar decidí usar Hugo y me enteré de la HugoConf. Por lo que envié una propuesta de mi experiencia y fui aceptado a participar en ella.

Afiche de la HugoConf 2022 de la charla de la experiencia de usar JAMStack con Hugo viniendo de un entorno LAM
Mi charla del HugoConf 2022

Mi camino desde el stack LAMP hasta JAMStack con Hugo

Esta presentación es un tema totalmente nuevo. Decidí enfocar mi experiencia de hacer mi primer sitio web con Hugo viniendo de muchos años de hacer sitios con PHP/MySQL y con WordPress (es decir, con o sin CMS). En ella les comento como es el proceso para elegir un generador de contenidos, porqué usé Hugo, las características y herramientas que provee Hugo, como empezar a hacer sitios, ventajas y como hacer optimizaciones del sitio para que cargue muy rápido.

Te recomiendo verla a continuación si deseas conocer como es eso de crear sitios web estáticos y deseas conocer como comenzar:

My journey from LAMP stack to Jamstack with Hugo - Miguel Useche // HugoConf 2022
Mi charla en el HugoConf 2022

Mi experiencia en la HugoConf 2002

Fue excelente evento totalmente virtual. Como estaba empezando a usar Hugo fue interesante ver todo lo que puedes hacer con este generador de contenido estático. Y por la misma razón me sentía un poco intimidado por mi charla porque pensé que era la de menos nivel. Pero la receptividad fue muy buena, se generaron varias preguntas y tuve comentarios muy positivos de esa experiencia. Me motivó a seguirla dictando o crear nuevo contenido similar.

Palabras finales

Espero que te haya gustado la presentación. Si vienes un entorno LAMP (Linux Apache MySQL y PHP) estos consejos te ayudarán a iniciarte en el mundo de JAMStack. Pronto haré un artículo con mas detalles sobre la experiencia de usar Hugo para rehacer mi sitio profesional y obteniendo mejores resultados.

2 comentarios