Seguridad en aplicacion web - StoredProcedures

Buenas:

Tengo aqui una aplicacion basada integramente en asps. Corre en un IIS y por detras tiene un SQLserver. Trato de encontrar fallos.. pero no lo hago, cosa que me frustra teniendo el codigo aqui delante. La cuestion es que todas las consultas que se realizan a la bd son mediante llamadas a StoredProcedures. Han codificado todas las posibles consultas en el servidor SQL. Despues se llaman y se les pasan los argumentos necesarios que suelen ser datos proporcionados por los usuarios que NO han sido validados de ninguna manera. Teniendo en cuenta esto... es correcto afirmar que es imposible inyectar sentencias? Tengo entendido que estos procedures estan compilados y no pueden ser modificados.

La gestion de sesiones se hace mediante la coleccion session de asp, lo cual genera como token un ASPSESSIONID volatil. (¿Por cierto, alguien conoce algun paper sobre debilidades en el algoritmo de generacion de este token?). Me olvido del robo de sesiones por deduccion o fuerza bruta. No tengo acceso al SQL que tiene almacenados los sp, ni tengo posibilidad de correr la aplicacion precisamente por eso, asi que no se si los stored procedures validaran los datos de salida antes de devolverlos al cliente... por ahi, podria haber un fallo de XSS pero tampoco puedo tener la certeza de que exista.

Centrandonos en la aplicacion en si, sin tener en cuenta posibles fallos de configuracion o falta de parches en el IIS... que otras consideraciones deberia tener en cuenta antes de seguir comiendome los cuernos con este codigo?

Saludos a todos.

Comentarios

Holas, Bueno,

Holas,

Bueno, definitivamente usar StoreProcedures en la aplicación limita la cantidad de opciones para un ataque de "SQL Inject" pero no del todo.

Primero, como en este caso tienes el codigo de ASP, tienes que revisar lo siguiente, para ver la factibilidad de un posible agujero de seguridad.

  • Revisa el modo en el que se ejecutan los SP, es decir, si están codificados con un string el cual posteriormente se pasa una sentecia Execute, en otro caso esta opción es casi nula.
  • Revisa si las variables que se recuperan con "Request", tienen algun
    tipo de validacion de texto, en algunos casos solo validan que haya comilla simple ('). Esto nos deja posibilidades de probar algo.
  • Confirmar si el usuario de conexion a SQL Server no tenga limitados los permisos a solo SP, por que en este caso casi es imposible hacer algo.

Con esto ya sacarás algo interesante...

--
saludos

cyfuss

Enviar un comentario nuevo

Smileys
:);):(:D}:):P:O:?8):jawdrop::sick:
El contenido de este campo se mantiene como privado y no se muestra públicamente.
  • Las direcciones de las páginas web y las de correo se convierten en enlaces automáticamente.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Saltos automáticos de líneas y de párrafos.
  • Textual smileys will be replaced with graphical ones.

Más información sobre opciones de formato

Captcha
Esta pregunta es para probar que el que escribe el comentario es un humano
2 + 1 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.

Tienda de música online