Entrevista con Code Risk: un servicio gratuito de análisis de código fuente para complementos de WordPress
Publicado: 2018-10-17
Por otro lado, muchos desarrolladores de complementos no tienen los recursos disponibles para garantizar que el código de sus complementos sea seguro, especialmente si se trata de un complemento pequeño. Aunque todo eso va a cambiar, como explica Hendrik Buchwald en esta entrevista. Hendrik es ingeniero de software, investigador de seguridad y cofundador de RIPS Technologies.
¿Qué hace RIPS Technologies?
RIPS Technologies es una empresa de alta tecnología con sede en Bochum, Alemania. Brindamos análisis de seguridad automatizados para aplicaciones PHP como instalación de software local o servicio en la nube altamente escalable. Nuestros innovadores algoritmos de análisis de código, que están específicamente dedicados al lenguaje PHP, pueden identificar vulnerabilidades de seguridad complejas en aplicaciones modernas como ninguna otra solución. Nuestra misión es proporcionar a los desarrolladores y profesionales de la seguridad el análisis de seguridad más preciso y eficiente posible.
¿Cuál diría que es el error de seguridad más común que cometen los desarrolladores y cuáles son las 3 vulnerabilidades principales que ve en los complementos de WordPress?
Como era de esperar, los problemas más comunes son las vulnerabilidades de secuencias de comandos entre sitios (XSS) que ocurren cada vez que la entrada del usuario se imprime sin la desinfección adecuada en la página de respuesta HTML. Por un lado, estos problemas aparecen con frecuencia porque la salida de datos es la operación más común de las aplicaciones PHP y, por lo tanto, se ve más afectada por violaciones de seguridad que otras operaciones. Y segundo, dada la diversidad de contextos HTML y sus dificultades en la limpieza, estos problemas se presentan fácilmente. Las vulnerabilidades de secuencias de comandos entre sitios (XSS) son bastante graves en WordPress porque pueden usarse, por ejemplo, para inyectar código PHP a través del editor de plantillas. Afortunadamente, requieren interacción con un administrador.
El segundo problema más común son las vulnerabilidades de inyección SQL. Las inyecciones de SQL son más graves que las vulnerabilidades de secuencias de comandos entre sitios porque, en el peor de los casos, se pueden usar para extraer información confidencial de la base de datos, por ejemplo, contraseñas, sin ninguna interacción del usuario. Como resultado, pueden usarse para ataques maliciosos totalmente automatizados.
¿Qué tan buena o mala diría que es la postura de seguridad general de los 1000 complementos más populares/descargados?
Esto es difícil de responder porque no he analizado en detalle los 1000 complementos más populares. Dichas operaciones tardarían muchos meses en completarse y, cuando estemos listos, tendríamos que comenzar de nuevo porque algunos complementos se actualizan con mucha frecuencia.
Por eso es importante utilizar un servicio de seguridad automatizado como Code Risk. Aunque a partir de la puntuación de CodeRisk, que se genera a partir de los escaneos de código fuente automatizados y no verificados que hacemos en el repositorio, puedo decir que el código de la mayoría no es malo, aunque también hay complementos con mala puntuación. Sin embargo, la mayoría de estos complementos son muy grandes y tienen muchas funciones. Esto aumenta automáticamente las posibilidades de tener un error en alguna parte. De nuestras pruebas manuales también podemos decir que los grandes complementos a menudo tienen vulnerabilidades lógicas.
¿Puede contarnos un poco sobre lo que ofrece a los desarrolladores de complementos de WordPress?
Nuestro último proyecto CodeRisk ayuda a los desarrolladores y usuarios a evaluar el riesgo de seguridad del código de su complemento de forma gratuita. Por ahora, esto se limita a los complementos de WordPress que están alojados en el repositorio oficial de WordPress.
Obtenemos automáticamente nuevos complementos del repositorio de WordPress y los escaneamos con nuestro escáner de seguridad PHP RIPS. Los resultados detallados de RIPS se combinan en un valor de riesgo fácil de entender. El valor tiene en cuenta la gravedad de la explotación exitosa, la cantidad de problemas encontrados en relación con el tamaño del código y la probabilidad de que un tercero pueda abusar de un problema.
Los desarrolladores de complementos pueden solicitar los resultados completos y detallados de sus propios complementos a través de un sistema automatizado. Pueden usar la información para corregir posibles vulnerabilidades y fortalecer su código, lo que hace que el ecosistema de WordPress sea más seguro. La idea detrás de CodeRisk es permitir que los desarrolladores de complementos encuentren problemas en su código por sí mismos, incluso si no son expertos en seguridad. Si bien investigamos mucho sobre la seguridad de WordPress e informamos muchas vulnerabilidades a los desarrolladores, hay demasiados complementos para analizarlos todos manualmente.
¿Hay muchos desarrolladores de complementos que se suscriben y utilizan su servicio gratuito de análisis de código fuente? ¿Cómo es la respuesta de la comunidad de WordPress?
Actualmente, hay algunas docenas de desarrolladores de complementos que usan CodeRisk para reducir el riesgo de vulnerabilidades de seguridad en sus complementos. Hemos recibido muchos buenos comentarios hasta ahora y CodeRisk ya ha ayudado a resolver cientos de problemas.
Los escáneres automatizados tienden a informar falsos positivos y casos extremos que podrían no ser explotables. Teniendo en cuenta que muchos desarrolladores no son expertos en seguridad, ¿qué está haciendo para ayudarlos y evitar falsas alarmas?
Nuestros usuarios deben saber que destacamos el código que representa un riesgo para la seguridad. Entre las vulnerabilidades de seguridad no deseadas, esto también incluye otros hallazgos, por ejemplo, protecciones débiles que pueden convertirse en una amenaza más adelante.
No tiene que saber si un problema es explotable y cómo para asegurarse de que no se convierta en una amenaza de seguridad en el futuro. Por ejemplo, si imprime el valor de retorno de una función, asegúrese de codificarlo correctamente para evitar vulnerabilidades de secuencias de comandos entre sitios. Incluso si el valor de retorno aún no contiene la entrada del usuario, este podría no ser el caso en el futuro.
¿Hacia dónde ves que va este proyecto gratuito de WordPress? ¿Tienes planes para ello? ¿Quizás ofrecer un servicio premium para ayudar a los desarrolladores a comprender los resultados y aprovecharlos al máximo?
La próxima versión de CodeRisk agregará soporte para temas de WordPress, ya que son una parte integral de la mayoría de los blogs y, a menudo, también contienen vulnerabilidades. En algún momento nos gustaría extender CodeRisk a otros sistemas de administración de contenido. Actualmente no hay planes para un servicio premium, pero si hay suficiente demanda, esto podría cambiar.
¿Puede dar a los desarrolladores de WordPress dos o tres mejores prácticas de desarrollo seguro a seguir para que puedan escribir un código más seguro?
Si desea escribir un código más seguro, nunca confíe ciegamente en el código existente. Suponga siempre que las funciones pueden devolver la entrada del usuario y trátelas como tales. Para obtener información general sobre cómo escribir código PHP seguro, consulte la Guía 2018 para crear software PHP seguro.
Visite el sitio web de CodeRisk para obtener más información sobre el servicio. Y si usted es un desarrollador de complementos de WordPress, y su complemento está en el repositorio de complementos de WordPress, regístrese para obtener una cuenta gratuita para ver qué vulnerabilidades podría tener su complemento.