Codifica lato client: come prevenire l'uso dannoso?

Negli ultimi anni, la tendenza per le applicazioni lato client (browser) è davvero decollata.

Per il mio ultimo progetto, ho deciso di provare a muovermi con i tempi e scrivere un'applicazione sul lato client.

Parte di questa applicazione prevede l'invio di e-mail di transazione agli utenti (ad esempio, convalida l'iscrizione, e-mail di reimpostazione della password, ecc.). Sto usando un'API di terze parti per inviare le e-mail.

Normalmente avrei la mia applicazione in esecuzione su un server. Chiamerei l'API di terze parti dal codice sul mio server.

L'esecuzione di un'applicazione sul lato client significa che ora deve avvenire sul browser di un utente. L'API di terze parti fornisce i file JavaScript necessari per raggiungere questo obiettivo.

Il primo problema evidente che posso vedere è che devo usare una chiave API. Questo sarebbe normalmente archiviato in modo sicuro sul mio server, ma ora presumibilmente dovrò fornire questa chiave al browser del client.

Supponendo di poter aggirare questo problema, il problema successivo è ciò che impedisce a un utente esperto di tecnologia di caricare lo strumento di sviluppo JavaScript su un browser e di utilizzare l'API di posta elettronica come preferisce, piuttosto che dire di aderire a tutte le regole che ho impostato nell'applicazione .

Immagino che la mia domanda generale sia: come possiamo impedire l'uso dannoso di un'applicazione sul lato client?

Non puoi, e più persone lo capiscono, e più in profondità capiscono, meglio è per il mondo.

Il codice eseguito su un dispositivo sotto il controllo dell'utente non può essere controllato. Gli smartphone possono essere sottoposti a jailbreak. I set-top box possono essere rotti. I browser ordinari non tentano nemmeno di impedire l'accesso al codice JavaScript. Se hai qualcosa che vale la pena rubare o abusare, un determinato attaccante sarà in grado di farlo a meno che tu non convalidi tutto ciò che ami sul lato server.

L'offuscamento è di scarso aiuto; il tipo di avversario che attirerai non appena viene coinvolto qualcosa di remoto, legge il linguaggio dell'assemblea come gli annunci classificati. La crittografia non può aiutarti, perché il dispositivo che protegge la chiave è lo stesso dispositivo che devi supporre sia rotto. Ci sono molte altre contromisure apparentemente ovvie che non funzionano, per ragioni simili.

Sfortunatamente, questa è una verità molto scomoda. Il mondo è pieno di operatori di piccole e grandi dimensioni che pensano di poter in qualche modo aggirare la fondamentale rottura della fiducia remota, semplicemente perché sarebbe così bello se potessimo presumere che il nostro codice verrà eseguito nel modo in cui abbiamo assunto. E sì, renderebbe tutto molto più semplice da non essere nemmeno divertente. Ma desiderare non lo rende così, e sperare contro la speranza che tu sia l'unico cookie intelligente che può evitare lo spiacevolezza brucerà solo te e i tuoi clienti. Pertanto, entra nella mentalità che Internet è un territorio nemico, includi quel costo aggiuntivo nelle tue stime e andrà tutto bene.

Detto questo, ovviamente esiste una cosa come la difesa in profondità. Offuscare il tuo JavaScript non rimanda un attaccante determinato, ma può rimandare alcuni attaccanti meno determinati. Se i tuoi beni valgono abbastanza da proteggere, ma non a tutti i costi, una qualsiasi di queste misure può aggiungere valore commerciale al tuo sistema; non può essere perfetto. Finché sei pienamente consapevole del trade-off che stai effettuando, questa può essere una strategia ragionevole.

La regola qui è:

Fai tutto sul lato client che non influisce su nessun altro se l'utente lo manomette. In particolare, ciò significa effetti grafici.

Fai tutto sul lato server che deve essere sicuro e invia semplicemente gli eventi UI dal client (es. Quindi il client dice semplicemente "l'utente ha toccato il pulsante Acquista" mentre il server esegue effettivamente la transazione). In particolare, ciò significa transazioni finanziarie.

Questo è esattamente il caso in cui non è appropriato renderlo un'applicazione completamente lato client .

Puoi effettuare la logica e la convalida di base dei moduli lato client (devi ancora riconvalidare sul server, perché qualcuno potrebbe provare a falsificare la richiesta) per migliorare la reattività, puoi fare richieste HTTP da JavaScript passando i dati lì e indietro in JSON a evitare di inviare nuovamente decorazioni di pagine e simili, ma se la transazione stessa deve essere autenticata e autorizzata, dovrebbe comunque avvenire su un server.

Il tuo secondo paragrafo è il cuore del problema:

L'esecuzione di un'app lato client significa che ora deve accadere nel browser di un utente. L'API di terze parti fornisce i file js necessari per raggiungere questo obiettivo.

Perché un'app lato client significa che non puoi avere un lavoro lato server? La spinta verso la programmazione lato client non riguarda l'eliminazione dei server, ma lo sfruttamento delle tecnologie più recenti che i browser supportano finalmente per creare interfacce utente migliori.

Per quanto riguarda il .jsfile che hai ricevuto, sei sicuro che sia pensato per un browser? Potrebbe essere una libreria node.js?

