Le app Nativescript sono sicure?

   

20

             

2

SafeValue must use [property]=binding:

Le app Nativescript sono sicure?


Nativescript può essere considerata una tecnologia ancora giovane nel contesto delle hybrid mobile application.

Anche se la versione 1.0.0 risale al 2015, la community di sviluppatori deve ancora crescere del tutto e le aziende stanno cominciando a prendere in considerazione l’utilizzo di Nativescript per i loro progetti .

Bisogna pero’ comprendere che l’approccio degli sviluppatori e delle aziende è su certi aspetti ben diverso e ciò vale per tutte le nuove tecnologie che approdano sul mercato.

Se i primi sono interessati alla conoscenza di una nuova tecnologia e invogliati a contribuire attivamente per farla crescere, le imprese necessitano di soluzione solide, sicure e che portino un reale guadagno al business.

Per questo il team di Nativescript si sta muovendo per fornire agli sviluppatori, strumenti e best practices per le app di produzione, 3 giorni fa dalla scrittura di questo articolo, è iniziata una serie dedicata alla sicurezza in Nativescript con l'obbiettivo di spiegare gli aspetti più critici da tenere in considerazione.

Qui non faro’ un copia incolla di ciò che è stato detto, l'articolo completo lo potete trovate qui, ma mi piacerebbe fare un commentary e analizzare i punti focali dell’articolo

Partiremo con il primo del 14/01/2019 e proseguiremo nei prossimi giorni a commentare quelli che usciranno.

Questo primo articolo è prettamente mirato a coloro che si avvicinano per la prima volta alle app ibride e a javascript, se hai mai sviluppato con altri framework come questo o sviluppato un app web, molti di questi punti, se non tutti, ti sembreranno scontati, vale comunque la pena ripassare ogni tanto.

Inziamo.

Nativescript Best practice di Sicurezza Parte 1

L’articolo parte spiegandoci che, come altri framewrok per app ibride come Ionic e React Native, Nativescript è anch’esso un hybrid mobile framework basato su Javascript, perciò necessita di essere interpretato e inviato al device così com’è. 

A differenza delle app native, che vengono compilate ed eseguite dal dispositivo, Nativescript utilizza una compilazione JIT(Just In Time) che richiede il codice sorgente dell’app sempre disponibile al compilatore. 

La nostra app, con un po’ di reverse engineering, puo’ essere decompilata facilmente e copiata o manipolata.

Ci vengono quindi date delle vie per risolvere il problema che vengono largamente utilizzate in ambito web

Minificazione e Offuscazione

E’ una tecnica la quale, tramite un algoritmo molto semplice nella maggior parte dei casi, si rende il codice del software meno leggibile eliminando spazi, linee vuote ecc... .

Questa tecnica è lontana dall’essere realmente utile in ambiti di produzione in quanto non nasconde nulla alla vista e tutta la logica dei componenti può essere ricreata facilmente, esistono un sacco di software la fuori che fanno proprio questo lavoro.


Ce ne viene consigliata una delle più celebri, Uglify, che modifica un codice da così


const app = require("tns-core-modules/application"); 
const HomeViewModel = require("./home-view-model"); 

functiononNavigatingTo(args) 
    const page = args.object; page.bindingContext = new HomeViewModel(); 


functiononDrawerButtonTap(args) 
    const sideDrawer = app.getRootView(); sideDrawer.showDrawer(); 

exports.onNavigatingTo = onNavigatingTo; 

exports.onDrawerButtonTap = onDrawerButtonTap;


A così


const app=require("tns-core-modules/application"),HomeViewModel=require("./home-view-model");functiononNavigatingTo(o){o.object.bindingContext=new HomeViewModel}functiononDrawerButtonTap(o){app.getRootView().showDrawer()}exports.onNavigatingTo=onNavigatingTo,exports.onDrawerButtonTap=onDrawerButtonTap;

Per utilizzarlo subito in Nativescript, utilizza questi comandi durante la build

tns build android|ios bundle --env.uglify


Jscrambler

Seguendo la scia dei metodi di offuscazione , Jscrambler è un tool molto più avanzato che ti permetterà di creare codice davvero illeggibile grazie ad algoritmi che contrastano qualsiasi tipo reverse engeeneering

Qui un articolo dedicato per l’implementazione 

Sposta le logiche importanti dell’app in Cloud

Riprendendo il discorso precedente relativo al fatto che le app ibride necessitano della presenza del codice javascript sul device durante l’esecuzione, è logico pensare che il miglior modo per rendere inaccessibile quest’ultimo, è spostarlo letteralmente da un’altra parte.

Chi arriva dallo sviluppo di app web, questa cosa la conosce molto bene, sopratutto chi ha lavorato in contesti in cui esitono frontend e backend.
Il frontend, quindi un app Nativescript, deve solo preoccuparsi della presentazione dei dati, di come sono organizzati e dell’interazione utente, tutte le operazioni che vengono denominate di “business logic”, devono restare nel backend, non solo per motivi di sicurezza ma anche di performance, andando a spostare completamente il carico sui server che sono sicuramente più performanti.

Nell’articolo, i simpaticoni del team ci propongono FlexService, un loro servizio, in particolare di Telerik, che permette di creare sostanzialmente della api javascript completamente in Cloud.


Il servizio è indubbiamente interessante se non esistessero già soluzioni di questo tipo come Firebase, Azure e moltissime altre, senza parlare del fatto che vi basterebbe giusto una settimana di formazione per crearvi voi stessi un piccolo script in NodeJS che vi fornisca delle api da caricare su Heroku o DigitalOcean

Di tutto l’articolo ritengo questo sia il consiglio più utile se avete davvero il bisogno che ciò che venga scritto sul codice non possa assolutamente essere visto, in contesti aziendali questo è obbligatorio, immagina se Facebook includesse nei file javascript i propri algoritmi, oltre ad essere inutilizzabile per la pesantezza, smaschererebbe completamente il business aziendale.

Stai attento a non condividere chiavi di accesso

Un’ultimo consiglio è relativo all’upload del vostro codice sui sistemi di versioning come Git e altri.

Capita spesso infatti che gli sviluppatori non rimuovano file e riferimenti nel codice di chiavi di accesso a servizi come ad esempio Firebase, AWS e via dicendo.

Il consiglio è quello di modificare il file .gitignore nella folder principale del progetto e indicare per quali file non deve essere effettuato l’upload.

.vscode/ 
.cloud/ 
platforms/ 
node_modules app/**/*.js 
app/**/* .map 
npm-debug.log 
app/keys.* 
hooks/ 
app/**/google-services.json 
app/**/GoogleService-Info.plist 

Per i riferimenti nel codice, nel caso ce ne fossero, qui vi consiglio di googlare soluzioni specifiche per Angular, Vue e Javascript.

Qui l’articolo si conclude, come vi dicevo non sono consigli particolari per lo sviluppo in Nativescript, ma sono comunque delle best practices che gli sviluppatori alle prime armi o che hanno sviluppato sempre in nativo, apprezzeranno sicuramente.

Segui la mia pagina dedicata, Nativescript Italia Community, dove troverai altri articoli come questo e esiste anche un gruppo riservato dove puoi postare i tuoi quesiti e aiutare gli altri.

Grazie della lettura!

(see http://g.co/ng/security#xss)