Seguridad en ScriptCase
Aquí hablaremos sobre el «descuido de seguridad» en un desarrollo realizado con ScriptCase en un caso real.
Un producto (llámese sitio web, sistema web, servicios web, etc.) es seguro o inseguro dependiendo del nivel de atención que le pongamos a la hora de la construcción.
Utilicemos o no un framework para el desarrollo, o estemos usando un paquete cerrado como lo son WordPress, Joomla, Moodle, etc, cada uno tiene su límite entre lo seguro e inseguro, en algunos casos basta con mantener actualizados los parches de seguridad o desinstalar ciertos módulos, pero ¡hay que hacerlos! En otros casos hay que programar correctamente la recepción y la limpieza de cada variable para protegerse de cualquier tipo de inyección de código malicioso (especialmente de SQL)
En definitiva, no es algo mágico, no hay un botón que se active para hacer seguro o no un sitio, hay que trabajarlo, hay que cuidar, hay que informarse, hay que conocer los ataques o vulnerabilidades en el entorno en el que estemos, no es para alarmarnos sino para tomar enserio la seguridad. 
Muchos ya se conforman con el SSL y los certificados digitales, creen erróneamente que con la leyenda de «sitio con conexión segura» ya es suficiente, y obviamente están totalmente equivocados, en el HTTPS la seguridad es en la transmisión de un punto a otro punto mediante la encriptación de la información, no tiene nada que ver con la seguridad real de la programación que se haya hecho en el sitio.
En este artículo quiero expresar algunos puntos sobre la seguridad en el entorno de desarrollo del ScriptCase, el mismo trae sus módulos de seguridad correctamente, está totalmente preparado para “enchufar y usarlo” pero para muchos ese módulo no es prioridad, entonces mi recomendación es tomarse el tiempo para aplicar las políticas de seguridad correspondiente. Además, las variables globales, sean estas de sesión, get o post, en forma predeterminada están marcadas las 3 maneras de recepción, cuando en realidad algunas veces solo necesitamos el de sesión.
SOBRE UN CASO REAL
Días pasados me topé con el sitio de una entidad gubernamental paraguaya y constaté que su usuario admin por defecto estaba recibiendo parámetros por get, posiblemente solo debía ser una variable de sesión.
La vulnerabilidad por desatención de la empresa desarrolladora es la siguiente, se accede al siguiente link:
http://www.zzzzzz.gov.py/admin/form_noticias/?usr_login=admin (por privacidad se omite el nombre real del sitio)
Cualquiera que ejecutare el link anterior tomaría el control total de su contenido, pudiendo: alterar, borrar, o insertar nuevos contenidos.
A partir de ahí ya es sencillo ingresar a los siguientes administradores, por ejemplo:
http://www. zzzzzz.gov.py/admin/grid_noticias/
Se ha enviado el aviso correspondiente a los emails que aparecen en dicho sitio, ya hace más de 2 meses del mismo y los responsables ni siquiera se dignaron a responder el aviso, ya se imaginan la importancia que le dan a la seguridad.
Entonces resumiendo todo, la seguridad es responsabilidad directa del desarrollador y no de ninguna herramienta que se use.