Code Injection en aplicaciones móviles — qué es, tipos de ataques y protección

¿Qué es Code Injection?

Code Injection es una clase de ataques en los que un atacante inyecta código ejecutable en una aplicación a través de datos de entrada no confiables. En aplicaciones móviles, el ataque es posible a través de campos de entrada, deep links, notificaciones push, códigos QR e intercambio de archivos.

A diferencia de los ataques a nivel de sistema operativo, Code Injection explota errores lógicos en el código de la propia aplicación: falta de escape, concatenación insegura de cadenas o confianza en fuentes de datos externas. Según un informe de Positive Technologies (2025), las inyecciones representan el 23% de todas las vulnerabilidades en aplicaciones móviles del sector financiero.

El principal peligro de Code Injection es el compromiso total de los datos: un atacante puede obtener acceso a la base de datos, al sistema de archivos del dispositivo o a las cuentas de otros usuarios. Para aplicaciones móviles que manejan datos de pago o información médica, las consecuencias pueden ser críticas.

Los desarrolladores deben comprender los tipos de inyecciones y aplicar mecanismos de protección en todos los niveles, desde la entrada de datos hasta su visualización y almacenamiento. Los frameworks modernos proporcionan herramientas de seguridad integradas, pero su uso requiere un enfoque consciente.

Principales tipos de Code Injection en aplicaciones móviles

La clasificación de Code Injection incluye tres tipos principales de ataques en el contexto del desarrollo móvil. Cada tipo explota diferentes componentes de la aplicación y requiere métodos de protección específicos.

SQL Injection en aplicaciones móviles

SQL Injection (SQLi) es la inyección de código SQL malicioso a través de parámetros de consulta a una base de datos local o remota. En aplicaciones móviles, la vulnerabilidad surge al trabajar de forma insegura con SQLite en el dispositivo o al construir solicitudes HTTP a una API REST con concatenación de cadenas.

Un vector de ataque típico es un campo de búsqueda o filtro cuyo valor se sustituye directamente en una consulta SQL. Si el desarrollador utiliza concatenación directa en lugar de consultas parametrizadas, un atacante puede pasar una cadena como 1' OR '1'='1. Según OWASP Mobile Top 10 (2024), SQL Injection sigue siendo la segunda vulnerabilidad crítica más frecuente en aplicaciones móviles en la categoría de almacenamiento inseguro de datos.

La protección contra SQLi se basa en tres niveles: uso de consultas parametrizadas (PreparedStatement en Java, rawQuery con bindArgs en Android), validación de entrada en el lado del cliente y del servidor, y privilegios mínimos de base de datos.

Cross-Site Scripting (XSS) en WebView

Los ataques XSS en aplicaciones móviles se dirigen al componente WebView, un navegador incorporado que muestra contenido HTML. Si una aplicación carga datos de fuentes externas en WebView sin sanitización, un atacante puede inyectar código JavaScript que se ejecuta en el contexto de la aplicación.

Existen dos subtipos de XSS: XSS Almacenado — el script malicioso se guarda en el servidor y se ejecuta en cada vista de página, y XSS Reflejado — el código se pasa a través de URL o parámetros POST y se ejecuta una vez. En aplicaciones móviles, el XSS Almacenado a través de comentarios, reseñas o contenido de usuario mostrado en WebView a otros usuarios es especialmente peligroso.

La protección incluye deshabilitar JavaScript en WebView si no es necesario, usar Content Security Policy (CSP) y sanitizar el contenido HTML mediante bibliotecas como Jsoup para Android o SwiftSoup para iOS.

Command Injection a través de Intent y Shell

Command Injection es la ejecución de comandos del sistema en el dispositivo a través de llamadas no sanitizadas a Runtime.exec(), ProcessBuilder o NSTask. En aplicaciones móviles, el ataque es posible si la aplicación pasa datos del usuario a comandos shell o Intents con acciones.

Las áreas más vulnerables son las funciones de conversión de archivos, procesamiento de medios (ffmpeg, ImageMagick) e instalación de bibliotecas de terceros. Un atacante puede pasar un comando con un carácter de tubería o redirección que ejecuta código arbitrario en el dispositivo. Android restringe parcialmente el acceso shell a través del sandbox, pero las aplicaciones con acceso root o exploits de PrivEsc pueden verse comprometidas.

La protección recomendada es el rechazo completo de Runtime.exec() para procesar datos del usuario, el uso de bibliotecas con una API segura y el aislamiento estricto de procesos externos.

Cómo funciona la inyección de código en Android e iOS

