Hola, Agustín.
Soy Juan, team leader de Toolset. Muchas gracias por tu detallado análisis.
He estado revisando el informe que enlazas, y todas las referencias a código de nuestros plugins. Me gustaría extenderme para explicar por qué considero que son falsos positivos.
Enlace a sitio malicioso, inexistente, sin clasificar
En todos los cases, los enlaces aparecen en archivos de una librería de terceros, Codemirror, y se concentran en un archivo concreto donde se enlazan usos reales de la librería. Ese archivo puede estar desfasado, obsoleto e incluir enlaces a sitios que ya no existen, o cuya clasificación de seguridad ha cambiado.
En cualquier caso, ninguno de esos enlaces es añadido a tu página web bajo ningún concepto.
A pesar de que no suponen un problema de seguridad, tomamos nota para limpiar esta y otras librerías de documentación, ejemplos y otros archivos innecesarios.
Inyección de SQL a ciegas
Sin más información al respecto, me temo que debo referirme a nuestras prácticas habituales. Toolset tiene dos maneras de interactuar con la base de datos:
- Mediante el uso de funcciones y métodos nativos de WordPress, asegurados y verificados por la propia plataforma.
- Construyendo comandos de SQL propios, que después pasan por le método estándar de securización de la propia plataforma:
.
En cualquier caso, nuestros accesos a la base de datos son seguros según el estándar de la plataforma.
Nuestro código no contiene ninguna referencia a una entidad
, que supongo corresponde a algún tipo de contenido definido por el administrador del sitio. Si puedes proporcionarnos más información al respecto estaré encantado de hacer un análisis más profundo.
Listados de directorios y acceso a listados
Este punto se puede resolver mediante una directriz del servidor. Si bien es cierto que podríamos incluir archivos de índice en cada uno de nuestros directorios, no suele ser práctica habitual.
Comprobación de soporte de SRI
De nuevo, un archivo de ejemplo de la librería de terceros Codemirror include scripts de un tercer dominio, que podrían verse comprometidos.
Ese ejemplo nunca se incluye en el sitio web, y en el peor de los casos ese script no tiene acceso a ningún tipo de datos ni a la base de datos. En cualquier caso, como comento arriba, tomo nota para limpiar esos archivos de ejemplo.
Patrón de error en la base de datos / Detectado script de prueba
Algunos ejemplos de esa librería Codemirror contienen formularios, pero en ningún caso los datos aportados allí acceden, puede modificar o alterar la base de datos. De hecho, esos ejemplos no se incluyen en la página web.
Patrón de correo electrónico
Es una práctica muy común que las librerías de javascript contengan una referencia al email de su creador, o al email del grupo que mantiene la librería. Ninguna de dichas direcciones de email supone una amenaza.
----------------------
Como ves, todos los resultados que apuntan a código en nuestros plugins parecen falsos positivos. Me gustaría contar con más información sobre la supuesta vulnerabilidad de inyección SQL, si puedes proporcionarla.
En cualquier caso, espero haber resuelto tus dudas.
Un saludo.
