Che cosa rende vulnerabile un'applicazione Android a Cross-site scripting (XSS)?

4

Definizione di XSS

Se esegui ricerche sul Web, esistono diversi modi per definire un attacco di cross site scripting. In poche parole, le vulnerabilità XSS si verificano quando un utente malintenzionato è autorizzato a iniettare uno script sul lato client in un sito Web che viene visualizzato da altre persone che diventano vittime dell'attacco.

Un esempio di bug XSS in Android O.S

Vulnerability Details

By sending a crafted intent to Chrome for Android, malicious Android apps can inject JavaScript: URIs into arbitrary Web pages loaded in Chrome. Injected JavaScript works in the context of the target Web page's domain, not a blank domain. So it can be used for Cookie theft or so. Such kind of vulnerabilities is often called Cross-Application Scripting.

Version

Chrome Version: Chrome for Android v18.0.1025123 Operating System: confirmed on Android 4.0.4 (Samsung Galaxy Nexus)

Reproduction Case

A sample code of a malicious Android app is attached.

Note

This issue was initially reported to [email protected] on Jul. 7 2012, but recently I heard from Google security team that the issue might not be filed in Chromium bug database. So now I re-submit the issue here which should be a legitimate place for reporting Chrome bugs.

La mia domanda

Anche se capisco quale Cross-Site-Scripting è e come può avvenire lo Cross-Site-Scripting . Non so quali fattori rendono vulnerabile una selezione di codice Android a tale attacco.

    
posta 22.05.2015 - 20:15
fonte

3 risposte

1

L'esempio specifico non è Cross Site Scripting, è Cross App Scripting. Con un intento appositamente predisposto, un'app per Android potrebbe forzare un'altra app (Chrome in questo esempio) ad eseguire alcuni script nel suo contesto (Chrome).

Ciò potrebbe abusare di alcuni meccanismi di privacy e autenticazione. Se non mi manca qualcosa, questa vulnerabilità (risolta in Chrome un po 'di tempo fa) ha permesso a un'app dannosa di dirottare una sessione web aperta con la banca dell'utente e approvare il trasferimento di denaro.

Questo è un po 'esagerato, i normali siti Web bancari sono protetti da tali attacchi: richiedono la conferma dell'utente (cioè reinserisci la password) per completare qualsiasi operazione sensibile.

Il problema con Chrome era che consentiva a un'app di terze parti di impersonarsi da sola tramite l'intento extra e di non eseguire una convalida sufficiente. Questo non era un buco di sicurezza nel sistema operativo Android, e non un exploit che poteva essere statisticamente utilizzato contro le app casuali sul tuo dispositivo, per trovare quello che non era protetto.

    
risposta data 23.03.2017 - 12:12
fonte
-1

Hai ragione che, in generale, un attacco XSS è più un attacco a livello di server. Qualcuno compila un modulo o pubblica i dati su un server, il server accetta quei dati e non riesce a disinfettarlo. I dati vengono memorizzati, potenzialmente con javascript o reindirizzamenti o collegamenti a oggetti remoti con payload dannosi. Qualcun altro visita il sito e recupera i dati che sono stati pubblicati e il browser interpreta i dati letterali, eseguendo il javascript, recuperando l'oggetto collegato con un carico utile dannoso ecc.

Quindi, come si applica ad Android quando il tuo Android non è di solito un server? In generale può essere un problema perché molte app utilizzano la stessa tecnologia per il rendering del contenuto, in sostanza, html, javascript ecc. Quindi, se si dispone di un'app di messaggio e accetta solo un messaggio in arrivo senza effettuare alcuna sanificazione dei dati, qualsiasi javascript o collegamenti a oggetti incorporati con payload dannosi verranno elaborati proprio come in un browser, essenzialmente un attacco XSS.

    
risposta data 29.05.2015 - 00:35
fonte
-1

Nella maggior parte dei casi, è dovuto a un'implementazione scadente di webview . Per un'istanza, il metodo setJavaScriptEnabled(true) su WebSettings per una WebView deve essere attivato in uno script cross site. Dipende dal livello logico se l'input viene memorizzato e amp; quindi XSS persistente o riflette.

Webviewprecedentealla4.2quandoAbilitijavascriptperquestorimarràsemprevulnerabileaXSS,amenochelosviluppatorenonaggiungal'annotazioneJavascriptInterfaceaqualsiasimetodochelosviluppatoredesiderasiadisponibileperJavaScript.PerleapplicazioniconAndroid4.2,èpossibileaccedereatuttiimetodipubbliciannotaticonJavascriptInterfacedaJavaScript.

AltrevariantidiWebviewpotrebberoesserequalcosadeltipo:

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

Come puoi vedere, il codice utilizzava lo stesso metodo (webView.loadUrl) per inviare dati alla parte HTML dell'applicazione. Anche questo fa scattare l'XSS. Webview è principalmente responsabile per XSS su Android.

    
risposta data 22.12.2016 - 18:09
fonte

Leggi altre domande sui tag