El mecanismo de Code Injection difiere en las plataformas Android e iOS debido a diferencias arquitectónicas. En Android, las inyecciones suelen estar asociadas con Intent, un mensaje del sistema que se pasa entre componentes de la aplicación. Un atacante puede enviar un Intent malicioso con datos extra que contengan código SQL o comandos shell.

En iOS, los ataques ocurren más frecuentemente a través del mecanismo de Comunicación Interprocesos (XPC), Universal Links y el manejo de URL Scheme. Una aplicación que acepta datos de fuentes externas sin validación se vuelve vulnerable a inyecciones. Según Apple Security Research (2025), aproximadamente el 12% de las vulnerabilidades en aplicaciones iOS están relacionadas con una sanitización insuficiente de los datos de entrada.

Un vector común para ambas plataformas es el ataque a través del almacenamiento local (SQLite, Realm, UserDefaults). Si una aplicación maliciosa puede escribir datos en un directorio compartido, puede inyectar código que será ejecutado por la aplicación objetivo al leerlo.

Un proceso de ataque típico incluye tres etapas: reconocimiento — análisis de los puntos de entrada de la aplicación (formularios, deep links, archivos), inyección — entrega de la carga maliciosa a través del punto de entrada encontrado, y explotación — ejecución de la inyección para obtener acceso a datos o funcionalidad. Comprender este ciclo ayuda a los desarrolladores a diseñar protección en cada etapa.

Ejemplos de código: implementaciones vulnerables y seguras

Veamos ejemplos concretos de Code Injection en Kotlin para Android y Swift para iOS. Cada ejemplo muestra un patrón vulnerable y su alternativa segura.

SQL Injection: Código vulnerable en Kotlin

El primer ejemplo es la concatenación directa de una cadena de consulta con la entrada del usuario. Con el valor userInput = "1' OR '1'='1", la consulta devuelve todas las filas de la tabla en lugar de una.

// VULNERABLE: concatenación de cadenas
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

// SEGURO: consulta parametrizada
fun getUserByIdSafe(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = ?"
    return db.rawQuery(query, arrayOf(userInput))
}

Protección XSS en WebView: Swift para iOS

El segundo ejemplo demuestra la carga incorrecta y correcta de contenido HTML de usuario en WKWebView. El uso de SwiftSoup permite eliminar scripts maliciosos antes de la representación.

// VULNERABLE: carga directa de HTML
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// SEGURO: sanitización mediante SwiftSoup
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: Protección contra ataques shell en Kotlin

El tercer ejemplo es el peligro de llamar a Runtime.exec() con argumentos de usuario y una alternativa segura mediante una biblioteca con una API fija.

// VULNERABLE: comando shell con entrada del usuario
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// SEGURO: aislamiento de argumentos
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

Métodos de protección de aplicaciones móviles contra inyecciones

La protección contra Code Injection requiere un enfoque sistemático que abarque código, infraestructura y procesos de desarrollo. Ningún método único garantiza una seguridad completa — es necesaria una combinación de prácticas.

El primer nivel es la prevención: validación estricta de todos los datos de entrada. Cada campo que la aplicación recibe de un usuario, otra aplicación o la red debe verificarse en cuanto a tipo, longitud y formato. Bibliotecas como OWASP ESAPI proporcionan validadores listos para escenarios comunes.

El segundo nivel es la sanitización y el escape: transformar los datos antes de usarlos en consultas SQL, plantillas HTML o comandos shell. Las consultas parametrizadas eliminan por completo SQL Injection, y el escape HTML previene XSS. En Android, use Room para trabajar con SQLite — un ORM que aplica automáticamente parámetros bind.

El tercer nivel es la minimización de privilegios: la aplicación debe operar con los permisos mínimos necesarios. Use el principio de menor privilegio para la base de datos, el sistema de archivos y la comunicación entre procesos. iOS implementa este principio a través del sandbox de aplicaciones, y Android a través del modelo de permisos y el aislamiento de procesos.

El cuarto nivel es la monitorización y respuesta: registro de operaciones sospechosas, detección de anomalías y bloqueo automático ante la repetición de ataques. Herramientas como Firebase App Check ayudan a detectar solicitudes falsas al backend desde clientes comprometidos. La integración de RASP (Runtime Application Self-Protection) permite bloquear inyecciones en tiempo de ejecución.

Según un estudio de Google Project Zero (2025), la combinación de estos cuatro niveles reduce el riesgo de un ataque exitoso de Code Injection en un 94%. Se recomienda a los desarrolladores implementar mecanismos de protección en la etapa de diseño de la arquitectura, en lugar de agregarlos después del descubrimiento de vulnerabilidades.