1) Inyeccin SQL:

La aplicacin fue correctamente protegida en su momento, pero al da de la fecha existen mtodos mejores para
la sanitizacion de las entradas a la BDD, por ejemplo, la aplicacin a la hora de ejecutar las queries las genera
concatenando un string para luego ejecutarlo:

Si bien los valores de entrada pasan por db_escape (que mostramos a continuacin)

Dentro de dicha funcin se escapan los caracteres especiales usando una codificacin que no necesariamente es
la misma que est configurada en el servidor, siendo esto una posible amenaza ya que con determinadas
codificaciones, se puede ingresar caracteres que son interpretados por el motor de BDD de otra manera, por
ejemplo que sean interpretados como un () (singlequote), lo cual podra llegar a ser, en casos muy especficos,
la posibilidad para un atacante de hacer inyeccin SQL.
Mas mejoras propuestas al cdigo son: Cambiar las funciones de la librera mysql_ (Actualmente deprecada y sin
actualizarse por ms de 10 aos) por las de la librera mysqli_ que toman como parmetro la conexin a la BDD y
aseguran en el caso de escape_string que se use la misma codificacin. Evitando la vulnerabilidad que se
especifica anteriormente.

Como desventaja tenemos que la aplicacin solo funcionara en servidores donde la librera mysqli_ est
disponible.
 Vale la pena mencionar que sigue sin ser la manera mas optima, ya que seria recomendable el uso de un ORM
que se encargue de la conexin a la BDD, o utilizar PDO (Manejo Parametrizado)

2) Perdida de autenticacin y gestin de sesiones: No se encuentran vulnerabilidades ya que en nuestro anlisis no

encontramos que la aplicacin haga pblico ningn cdigo de sesin en urls ni partes visibles al cliente.

3) XSS: En un principio consideramos una vulnerabilidad al agregar un tem a las compras, ya que a simple vista
pareca que el campo precio no se sanitizaba y se poda llegar a ingresar un string como por ejemplo:

/><script src=http://www.misitio.com/myscript.js/>

Para que la prxima persona que ingrese a editar esa compra viera el input del precio cerrado (/>) y cargar su
propio script, pero luego de ms anlisis vemos que solo admite nmeros ya que antes de llamar a la funcin
que mostramos a continuacin:

Se tomaron el trabajo de pasar el numero en cuestin por la funcin input_num($valor, $defecto) que en caso
de no ser un valor numrico, devuelve el valor numrico por defecto que se le ingresa en el segundo argumento.
Si bien comprobamos que no hay riesgo de seguridad aqu, si un programador poco experimentado o distrado
crea un nuevo formulario y se olvida de sanitizarlo antes de ingresarlo a la funcin, podra estar generando una
vulnerabilidad. Se recomienda utilizar la funcin de sanitizacion dentro de la funciones como se muestra a
continuacin para garantizar que sean sanitizadas y no depender de que el programador lo haga antes de usarla:
4) Referencia Directa insegura a objetos
Si bien la aplicacin no enva por GET de manera obvia referencias que puedan cambiarse fcilmente para
probar suerte, las mismas son enviadas en su gran mayora por POST y de manera asincrnica a travez de Ajax.
Si bien es relativamente simple enviar otros parmetros por POST, encontramos una funcin que verifica que el
usuario tenga acceso a una determinada pgina antes de brindrsela al mismo. Por lo cual consideramos que en
caso de haber sido aplicada en todo lugar donde corresponda la aplicacin estara en principio protegida de este
ataque.

5) En cuanto a la configuracin de seguridad propia de la aplicacin, la misma cuenta con un setup que hasta no
ser configurado permite acceder a configuraciones de bajo nivel sin ningn usuario o contrasea, no
consideramos que sea un problema ya que una vez configurada automticamente elimina la carpeta install y
no se puede acceder a esta configuracin. La configuracin de muestra de errores parece adecuada y tampoco
se encontraron indicios de configuraciones inseguras por defecto. Si bien la aplicacin por defecto no trae
problemas de seguridad en su configuracin, puede ser instalada en un entorno no seguro, por ejemplo en un
servidor apache configurado correctamente pero cuyo servidor MYSQL se usa con el usuario root y sin
contrasea, se podra acceder a toda la base de datos de la aplicacin sin uso de una contrasea. No
consideramos esto una falla de la aplicacin ya que depende de la idoneidad de la persona que lo instala y
configura y excede a la aplicacin.

6) La aplicacin no cifra las comunicaciones, no consideramos que sea obligatorio para el entorno para el que esta
pensada (Pequea y mediana empresa) ya que parte de la idea de que todo usuario es parte de la empresa. Si
bien seria una buena practica el uso de SSL aumentara el costo y dificultad de instalacin de la aplicacin,
reduciendo el publico objetivo. Las contraseas de los usuarios se hashean en MD5, consideramos que seria mas
seguro usar SHA1 o mejor aun, un hasheado con salt.

7) Como se explico en el punto 4, la aplicacin verifica por medio de una funcin propia que el usuario tenga
acceso a una funcin antes de brindarla al usuario. No se detecta vulnerabilidad de este tipo.

8) HACER
9) La aplicacin utiliza funciones de la biblioteca MYSQL_ que estn deprecadas como se explica en el punto 1,
se recomienda el reemplazo por las MYSQLI.

10) La aplicacin no tiene ninguna pagina especifica que realice redirecciones de acuerdo a un parmetro. No se
detecta vulnerabilidad de este tipo.