**************************************************************************************************
- Hacking de aplicaciones Lasso (I de IV)
- Hacking de aplicaciones Lasso (II de IV)
- Hacking de aplicaciones Lasso (III de IV)
- Hacking de aplicaciones Lasso (IV de IV)
**************************************************************************************************
Llegado ya a la tercera parte del artículo, vamos a proceder a analizar las URLs para poder ver cómo se pueden manipular los resultados de las consultas que se acaban ejecutando en una base de datos conectada a través de Lasso.
Respuesta con y sin errores
Lo primero que hay que explicar es que en las peticiones de muchas aplicaciones vamos a poder encontrar los modificadores -Response y alguno similar a -AnyError, tal y como se puede ver en al Figura 11.
Como podéis suponer, estos parámetros identifican cuales son las páginas web a las que se debe navegar en caso de que la consulta que se lance al servidor de bases de datos devuelva unos resultados esperados o unos resultados con error.
El número de modificadores de error es grande, ya que para tener un control de los mismos más granulado existen modificadores como:
Un proceso de login como ejemplo
Para explicar el proceso, vamos a ver un sistema de login en una aplicación web creada con Lasso. En ella se puede ver que el proceso comienza con la petición de una dirección de correo electrónico, para posteriormente solicitar un clave de acceso.
¿Cómo manipular la consulta y meter datos?
Si tenéis experiencia con el hacking de aplicaciones web con SQL Injection, seguro que ya estáis pensando en meter un ' or '1'='1 para hacer que devuelva algún resultado la consulta y se dispare el layout de response con los datos del primer registro obtenido desde la base de datos. Y eso mismo es lo que vamos a hacer, sólo que sin poner una comilla.
El framework de Lasso permite poner modificadores en las URLs que inciden directamente en la lógica de la aplicación, lo que es muy malo para la seguridad. Si analizamos la URL de llamada anterior es fácil ver como se usan los modificadores -token para meter parámetros a la aplicación y -doscript para forzar el uso de algún procedimiento almacenado.
Si vamos a la referencia de Lasso y buscamos los modificadores que se pueden usar en la URL, obtendremos un maravilloso mundo de posibilidades ante nosotros.
Con esto vemos cómo es posible saltar algunas de las restricciones que se configuran en muchas de las aplicaciones Lasso, pero aún quedan muchas cosas por contar, que veremos en las próximas partes.
Saludos Malignos!
**************************************************************************************************
- Hacking de aplicaciones Lasso (I de IV)
- Hacking de aplicaciones Lasso (II de IV)
- Hacking de aplicaciones Lasso (III de IV)
- Hacking de aplicaciones Lasso (IV de IV)
**************************************************************************************************
- Hacking de aplicaciones Lasso (I de IV)
- Hacking de aplicaciones Lasso (II de IV)
- Hacking de aplicaciones Lasso (III de IV)
- Hacking de aplicaciones Lasso (IV de IV)
**************************************************************************************************
Llegado ya a la tercera parte del artículo, vamos a proceder a analizar las URLs para poder ver cómo se pueden manipular los resultados de las consultas que se acaban ejecutando en una base de datos conectada a través de Lasso.
Respuesta con y sin errores
Lo primero que hay que explicar es que en las peticiones de muchas aplicaciones vamos a poder encontrar los modificadores -Response y alguno similar a -AnyError, tal y como se puede ver en al Figura 11.
 |
| Figura 11: URL con Respose y AnyError |
Como podéis suponer, estos parámetros identifican cuales son las páginas web a las que se debe navegar en caso de que la consulta que se lance al servidor de bases de datos devuelva unos resultados esperados o unos resultados con error.
El número de modificadores de error es grande, ya que para tener un control de los mismos más granulado existen modificadores como:
-NoresultsErrorTodos ellos para conseguir que la página de resultados se dispare por el mensaje de error adecuado. En cualquier caso, si queremos lograr ver el layout que se usa cuando no da error y los datos mostrados en él, es necesario conseguir que que la lógica de la consulta a la base de datos consiga devolver valores esperados, y eso es lo que nos proponemos a hacer en esta parte del artículo.
-ResponseSecurityError
-ResponseAnyError
-ResponseRequiredFieldMissingError
Un proceso de login como ejemplo
Para explicar el proceso, vamos a ver un sistema de login en una aplicación web creada con Lasso. En ella se puede ver que el proceso comienza con la petición de una dirección de correo electrónico, para posteriormente solicitar un clave de acceso.
 |
| Figura 12: Proceso de Log in con Lasso |
En la URL no se aprecian los layouts de error y respuesta, ya que esta dirección es la ubicación en la que estamos y a ella hemos llegado desde un enlace, por lo que el programador no ha contemplado ningún error. Sin embargo, en todos los enlaces que tienen que contar con una sesión autenticada de usuario sí que podría producirse un error - cuando el usuario no estuviera autenticado -.
Si analizamos el código fuente de la página, podemos ver cómo el enlace a revisar las propiedades de la cuenta del usuario tiene los modificadores citados anteriormente -Response y uno para el tratamiento de errores. En este caso -NoResultsError.
 |
| Figura 13: Enlace con Response y NoResultsError |
Al invocar la URL manualmente en el navegador obtendremos, como es de esperar, la página indicada en NoResultsError, es decir, un mensaje de que necesitamos logarnos.
 |
| Figura 14: Página de error |
¿Cómo manipular la consulta y meter datos?
Si tenéis experiencia con el hacking de aplicaciones web con SQL Injection, seguro que ya estáis pensando en meter un ' or '1'='1 para hacer que devuelva algún resultado la consulta y se dispare el layout de response con los datos del primer registro obtenido desde la base de datos. Y eso mismo es lo que vamos a hacer, sólo que sin poner una comilla.
El framework de Lasso permite poner modificadores en las URLs que inciden directamente en la lógica de la aplicación, lo que es muy malo para la seguridad. Si analizamos la URL de llamada anterior es fácil ver como se usan los modificadores -token para meter parámetros a la aplicación y -doscript para forzar el uso de algún procedimiento almacenado.
Si vamos a la referencia de Lasso y buscamos los modificadores que se pueden usar en la URL, obtendremos un maravilloso mundo de posibilidades ante nosotros.
 |
| Figura 15: Referencia de comandos en Lasso |
Uno de esos maravillosos modificadores es 'or '1'='1... digo.. -findall, que permite obtener todos los resultados del layout/table asociado, con lo cual se simplifica totalmente el proceso de extracción de datos.
 |
| Figura 16: Información sobre findall |
En este ejemplo, quitando los modificadores -doscript y -token, y añadiendo -findall a la consulta, se puede ver cómo vemos el layout de -Response con datos obtenidos desde la base de datos conectada.
 |
| Figura 17: Respuesta con -findall |
Con esto vemos cómo es posible saltar algunas de las restricciones que se configuran en muchas de las aplicaciones Lasso, pero aún quedan muchas cosas por contar, que veremos en las próximas partes.
Saludos Malignos!
**************************************************************************************************
- Hacking de aplicaciones Lasso (I de IV)
- Hacking de aplicaciones Lasso (II de IV)
- Hacking de aplicaciones Lasso (III de IV)
- Hacking de aplicaciones Lasso (IV de IV)
**************************************************************************************************
No hay comentarios:
Publicar un comentario