Facciamo un passo indietro e diamo uno sguardo di livello superiore ... dovremmo ... Eudora o Outlook (un'app lato client, che non ha nemmeno bisogno di un browser) hanno mai causato una perdita finanziaria per qualsiasi azienda? No. Chiunque può scrivere nelle API POP / SMTP ed essere il client. Ma nessuna perdita per il server. Il server non ha limitato le azioni del client, i calcoli, l'archiviazione, la temperatura, la dimensione del disco, la dimensione della RAM, il monitoraggio DPI, GPU, FPU yada yada del client, ma ha specificato esattamente a cosa avrebbe risposto e non di più. Hai mai sentito parlare di quicken o MS-Money usato per andare in banca?

L'app del tuo browser (cioè lato client) può utilizzare la stessa architettura.

1. Costruisci il tuo server con un'API (che BTW, si riduce sempre a derivati ​​di GET POST HEAD ecc.).
2. Sul server, assicurarsi che l'API dialoghi solo con un client autenticato e verificato dall'identità per ogni chiamata.
3. Quindi non ti importa chi sia il cliente.
4. E poi non ti importa se si tratta di un browser, di un dispositivo jailbreak, di Google Glass, di DOS 3.1 o di un Nexus nuovo di zecca nelle mani di un bis-bis-bis-bis-nonno tecnophobe che ha viaggiato nel 2014 e ha perso tutto la tecnologia che ha inondato le nostre vite negli ultimi 15 decenni.
5. Ora puoi iniziare a scaricare tutto il resto sul lato client.

SoapBoxBegin

@KilianFoth solleva un importante punto di sensibilizzazione per gli ingenui e gli sconsiderati, principalmente quelli che leggono sempre i titoli dei giornali, ma non pensano mai che accadrà alla loro app, al loro codice, al loro datore di lavoro, al loro cliente, al proprio conto bancario. Ancora più spericolati sono i loro datori di lavoro (in particolare i CTO) che consentirebbero alle app di uscire che espongono qualsiasi sistema a esposizioni non gestite / incontrollate. Tuttavia sono sempre perplesso su come sembra "non impariamo mai".

SoapBoxEnd

Quindi per riassumere. Crea un'API lato server solida e compatta. Scarica tutto il resto sul client in base a ciò che il client è in grado di gestire.

Direi che non puoi davvero. Se sei disposto a inviare i dati al cliente, devi aspettarti che vengano abusati, per quanto possibile. Il tuo esempio per quanto riguarda la chiave API è illustrativo del punto e non includerei questo nel tuo client JS: verrà rubato e abusato.

Avrai sicuramente bisogno di una certa quantità di codice server per mantenere le cose al sicuro. Anche qualcosa di semplice come recuperare solo i dati relativi all'utente che ha effettuato l'accesso. Che l'autenticazione non possa essere eseguita sul lato client o di nuovo sarai sfruttato e i tuoi dati non sono al sicuro.

Vorrei sempre vedere l'esperienza lato client JS come un'aggiunta al codice del server. La convalida sul client offre un'esperienza utente piacevole, ma se non si verificano anche i dati POST sul server ricevente, ci si sta aprendo all'attacco. Qualunque cosa dal cliente dovrebbe essere considerata sospetta.

È abbastanza semplice, davvero. Supponiamo che il computer client e tutto il software in esecuzione su di esso sia sotto il completo controllo di un abile hacker malintenzionato.

Ciò significa che tutte le informazioni che invii dal server al client saranno note all'hacker dannoso, quindi devi assicurarti di non inviare al client alcuna informazione che possa essere utilizzata per attaccare il tuo server o la tua attività.

Significa anche che tutto ciò che è stato inviato dal client al server è stato prodotto dall'hacker dannoso, quindi il codice del tuo server deve assicurarsi che nulla che il client possa inviare sia in grado di attaccare con successo il tuo server.

Certo, l'implementazione è un problema, ma l'importante è l'atteggiamento mentale, il presupposto che il "client" con cui pensi che il tuo server stia parlando non è un client ma un attaccante attivo.

(Devi anche supporre che l'utente sia un truffatore intelligente che proverà ad attaccare i tuoi metodi di business, ma ciò non ha nulla a che fare con la programmazione lato client).

A mio avviso, l'applicazione sul lato client riguarda principalmente l'interfaccia utente. Ad esempio, tutto il tuo sistema di interfaccia utente verrà inviato una volta al client, quindi il client farebbe tutto ciò che vuole con esso.

Normalmente avrei la mia applicazione in esecuzione su un server. Chiamerei l'API di terze parti dal codice sul mio server.

L'esecuzione di un'applicazione sul lato client significa che ora deve avvenire sul browser di un utente. L'API di terze parti fornisce i file JavaScript necessari per raggiungere questo obiettivo.

Se hai una chiave API, non è pensata per funzionare sul lato client. Se si fornisce la chiave API sul lato client, chiunque può accedervi e può quindi utilizzarla per i propri scopi. Conservalo e usalo sul lato server quando il client ne ha bisogno, quindi invia il risultato usando Ajax / WebSocket.

È come se la tua banca stesse dicendo: "Bene, ho intenzione di mettere la password del lato client del database principale in modo che il client possa richiederlo da solo e non disturberà più i nostri server".