Cómo informar de una vulnerabilidad
Escribe a hello@html2wp.dev con SECURITY en el asunto. Por favor, no informes de un problema de seguridad en un issue público de GitHub. Allí los issues son públicos desde el momento en que alguien los abre, así que todos los usuarios de la skill quedarían expuestos al problema antes de que hubiera una actualización que instalar.
Cómo informar
Incluye todo lo necesario para reproducir el problema: la versión o el commit, los pasos y lo que esperabas que pasara. Una prueba de concepto (una demostración funcional del exploit) ayuda y es bienvenida, pero no la necesitas para enviar un informe.
El endpoint /v1/report que describe la documentación no es el canal adecuado para esto: es un buzón para defectos del generador, y una persona lo lee junto con los informes de errores normales.
Qué puedes esperar
- Confirmación de que recibimos el informe en 3 días hábiles.
- Una evaluación del problema y un plazo aproximado en 10 días hábiles.
- Una mención en las notas de la versión si la quieres, y ninguna si prefieres que no.
Si no hay respuesta
Somos un equipo pequeño, no una empresa con un departamento de seguridad. Si un informe sigue sin respuesta después de esos plazos, vuelve a enviarlo: se nos pasó, no lo estamos ignorando.
Qué entra en el alcance
- La skill y los scripts de
skills/html2wp/assets/scripts/, que se ejecutan en tu propio equipo. - El servicio de conversión en
api.html2wp.dev. - El tema de WordPress que genera el servicio, incluido el runtime de PHP que lleva y el importador de contenido.
Cosas que vale la pena reportar aunque parezcan pequeñas: cualquier cosa que lea o transmita archivos fuera del directorio de entrada y del espacio de trabajo, cualquier cosa que permita a una conversión ver otra, cualquier parte de un tema generado accesible sin autenticación, y cualquier cosa que haga que una conversión terminada entregue un tema que debería haber rechazado.
Qué queda fuera del alcance
- Hallazgos contra una versión de WordPress, PHP o de un plugin que tú elegiste usar, cuando la solución es actualizarla.
- El WordPress desechable en Docker que usa
test-env.shpara la verificación local. Tiene una contraseña de administrador fija a propósito, solo escucha en127.0.0.1y se borra después de cada ejecución. Es un entorno de prueba, no un sitio publicado. - Informes de que la comprobación de licencia se puede quitar del cliente. Sí, se puede: el cliente es tuyo y puedes editarlo. Nada relevante para la seguridad depende de esa comprobación. Es el servicio quien decide a qué tienes derecho, y las partes de pago son justo las que se niega a producir sin clave.
- Ataques volumétricos de denegación de servicio (inundar el servicio con peticiones) contra
api.html2wp.dev, y hallazgos que se reducen a pasarle un escáner.
Pruebas contra el servicio
Haz las pruebas con tus propias conversiones y tu propia clave de licencia. No intentes acceder a los trabajos, artefactos o espacios de trabajo de otra cuenta. Si crees que has encontrado una forma de hacerlo, ese es justo el informe que debes enviarnos, y basta con describir el método. No necesitas demostrarlo con los datos de otra persona.
Qué sale de tu equipo
Lo describen la página sobre datos y el propio README del plugin, porque una política de seguridad no es el lugar para enterarse de esto por primera vez. En resumen: el sitio compilado sube al servicio, y la conversión se hace sobre él. Los veredictos de las comprobaciones (gates) se envían por separado y solo contienen nombres y números. La etapa 1 filtra del paquete los archivos que parecen credenciales y lista cada uno que ha descartado. Si encuentras algo que se salta ese filtro, entra en el alcance.