Interfaccia di amministrazione: Web vs desktop

Non c'è davvero alcuna differenza di sicurezza se sia l'app desktop sia l'app browser sono state create correttamente. Tuttavia, mi piacerebbe decisamente orientarmi verso l'app per browser perché si ottengono diverse funzionalità "gratuitamente" (ad esempio PKI per HTTPS).

Tutte le misure di sicurezza presenti nei browser moderni possono essere integrate in un'app desktop. Il problema è che probabilmente richiederebbero maggiori sforzi di sviluppo e consentire più posti dove possono verificarsi errori.

Divertiamoci ora con i controargomenti:

Desktop is safer since it stops random people from manipulating our data if they don't have the program

LOL! < sarcasmo > Sì, il reverse engineering non esiste e l'oscurità può prevenire l'intercettazione di < / sarcasm >.

Con la quantità di potenza di calcolo che abbiamo oggi la sicurezza attraverso l'oscurità sta diventando sempre meno possibile. Un paio di megabyte di traffico scaricati in un modello statistico possono costruire una specifica di come vengono inviati i dati. E, a meno che non si ripetano mai gli stessi comandi all'interfaccia di amministrazione, non si può uscire da un modello statistico usando solo l'oscurità.

L'unica opzione è la crittografia. Ciò significa che dovrai implementare TLS completo. E per completo intendo TLS (potresti usare openssl per questa parte) e HSTS e un percorso di revoca per certificati compromessi, e un CSP sarebbe altrettanto valido. E tutto questo abbastanza attentamente da non commettere errori. La crittografia non consente lo spazio per errori di codifica.

Rival company is employing this method. Currently they are no.1 in the market

MasterCard utilizza ancora i mainframe per elaborare (alcuni dei suoi) dati Chipcard. E ancora inviare diversi file di clearing in distinti sapori EBCDIC. Tutti useremo i mainframe per i pagamenti?

È ancora possibile commettere errori nell'app Web e peggiorarla rispetto a un'app desktop. Ma c'è molta documentazione sulla protezione delle app Web.

Esistono anche buone strutture per creare app desktop che vengono fornite in bundle con le comunicazioni TLS. L'utilizzo di uno di questi (Python paramiko e Microsoft WIF mi vengono in mente) è un'opzione ma guarda la prossima sezione:

Punto extra

Il tallone d'Achille (in termini di sicurezza) delle app desktop è il loro albero delle dipendenze. Un'app desktop richiederà dozzine di librerie, che potrebbero presentare problemi di sicurezza. Dovrai tenere d'occhio i CVE per tutte le biblioteche. E, se una delle biblioteche risulta non essere molto popolare, non ci saranno molti bughunter a guardarla.

(Questo vale anche per le librerie JavaScript impopolari)

E finalmente arriva l'app desktop updates . Hai trovato che la tua app desktop è vulnerabile a qualcosa e l'ha patchata. Buono! Ma ora è necessario distribuire la nuova versione a tutti coloro che la utilizzano, incluso quel ragazzo che sta lavorando da casa negli ultimi due mesi. OK, puoi mandargli una email con il nuovo programma di installazione. Ma aspetta, non si può manomettere l'e-mail? O anche in un punto più banale, puoi essere sicuro che aggiornerà la sua app?

Un'app Web è molto più semplice da aggiornare.

Dipende da come l'applicazione è costruita, protetta e utilizzata. Un problema tipico dell'amministrazione basata sul Web è che viene utilizzato all'interno dello stesso browser utilizzato anche per navigare su Internet. Ciò rende possibile utilizzare il browser come trampolino per attaccare i sistemi interni dall'esterno.

Tali attacchi di origine incrociata possibili con il browser sono in particolare Cross Site Request Forgery (CSRF) e Cross Site Scripting (XSS) attacca ma anche DNS rebinding . Le interfacce di amministrazione basate sul Web sono spesso protette in modo insufficiente da tali attacchi, il che significa che questi vettori di attacco vengono utilizzati con successo contro router o anche dispositivi industriali .

Le applicazioni desktop da sole non hanno questo tipo di problemi. Ovviamente, se l'applicazione desktop utilizza solo un'interfaccia browser in background e sta utilizzando HTTP (s) per la comunicazione, si potrebbero ottenere gli stessi problemi.

Oltre a ciò che è stato già detto, dovresti considerare come la tua applicazione parlerà con qualsiasi cosa stia gestendo.

Se si tratta di un database e si utilizza un'applicazione desktop semplice, significa esporre il server del database alle connessioni da tutti i potenziali computer client. Ricorda che chiunque può vedere le stringhe di connessione . Dovrai fare affidamento sulle funzionalità di sicurezza del tuo database per l'autenticazione e l'autorizzazione. Questa è una vasta area di superficie da proteggere.

Per un'applicazione web, solo il tuo server web deve sapere come parlare al tuo database. Tutto il resto è nascosto dietro una facciata HTTP e tu hai un grado molto maggiore di controllo su ciò che i tuoi clienti possono fare.

Ovviamente potresti fare entrambe le cose - esporre una specie di web API con cui le tue applicazioni client parleranno. Ma ora hai due applicazioni da mantenere: l'API e il client stesso. A meno che non ti aspetti di avere più utenti della tua API, stai molto meglio semplicemente facendo l'interfaccia utente anche come applicazione web.