Los plugins facilitan la ejecución de tareas administrativas o de publicación en los sitios web con WordPress, pero también pueden ser objeto de abuso por parte de terceros con intenciones maliciosas. Algunas de las vulnerabilidades comunes a los que están expuestos los plugins de WordPress se presentan a continuación.
a. Visualización de archivos arbitrarios.
b. Carga de archivos arbitrarios.
c. Inyecciones SQL.
d. Escalada de privilegios.
e. Evaluación remota de código.
f. Secuencia de Comandos en Sitios Cruzados (XSS).
g. Falsificación de Peticiones en Sitios Cruzados (CSRF).
Para leer sobre las primeras cuatro vulnerabilidades mencionadas, revisar la parte 1 del artículo.
e. Evaluación remota de código.
Nombre en inglés: Remote code evaluation.
¿Por qué es inseguro?
La evaluación remota es una vulnerabilidad que puede ser explotada si una entrada de datos de usuario es inyectada en un archivo o una cadena que es evaluada (ejecutada) por el procesador del lenguaje de programación de la aplicación web.
¿Cómo se soluciona o mitiga?
Se aconseja evitar entradas de datos de usuario dentro de código evaluador del respectivo lenguaje de programación, esto se puede lograr evitando el uso de funciones como “eval”*. También es buena práctica evitar que algún usuario edite contenidos y extensiones de archivos que podrían ser procesados por los determinados lenguajes de programación del sitio web.
*”eval” es una función usada en algunos lenguajes de programación para la evaluación de cadenas de caracteres para la obtención de un resultado.
Para mayor información revisar https://www.netsparker.com/blog/web-security/remote-code-evaluation-execution/
f. Secuencia de Comandos en Sitios Cruzados (XSS)
Nombre en inglés: Cross-Site Scripting (XSS)
¿Por qué es inseguro?
Esta vulnerabilidad permite ejecutar comandos en el navegador web del usuario víctima, permitiendo a un atacante remoto secuestrar una sesión, realizar una modificación no autorizada de contenido en el sitio web o re-direccionar a un usuario hacia un sitio malicioso.
¿Cómo se soluciona o mitiga?
Se requiere mantener los datos no confiables separados del contenido activo del navegador, a través del uso de frameworks seguros que por diseño codifican de manera automática el contenido para prevenir XSS, como Ruby on Rails (versiones superiores a 3.0) o React JS. Habilitar en el servidor web una Política de Seguridad de Contenido (CSP por sus siglas en inglés).
Para mayor información revisar sección “Cross-Site Scripting (XSS)” en https://www.owasp.org/images/5/5e/OWASP-Top-10-2017-es.pdf
g. Falsificación de Peticiones en Sitios Cruzados (CSRF).
Nombre en inglés: Cross-Site Request Forgery (CSRF).
¿Por qué es inseguro?
Un ataque CSRF obliga al navegador web de un usuario víctima con una sesión iniciada a realizar una petición a través de la sesión activa.
¿Cómo se soluciona o mitiga?
Introducir tokens aleatorios únicos en cada formulario y URL que no sean automáticamente presentados en el navegador web, asegurar que se hayan eliminado todas las vulnerabilidades de Secuencia de Comandos en Sitios Cruzados (XSS) de la aplicación web.
Para mayor información revisar https://www.owasp.org/index.php/Top_10_2007-Vulnerabilidades_de_Falsificación_de_Petición_en_Sitios_Cruzados_(CSRF)
Referencias:
https://www.netsparker.com/blog/web-security/remote-code-evaluation-execution/
https://www.owasp.org/images/5/5e/OWASP-Top-10-2017-es.pdf
https://www.owasp.org/index.php/Top_10_2007-Vulnerabilidades_de_Falsificación_de_Petición_en_Sitios_Cruzados_(CSRF)