2013-07-16 8 views
5

Sono di fronte a un problema in un'applicazione iOS che utilizza UIWebView per il rendering di codice HTML5 che fa parte del pacchetto di applicazioni.Dati sensibili memorizzati nel file cache.db-wal?

Questo codice HTML5 consente ajax di richiedere al nostro back-end che potrebbe contenere dati sensibili. Questo è tutto fatto su HTTPS e la nostra applicazione non memorizza mai i dati sensibili. Tuttavia, durante i test di sicurezza per l'applicazione, abbiamo rilevato che le richieste HTTP venivano archiviate in un database SQL Lite locale (cache.db) a partire da iOS 5.

È stato facile gestirlo impostando NSURLCache oggetto globale per avere zero storage su disco ed eliminare il file quando appropriato.

Ora, tuttavia, in iOS 6.1 Apple ha cambiato di nuovo l'implementazione e i dati vengono archiviati in cache.db-wal. Ho una conoscenza limitata di SQL Lite, ma penso che questo sia un file creato quando SQL Lite è inizializzato con determinate opzioni.

Qualche suggerimento per una correzione?

+1

Un po 'più informazioni sulla memorizzazione nella cache del disco delle richieste di URL. http://petersteinberger.com/blog/2012/nsurlcache-uses-a-disk-cache-as-of-ios5/ – Casey

+0

La sperimentazione nel nostro negozio suggerisce che l'impostazione "Cache-Control: no-cache, no-store" può prevenire la memorizzazione nella cache. Stiamo ancora ricontrollando, comunque. Si prega di tenere tutti aggiornati sullo stato di questo. –

risposta

4

Dopo ulteriori ricerche, sembra che il suggerimento di Hot Licks sopra fosse corretto, aggiungendo il valore "no-cache, no-store" alla risposta HTTP, la richiesta HTTP valori non registrati nel database SQLite.

Per esempio, in ASP.Net MVC:

public ActionResult PostSensitiveData(string data) 
{ 
    Response.Cache.SetCacheability(HttpCacheability.NoCache); 
    Response.Cache.SetNoStore(); 

    return Json(data); 
} 
1

Gli altri file creati da SQLite (-journal, -wal, -shm) fanno parte del database stesso.

Quando si elimina il file cache.db, eliminare anche eventuali file cache.db-*.


Per evitare che i dati viene inserito, in primo luogo, aprire il database e creare un po 'di innesco come questo su ogni tavolo:

CREATE TRIGGER MyTable_evil_trigger 
BEFORE INSERT ON MyTable 
BEGIN 
    SELECT RAISE(IGNORE); 
END; 

(E poi verificare se l'UIWebView fa saltare in aria quando l'inserimento record in realtà non vengono visualizzati ...)

+0

Non lo accetto come una risposta ideale, anche se funzionerà sicuramente. Ecco la cosa, Apple ha infranto il contratto Http 1.1 memorizzando nella cache i dati come questo senza riguardo per il controllo della cache, e stanno memorizzando i dati nella cache sui post http! – Casey

+0

Se si eliminano i file cach.db- *, vengono comunque creati e, almeno per un periodo di tempo, i dati sensibili vengono scritti sul dispositivo ed è vulnerabile. È piuttosto facile recuperare queste informazioni utilizzando strumenti come iExplorer e Blocco note se è possibile ottenere l'accesso fisico al dispositivo. – Casey

+0

questa è una risposta molto creativa, e anche se sembra un po 'hacky, probabilmente sarà l'opzione migliore. Ho fatto ricerche approfondite su questo e ci sono poche informazioni.Sospetto che ci siano un sacco di applicazioni là fuori che sono interessate da questo ed esporre informazioni sensibili nel db NSURLCache. – Casey

1

È possibile chiamare

[[NSURLCache sharedURLCache] removeAllCachedResponses] 

Questo cancellerà tutte le chiamate URL memorizzati nella cache dal file cache.db.

Problemi correlati