¿Qué hace que una aplicación de Android sea vulnerable a la inyección SQL?

2

Definición de inyección SQL

La inyección SQL es una técnica de inyección de código, utilizada para atacar aplicaciones controladas por datos, en la que se insertan sentencias SQL maliciosas en un campo de entrada para su ejecución (por ejemplo, para volcar el contenido de la base de datos al atacante).

Cómo afecta la Inyección SQL al Android O.S

El SQLite utilizado en las aplicaciones de Android son bases de datos totalmente funcionales, por lo que, al igual que SQL Server o MySQL, pueden ser susceptibles a la inyección de SQL. La inyección SQL normalmente funciona agregando datos a la cadena de consulta o agregando datos en un campo de formulario; para dar a los piratas informáticos acceso a una base de datos o inicios de sesión no autorizados. La inyección SQL se usa generalmente para atacar vistas web o un servicio web, pero también se puede usar para atacar actividades.

La causa raíz de la vulnerabilidad de Inyección de SQL se debe al uso de consultas SQL dinámicas o concatenadas. Si las consultas SQL se construyen concatenando entradas proporcionadas por el usuario; Luego, el usuario puede suministrar vectores de ataque de SQL en lugar de entradas válidas y manipular la consulta de SQL de fondo.

El proceso de inyección funciona al terminar prematuramente una cadena de texto y agregar un nuevo comando. Debido a que el comando insertado puede tener cadenas adicionales agregadas antes de que se ejecute, la cadena inyectada termina con una marca de comentario "-". El texto posterior se ignora en el momento de la ejecución.

Mi pregunta

Aunque entiendo qué es la Inyección SQL y cómo puede tener lugar la Inyección SQL . No sé qué factores hacen que una selección de código de Android sea vulnerable a tal ataque.

    
pregunta 22.05.2015 - 19:14
fuente

2 respuestas

3

Los ataques de inyección de SQL se aplican cuando una aplicación usa SQL y ensambla descuidadamente las solicitudes de SQL con elementos proporcionados por el atacante. Aquí, "descuidadamente" significa "sin usar declaraciones preparadas ". Las declaraciones preparadas son la forma correcta de hacer SQL con datos proporcionados externamente; muchos desarrolladores intentan pensar en ello en términos de "escapar de los caracteres de comillas", lo que es un mal método y conduce al desastre (aunque a la larga sucede un escape, solo las declaraciones preparadas garantizan que se haga correctamente).

Android no es un factor en todo esto, excepto de manera muy indirecta: Android viene con SQLite , por lo tanto, los desarrolladores están muy tentados de usarlo y, por lo tanto, juegan con SQL, incluso en los casos en que no es estrictamente necesario. Cuando su única herramienta es un martillo, es mejor que los problemas sean clavos, porque va a haber algunos golpes graves. Por supuesto, cuando los desarrolladores tienen el poder de SQL pero no son lo suficientemente cuidadosos como para usarlo correctamente, los ataques de inyección de SQL se convierten en una posibilidad definitiva.

Otro efecto es que las aplicaciones de Android se basan en un lenguaje similar a Java, que está inherentemente protegido contra los desbordamientos de búfer (porque todos los accesos a la matriz se verifican sistemáticamente) y las situaciones de doble uso y después del uso (debido al GC basada en la gestión de memoria). Por lo tanto, otros tipos de ataques constituyen mecánicamente una mayor proporción de todas las vulnerabilidades generales. Tener muchas vulnerabilidades de inyección SQL en las aplicaciones de Android puede ser, de hecho, el resultado de tener comparativamente muchos menos tipos de ataques.

    
respondido por el Tom Leek 22.05.2015 - 19:34
fuente
1

SQLite admite consultas preparadas y parámetros enlazados, por lo que el problema es más con el uso de la herramienta, en lugar de la propia herramienta.

Si se usan parámetros de consulta, es imposible inyectar SQL en el proceso porque los datos se manejan por separado de la declaración. El problema solo surge si el desarrollador ha hecho algo como:

SQLStatement="seleccione * entre los usuarios donde password = '" + thePassword + "' y email = '" + theEmailAddr + "';";

Esto se debe a que le da al usuario final la oportunidad de escribir una contraseña que termina la declaración y agrega otra, o especifica las condiciones en las que cualquier contraseña funcionaría. Por ejemplo, si el usuario escribe una contraseña de

' or password!='fred

y una dirección de correo electrónico real, digamos [email protected], luego la consulta enviada a la base de datos es:

select * from users where password='' or password!='fred' and email='[email protected]';

Si usa parámetros, no hay opción para inyectar un nuevo sql en el texto del comando, porque los datos se tratan por separado del comando.

    
respondido por el Keith Procter 22.05.2015 - 19:41
fuente

Lea otras preguntas en las etiquetas