¿Qué hace que una aplicación de Android sea vulnerable a los scripts entre sitios (XSS)?

4

Definición de XSS

Si busca en la web, hay muchas maneras diferentes de definir un ataque de scripts entre sitios. En pocas palabras, las vulnerabilidades de XSS ocurren cuando un atacante malicioso puede inyectar un script del lado del cliente en un sitio web que es visto por otras personas que se convierten en víctimas del ataque.

Un ejemplo de un error XSS dentro de Android O.S

  

Detalles de vulnerabilidad

     

Al enviar un intento creado a Chrome para Android, Android malicioso   las aplicaciones pueden inyectar JavaScript: URI en páginas web arbitrarias cargadas en   Cromo. JavaScript inyectado funciona en el contexto de la Web objetivo   El dominio de la página, no es un dominio en blanco. Así que puede ser utilizado para el robo de galletas.   más o menos. Este tipo de vulnerabilidades a menudo se llama aplicación cruzada   Scripting.

     

Version

     

Versión de Chrome: Chrome para Android v18.0.1025123 Sistema operativo:   confirmado en Android 4.0.4 (Samsung Galaxy Nexus)

     

Caso de reproducción

     

Se adjunta un código de muestra de una aplicación de Android maliciosa.

     

Nota

     

Este problema se informó inicialmente a [email protected] el 7 de julio.   2012, pero recientemente escuché del equipo de seguridad de Google que el problema   podría no estar archivado en la base de datos de errores de Chromium. Así que ahora vuelvo a enviar el   problema aquí, que debería ser un lugar legítimo para reportar Chrome   errores.

Mi pregunta

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

    
pregunta 22.05.2015 - 20:15
fuente

3 respuestas

1

El ejemplo específico no es Cross Site Scripting, es Cross App Scripting. Con una intención especialmente diseñada, una aplicación de Android podría forzar a otra aplicación (Chrome en este ejemplo) a ejecutar algún script en su contexto (Chrome).

Esto podría abusar de algunos mecanismos de privacidad y autenticación. Si no me falta algo, esta vulnerabilidad (corregida en Chrome hace bastante tiempo) permitió que una aplicación malintencionada secuestrase una sesión web abierta con el banco del usuario y aprobara la transferencia de dinero.

Esto es un poco exagerado, los sitios web de los bancos normales están protegidos contra tales ataques: requieren la confirmación del usuario (es decir, volver a ingresar la contraseña) para completar cualquier operación confidencial.

El problema con Chrome era que permitía que una aplicación de terceros se personificara a través de la intención adicional y no realizara una validación suficiente. Esto no fue un agujero de seguridad en el sistema operativo Android, y no fue un exploit que podría usarse estadísticamente contra aplicaciones aleatorias en su dispositivo, para encontrar una que no estuviera protegida.

    
respondido por el Alex Cohn 23.03.2017 - 12:12
fuente
-1

Es correcto que, en general, un ataque XSS es más un ataque a nivel de servidor. Alguien rellena un formulario o publica datos en un servidor, el servidor acepta esos datos y no puede sanearlos. Los datos se almacenan, potencialmente con javascript incrustado o redirecciones o enlaces a objetos remotos con cargas maliciosas. Alguien más visita el sitio y recupera los datos que se publicaron como abejas y el navegador interpreta los datos literales, ejecuta el javascript, recupera el objeto vinculado con una carga útil maliciosa, etc.

Entonces, ¿cómo se aplica esto a Android cuando su Android generalmente no es un servidor? En general, puede ser un problema porque muchas aplicaciones utilizan la misma tecnología para representar el contenido: esencialmente, html, javascript, etc. Por lo tanto, si tiene una aplicación de mensajes y solo acepta un mensaje entrante sin realizar ningún saneamiento de los datos, cualquier javascript o enlaces a objetos incrustados con cargas maliciosas se procesarán como en un navegador, esencialmente un ataque XSS.

    
respondido por el Tim X 29.05.2015 - 00:35
fuente
-1

En la mayoría de los casos, se debe a una implementación deficiente de webview . Para una instancia, el método setJavaScriptEnabled(true) en el WebSettings para un WebView se activará a una secuencia de comandos entre sitios. Depende de la capa lógica si la entrada se está almacenando & Por lo tanto el XSS persistente o lo refleja.

Lavistawebmásantiguaque4.2cuandohabilitejavascriptparaellasiempreserávulnerableaXSSamenosqueeldesarrolladoragreguelaanotaciónJavascriptInterfaceacualquiermétodoqueeldesarrolladordeseedisponibleparaelJavaScript.ParaaplicacionesqueejecutanAndroid4.2:sepuedeaccederatodoslosmétodospúblicosqueestánanotadosconJavascriptInterfacedesdeJavaScript.

OtrasvariantesdeWebviewpodríanseralgocomoesto:

this.webView.loadUrl("javascript:setContent(" + JSONObject.quote(this.content) + "," + i + ")");

Como puede ver, el código utilizó el mismo método (webView.loadUrl) para enviar datos a la parte HTML de la aplicación. Esto también activa XSS. Webview es principalmente responsable de XSS en Android.

    
respondido por el Shritam Bhowmick 22.12.2016 - 18:09
fuente

Lea otras preguntas en las etiquetas