Recentemente ho scritto sulla protezione dell'idea di un'app e sul perché non vale la pena di brevettare la tua app prima che sia effettivamente lanciata. In termini di concetto di design, elementi UI e principi UX, c'è una parte ingegneristica che è tanto intricata quanto importante per la fattibilità del progetto.
Se si può mettere sotto copyright il design e l'identità, cosa succede dietro le linee di codice? Sono protette dal plagio? Come mai ci sono così tanti aap identici? È solo perché "le grandi menti pensano allo stesso modo"? O c'è una furia in corso? Cercherò di rispondere a queste domande con l'aiuto dei miei colleghi sviluppatori mobili.
Cosa può succedere con applicazioni non protette
Il codice sorgente delle applicazioni è l'essenza di ogni applicazione. Centinaia di ore di lavoro, tutte le conoscenze, le scoperte, le soluzioni con il nastro adesivo e ogni singola speranza di successo sono nascoste nel codice sorgente dell'applicazione. Come il ventre di una bestia è vulnerabile e le conseguenze di un suo danneggiamento sono terribili.
Quindi se qualcuno ruba o decompila un pezzo del codice sorgente della vostra applicazione, o l'intero codice, in pratica dirotta la vostra applicazione iOS o Android, cosa potete fare? Gli scenari peggiori includono i seguenti risultati:
- La vostra app viene craccata. Se la vostra app è a pagamento, il cattivo può farne una versione gratuita e uccidere il vostro modello di business. Questo richiederà molto probabilmente che tu abbandoni il tuo progetto e ne crei un altro. Scelta difficile.
- La vostra app viene infettata. Mantengono l'app pagata e normale, ma la infettano con virusware o malware per creare schemi truffaldini sulle build successive. In questo caso i vostri fedeli utenti ricevono un calcio nei denti che rovina tutto quello che avete costruito. Questa è una brutta situazione e molto probabilmente vi costringerà ad uscire dal business, per non parlare dei problemi legali.
- La vostra app diventa una cavia. Se l'app che hai creato ha un qualche successo, ha un bersaglio sulla schiena. Se i vostri concorrenti entrano in possesso del codice sorgente della vostra app, la faranno a pezzi e prenderanno pezzi del vostro precedente vantaggio competitivo. Molto probabilmente porrà fine alla vita della vostra app.
Ora rilassiamoci un po' e guardiamo come e perché il codice sorgente della vostra applicazione può essere rubato. Una volta che l'applicazione è uscita, ci si può aspettare che la gente cominci a pasticciare con essa.
Il Reverse Engineering dell'applicazione ne vale la pena?
A parte tutto il dramma, avere il codice rubato è una seccatura che se non rovina il vostro marchio, potrebbe essere un'enorme distrazione che distrae il tempo da ciò che conta davvero - i vostri obiettivi di business. A Shakuro, consideriamo il codice sorgente di un'applicazione la nostra responsabilità al 100%. La sua sicurezza e l'impermeabilità devono essere costantemente testate man mano che le funzionalità vengono implementate.
Sicurezza del codice iOS
Le nostre app iOS hanno un codice scritto in Objective-C e Swift che si compila in un codice binario. Il codice sorgente è memorizzato sul nostro repository privato GitHub, o su repository lato client. L'interazione app-server dei dati utente passa attraverso funzioni native di iOS o un certificato OpenSSL per crittografare il traffico per una maggiore protezione.
Questo fondamentalmente trasforma le nostre app iOS in scatole nere che non si possono realmente vedere. Ma con una certa quantità di persistenza, si può sbirciare da diverse angolazioni e pescare qualcosa. Le app consistono di diverse parti come:
- Eseguibile criptato - codice compilato, il nucleo.
- Metadati - variabili.
- Frameworks criptati - moduli.
- Asset - immagini, stringhe, ecc.
La parte eseguibile è quella che di solito viene schermata per proteggere l'app dalle intrusioni. Anche i framework possono essere intercettati. Un reverse engineer può lavorare con due stati di un'app - attivo e inattivo. Possono studiare il traffico e iniettare codice quando l'app è in esecuzione, e studiare i binari quando l'app non è in esecuzione. Decrittare il codice binario richiede un'ampia serie di competenze degne di uno sviluppatore di app molto competente.
Oltre a questo, Swift essendo una tecnologia abbastanza nuova è sicura per natura in quanto gli strumenti per scomporre il suo codice non sono ancora presenti. Come per Objective-C, ci sono molteplici strumenti complicati che devono essere utilizzati specificamente per alcune parti del processo di reverse engineering e richiedono così tanto sforzo, che quasi annulla l'effetto, per non parlare del fatto che è immorale e illegale.
Obfuscazione del codice iOS
Se qualcuno sta effettivamente cercando di decompilare il codice Swift, è nativamente offuscato. Citando hotpaw2 da stack overflow: "Xcode converte anche il codice Swift in una sorta di bytecode di rappresentazione intermedia, chiamato bitcode da Apple. Ma, IIRC, il bitcode viene rimosso da Apple prima di inviare un'app ai clienti, e il codice compilato dell'app è anche criptato da Apple."
Invece di mettere tempo nel complessificare il codice dell'app che non è visibile nella build, ciò che ci sforziamo davvero di proteggere sono le librerie SDK che contengono moduli personalizzati.
In aggiunta alle caratteristiche native, possiamo usare Obfuscator che è uno strumento per l'offuscamento delle stringhe sensibili alla sicurezza hard-coded. Obfuscator trasforma le stringhe in array di byte e invece di passarli attraverso l'app, decodifica gli array di byte per rivelare le stringhe. Non richiede che l'intero codice dell'applicazione sia offuscato, ma vi dà la scelta di influenzare solo le stringhe più cruciali.
Sicurezza del codice Android
Non c'è modo di fornire una sicurezza al 100% di un'applicazione Android. Se qualcuno si impegna ad entrare nel codice della vostra applicazione, lo farà. L'unico modo per combatterlo è renderlo insensato.
Nel caso di un'applicazione iOS scritta in Swift è un processo difficile e minuzioso, a causa della sua relativa novità, ma che dire di Java? Esiste da decenni e ci sono milioni di sviluppatori. Considerando le peculiarità del sistema operativo Android, ecco come è possibile proteggere un'applicazione. Il codice sorgente delle applicazioni Android è generalmente scritto in Java, ma non viene distribuito nelle build come bytecode Java, invece viene caricato in file .dex, che possono essere decompilati in codice sorgente Java. L'unica contromisura efficace su cui la comunità sembra essere d'accordo è l'offuscamento.
Obuscazione del codice Android
Uno dei modi più potenti per proteggere un APK Android è l'offuscamento del codice. Questa pratica cambia i nomi delle variabili dell'app e le classi su base regolare per rendere le stringhe di codice confuse e rompere le dipendenze. Ma è più di questo. L'offuscamento del codice riduce anche il codice, nasconde alcuni snippet e lo rimpicciolisce significativamente. Alcuni degli strumenti di offuscamento più popolari sono:
- Proguard
- DexProtector
Questi sono strumenti solidi che impediscono le intrusioni attraverso alcuni forti algoritmi crittografici, mentre iniettano anche controlli di sicurezza in Android APK. L'app può essere bloccata una volta che lo strumento si rende conto che il codice dell'app viene intercettato.
Android Application Licensing
Una caratteristica incorporata nelle licenze delle applicazioni Android è il tentativo di applicare una politica di licenza flessibile su una base di applicazione per applicazione - ogni applicazione può applicare la licenza nel modo più appropriato per essa. Quando un'applicazione controlla lo stato delle licenze, il server di Google Play firma la risposta allo stato delle licenze usando una coppia di chiavi che è associata unicamente all'applicazione. L'applicazione memorizza la chiave pubblica nel suo file .apk compilato e la utilizza per verificare la risposta dello stato della licenza."
"Per esempio, un'applicazione può controllare lo stato della licenza e poi applicare vincoli personalizzati che permettono all'utente di eseguirla senza licenza per un periodo di validità specifico. Un'applicazione può anche limitare l'uso dell'applicazione a un dispositivo specifico, oltre a qualsiasi altro vincolo". Questa funzione viene già utilizzata per integrare la sicurezza e la trasparenza nell'uso del codice dell'app lato client.
Linee guida generali sulla sicurezza delle app di Shakuro
Come potrebbe sembrare, il codice non è la parte più preziosa della vostra app, certamente è il cuore di un'app, ma è quasi controintuitivo quanto ci voglia per decompilare il codice e costruirne un clone. Invece, ci sono alcuni problemi specifici del mobile che riguardano il bene più prezioso che avete: le informazioni. L'obiettivo principale dello sviluppatore è quello di mantenere le informazioni sicure e private.
Salvataggio dei dati
Se un'app memorizza i dati dell'utente, in particolare credenziali, token e chiavi di accesso, queste cose devono essere protette meglio di un semplice file Info.plist. Invece, usate i servizi di portachiavi del sistema nativo o librerie di terze parti per una memorizzazione sicura. Anche usare la cache e non fare il backup di tutti i dati sui servizi cloud può risparmiare spazio e impedire a qualcuno di analizzarli.
Canali di comunicazione sicuri
Il protocollo HTTP è un metodo di comunicazione da app a server non criptato. Gli spot Wi-Fi pubblici a cui molti telefoni si connettono quotidianamente possono essere il mezzo per attacchi man-in-the-middle. Quindi, se qualcosa di riservato o critico per la sicurezza viene inviato avanti e indietro, HTTPS è il canale di comunicazione più sicuro. Per i protocolli di rete personalizzati, utilizzare TLS.
Dati dell'utente
Come sempre più app vengono integrate nelle nostre vite attraverso varie funzioni utili, i telefoni diventano gli ultimi hub di informazioni personali e sensibili che devono essere memorizzate in modo responsabile. Se un utente concede alla tua app l'accesso a queste informazioni, non dovrebbero essere duplicate e conservate separatamente da qualche parte. Consideriamo fortemente dove memorizziamo le informazioni e utilizziamo solo fonti non compromesse.
Consigli specifici per Android
- Evitare la Webview a causa delle vulnerabilità dell'interfaccia Javascript.
- Evitare la ri-delega dei permessi a causa dell'accesso non autorizzato di app di terze parti.
- Evitare Intents a causa dei rischi di essere intercettati.
- Evitare SQL Injections a causa dell'introduzione involontaria di vulnerabilità.
Bottomline
Uno dei modi migliori per resistere è rendere il succo non degno di essere spremuto. Lo scopo della pirateria delle app è quello di rubare un'app e ottenere una sorta di ricompensa per questo. Se l'importanza della ricompensa non batte il tempo e lo sforzo messi in campo, i pirati opportunisti e gli hacker abbandoneranno. Alla fine della giornata, sono anche uomini d'affari... immorali e illegali, ma sostenuti da una logica contorta.
La stragrande maggioranza degli sviluppatori dice che se qualcuno vuole fare il reverse engineering di un'app, lo farà.
È giusto dire che il codice sorgente non è il motivo per cui i clienti apprezzano gli sviluppatori. Sì, è l'output e il risultato di tutto il duro lavoro, ma non è la ragione per cui ci pagano. Quando i clienti assumono un team, investono nella soluzione del loro compito che va oltre il codice. Decidono di assumere un team in base alle loro capacità tecniche, alla loro esperienza, al loro modello di business, ecc. Noi conquistiamo i clienti per il modo in cui comunichiamo e ci sforziamo di capire sinceramente i loro progetti, e mostriamo il nostro impegno una volta iniziato.