Quanto è facile la tempera del codice JavaScript per un'applicazione mobile? [chiuso]

Supponendo che tu stia parlando di un'applicazione web in esecuzione nel browser a causa dei tag:

Dipende, la manomissione di JavaScript è banale, se non vengono prese precauzioni e ciò vale anche per i dispositivi desktop / portatili.

La precauzione più semplice e più importante è usare HTTPS, quindi impedire che il codice venga modificato usando l'attacco MITM.

Altri più avanzati includono SRI, che richiede l'hash dello script da includere nell'intestazione o almeno un nonce utilizzato. Ciò migliora molto la sicurezza, in quanto un utente malintenzionato dovrebbe avere un controllo significativo del server per sovvertirlo.

Tuttavia, se un utente malintenzionato ha il controllo completo del server Web, non esiste attualmente alcun modo per mitigare tale attacco se non controllando manualmente lo script ogni volta.

Ci sono un lotto di vettori di attacco da difendersi in una moderna applicazione web, troppi per poterli approfondire qui.

Ma qui ci sono un paio di punti di alto livello da considerare:

Innanzitutto, l'applicazione lato server riceve richieste da un'applicazione JavaScript lato client, ma non ha modo di sapere se tali richieste provengono effettivamente da una copia non modificata del codice JavaScript, una versione con altro JavaScript immesso in esso, oppure un'applicazione completamente separata e personalizzata utilizzata da un utente malintenzionato. Pertanto non devi mai fidarti di qualsiasi dato proveniente dal server dall'esterno di Internet, indipendentemente dal fatto che provenga dal tuo codice JavaScript o meno: verifica sempre che sia autenticato correttamente e ben formato, per < em> ogni richiesta.

Per evitare attacchi come CSRF, dovresti anche assicurarti che ogni nuova richiesta in arrivo sia collegata a un'interazione utente esistente (ad esempio utilizzando token anti-CSRF), non in "out of the blue".

Ricorda che tu dai potenziali attaccanti tutto il codice sorgente alla tua applicazione lato client. Nulla di ciò che finisce nel JavaScript può essere considerato segreto o sicuro. L'offuscamento del tuo JavaScript non è una difesa, ma più un rallentatore. (Anche se è utile per minification e altri scopi.) Non dare per scontato che, poiché i browser mobili non rendono facile l'accesso a una console JavaScript, che quindi l'utente malintenzionato non avrà accesso a una console JavaScript su un dispositivo mobile (o un browser che finge di essere su un dispositivo mobile). Se stai offrendo JavaScript vulnerabile a Internet, allora sei vulnerabile, punto.

Affrontare la parte della domanda lato client della tua domanda: l'unico modo per i tuoi utenti legittimi di sapere che stanno ricevendo un payload JavaScript da te e non da qualche altro utente malintenzionato è che abbiano già avuto fiducia in una terza parte che in fidarsi di te. I certificati SSL / TLS firmati da una CA ampiamente affidabile sono la soluzione normale qui, anche se in alcuni casi potrebbe essere necessario altro, ad es. firma del codice pure.

Alcuni client hanno compromesso la loro sicurezza (ad esempio installando estensioni del browser abbozzate da chissà dove) e non puoi mai sconfiggerli completamente, anche se in alcuni casi puoi rilevarli. Né è davvero il tuo posto per sconfiggerli: se un utente ha malware sul proprio dispositivo che è davvero il loro problema e non il tuo - la tua difesa principale contro questo è il primo punto sopra: non fidarti del codice lato client.

Inoltre, tutto quanto sopra presuppone che gli aggressori non abbiano accesso ai tuoi sistemi server. Questo è cruciale: il solo modo in cui il traffico dal mondo esterno dovrebbe essere in grado di raggiungere i tuoi server di produzione è tramite porte che hai esplicitamente aperto a Internet (in questi giorni, porta 80 e 443) e da qualsiasi amministrazione meccanismo che usi (che dovrebbe idealmente essere protetto da un strong meccanismo crittografico, ad esempio l'autenticazione della chiave pubblica SSH, non semplicemente dalle password). I tuoi sistemi lato server dovrebbero essere aggiornati con tutte le patch di sicurezza e idealmente dovrebbero essere controllati da un professionista della sicurezza competente per garantire che non ci siano altre vulnerabilità di cui non sei a conoscenza.

Infine: tutto questo è un processo in corso. La rete di oggi è piena di aggressori drive-by. Dovresti aspettarti che mantenere e proteggere la tua applicazione sia un costo continuo, non solo in termini di denaro ma anche di tempo ed energia.