TikTok su iOS: il browser in-app traccia gli input dell'utente

TikTok su iOS: il browser in-app traccia gli input dell'utente

Dopo le app di Meta, anche TikTok fa uso di un codice JavaScript con il proprio browser in-app per tracciare gli input e le interazioni dell'utente

di pubblicata il , alle 09:12 nel canale Sicurezza
TikTokiOS
 

Il ricercatore di sicurezza Felix Krause, che la scorsa settimana aveva evidenziato la presenza di un codice di tracciamento all'interno delle app di Meta per iOS, ha scoperto un comportamento simile anche nel browser in-app dell'applicazione TikTok per iOS. Anche in questo caso infatti Krause ha individuato che il browser inietta un codice JavaScript nei siti web visitati tramite esso e che permette a TikTok di tracciare tutti gli input e i tocchi della tastiera mentre l'utente sta interagendo con il sito.

Krause sottolinea che dal momento che vengono tracciati tutti gli input della tastiera, ovviamente anche qualsiasi password o altra informazione sensibile può essere registrata. "Dal punto di vista tecnico è come se si trattasse di un keylogger su siti web terzi". Krause ha comunque voluto specificare che la presenza di questo codice non è da sola prova del fatto che l'app stia facendo qualcosa di dannoso.

TikTok ha riconosciuto la presenza del codice in questione, ma afferma che si tratta di una misura che non viene usata per scopi diversi dal debug, dalla risoluzione dei problemi e dal monitoraggio delle prestazioni. Un portavoce della società ha dichiarato a Forbes: "Come altre piattaforme facciamo uso di un browser in-app per fornire un'esperienza utente ottimale, ma il codice Javascript in questione viene usato solo per debug, risoluzione di problemi e monitoraggio delle prestazioni di tale esperienza, come controllare la velocità di caricamento di una pagina o un eventuale arresto anomalo".

Il ricercatore consiglia di utilizzare, per una maggiore cautela, il browser predefinito su iOS evitando qualsiasi browser in-app. Per fare questo sono possibili due strade: la prima è verificare che l'app metta a disposizione la possibilità di aprire il collegamento in un browser esterno, mentre la seconda è quella di copiare "a manina" il collegamento nella barra degli indirizzi del browser e assicurarsi eventualmente che nell'indirizzo stesso non siano presenti eventuali suffissi anomali.

Krause ha realizzato uno strumento che permette a chiunque di verificare se un browser in-app sta iniettando codice JavaScript durante il caricamento di un sito web: è sufficiente aprire l'app che si desidera analizzare, condividere l'indirizzo InAppBrowser.com all'interno dell'app così da poterlo aprire con il browser inegrato e visionare i dettagli del resoconto che viene mostrato.

Quando Krause aveva individuato questo comportamento nelle app di Meta, la società aveva replicato affermando che si tratta di un codice "sviluppato intenzionalmente per onorare le scelte di trapsarenza del tracciamento delle app delle persone" sulle loro piattaforme.
1 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
lollo919 Agosto 2022, 09:52 #1
se quello che fa drizzare le antenne è appunto la JS injection, la soluzione sarebbe abbastanza semplice per Apple, come per Google.
il fatto è che non si tratta affatto di JS injection. Felix Krause non è un cretino, e lo so che le keywords come injection, keylogger etc. fanno un bell'effetto, ma da parte sua dovrebbe davvero aggiustare la terminologia.

TikTok, come ogni in-app browser di ogni altro social, ti fa passare da una rotta dedicata dalla quale ti servono JS con varie strategie, ma tendenzialmente due: o import-maps/microfrontend/affini, o un index specifico che referenzia del JS sempre residente su quel server.
questa NON è JS injection per definizione, è tutto first-party serving. l'esatto opposto.
che cosa sarebbe sentry.io allora? o logrocket?? od i vari tool di telemetria realtime che un qualsiasi framework web cabla di suo nelle build di produzione?
già oggi non puoi referenziare del JS esterno utilizzando JS stesso. e non puoi nemmeno lasciare che sia il bundle ad andare a recuperare JS per vie traverse da iniettarti nella webview, un po' per tutte le policy di cross-* che ci sono, un po' perché quello sì che Apple te lo casserebbe.

altra questione è interrogarsi su COSA possa fare il JS di una webview in-app, in particolare quali eventi possa ascoltare. e questa è materia per i vendor Apple e Google su tutti, ma poi pure MS, Mozilla e via giù fino al W3C.

ma come fai a bloccare selettivamente l'event queue di JS? non funzionerebbe niente. od ad aggiungiere un sistema di autorizzazioni sui listener? se ne riparlerebbe tra almeno 10 anni... il fatto è che il contenuto di una webview è dinamico per definizione, e visto che non puoi sapere cosa sarà servito in anticipo, l'unica strada è lavorare su un runtime "light" che per ora non esiste.
si è ormai creata questa prassi di buttare di tutto dentro una webview, puntare un revrese proxy da qualche parte e "decorare" al volo i contenuti. brutta gatta da pelare

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^