En el post anterior de esta serie sobre el análisis de código PL/SQL con SonarQube, hemos visto las reglas Blockers de nuestro nuevo Quality Profile.

En esta ocasión, hemos encontrado tres violaciones de las mejores prácticas de programación PL/SQL cuyas consecuencias son tan graves que no se puede imaginar cualquier tolerancia. Lo qué justifica por tanto su condición de ‘bloqueadores’.

Tambien, se encuentra un total de 18 fallos para estas 3 reglas, y entonces este número limitado nos deja suponer que estas reglas son conocidas por el equipo del proyecto.

Por último, estos defectos pueden generar un error de lógica en la aplicación – una operación que nunca se puede realizar debido a que la condición correspondiente nunca se cumplirá – e incluso un crash de la aplicación.

Estas tres reglas Blockers están alineadas con la fiabilidad, la robustez de la aplicación, lo que nos viene muy bien. De hecho, queremos destacar los defectos que afectan directamente al usuario, pues la fiabilidad de la aplicación, y también todo lo relacionado con la seguridad y el rendimiento, todo lo que puede evitar un posible ‘hacking’ de la aplicación, la corrupción de datos o tratamientos que toman demasiado tiempo, lo que de nuevo tendrá un impacto al usuario final.

Vamos a ver si nos encontramos con tales defectos entre las reglas Critical.

Las reglas Critical

Tenemos de nuevo 3 reglas para este grupo de violaciones Critical. La primera de estas, ‘Sensitive SYS owned functions should not be used’ trata del uso de packages Oracle, como:

• UTL_FILE para manejar ficheros y directorios..
• UTL_SMTP para manejar correos..
• UTL_TCIP para manejar conexiones TCP, para leer o escribir en un servidor remoto por ejemplo.

Hay muchos otros paquetes de Oracle con estas características, pero son los que puedo encontrar en el código analizado.

Debo decir que yo no conocía esta norma. No soy un experto en seguridad, y de hecho, no hay muchos expertos en seguridad de base de datos.

Por supuesto, conozco el principio de inyección SQL, que permite a un hacker penetrar en la base de datos, pero en este caso, tendrá los mismos derechos que un usuario normal. Pero, si se encuentra con uno de estos procedimientos ejecutados por un usuario de tipo ‘SYS’, entonces, según estos expertos, es «GAME OVER». Eso le concede los derechos de administrador de base de datos y, por lo tanto, puede hacer todo lo que quiere, incluyendo la eliminación de todos los accesos.

Obviamente, con 320 defectos identificados por SonarQube en el código analizado, esta norma de seguridad no es muy conocida. Corregirlos también puede tomar un poco de tiempo.

Como podemos ver en este diagrama SQALE (plugin SonarQube), se necesitan 40 días para remediar a estos 320 defectos. Yo recomendaría un plan de accción específico para estas correcciones en el corto plazo.

La segunda de estas tres reglas se refiere al uso de un DELETE o un UPDATE sin una cláusula WHERE, lo que significa quitar o actualizar todos los registros de una tabla. Puede suceder a veces una eliminación total de los datos en una tabla temporal, pero una actualización completa es muy poco común. En cualquier caso, queremos comprobar si el uso de estas clausulas se justifica o no.

Con SonarQube, un drill-down en el código nos permite identificar y comprobar el tratamiento erróneo, y en este caso, lo más probable es que estamos frente a un fallo de programación. Alguien tendrá que dar explicaciones!

Sobre todo porque este mismo bloque de código se repite 8 veces en el mismo programa! Ya habíamos conocido este caso con los Blockers, con un Copy-Paste multiple. Una de mis recomendaciones será comprobar si al menos una persona en el equipo de proyecto requiere algún tipo de formación con las mejores prácticas de programación PL/SQL.

Por último nos encontramos con una sola violación de la regla ‘Avoid CROSS JOIN queries’, que identifica consultas en 2 tablas (o más) sin especificar una unión entre ellas, lo cual tiene el efecto de devolver el producto cartesiano de todos los datos de estas dos tablas. Tal defecto puede resultar en un error de lógica para el usuario, sin duda un problema de rendimiento, o incluso un posible error de datos (es decir, una corrupción de datos).

Se podría justificar incluir esta regla en los Blockers. Pero en este caso, ¿ya no tenemos reglas criticas? Si, porque vamos a trasladar unas reglas de tipo Major en la categoria de Criticals, las que presentan un impacto en términos de robustez, seguridad y rendimiento para el usuario.

Esto lo vemos en el próximo post sobre las normas Major. Hasta luego.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.