Come ci si assicura che un'applicazione client .net non sia stata compromessa per aggirare le richieste di autorizzazione?

Question

Come ci si assicura che un'applicazione client .net non sia stata compromessa per aggirare le richieste di autorizzazione?

#1 da (2 voti)
#2 da (1 voti)

1

Abbiamo scritto una semplice applicazione desktop .NET (C #) in Wpf. Abbiamo anche utilizzato WIF (Windows Identity Framework) per ottenere un elenco di attestazioni per l'utente autenticato. Alcuni esempi sono:

CanOverrideSalesAmount
CanAddContact
ecc.

Funziona bene e tutto, il client sembra molto protetto. Ma, quando stavo eseguendo il debug dell'applicazione mi è venuto in mente che tutta l'autorizzazione sta avvenendo dal lato client. Una persona subdola potrebbe utilizzare uno strumento come Snoop per collegarsi all'applicazione e apportare modifiche al modello di dominio che non dovrebbe fare.

Abbiamo pensato di spostare i controlli di autorizzazione sui setter di proprietà, ma anche questo non è abbastanza buono perché quando serializziamo il grafico dell'oggetto per inviare il filo, i dati serializzati possono essere modificati (molto estrapolati, ma ancora possibili) .

Mi sembra che l'unico vero modo per proteggere il mio grafo di oggetti sia di farlo risiedere sul server e fare in modo che il client effettui chiamate per aggiornarlo, ma sembra un tale eccessivo. C'è un modo migliore per gestire questa situazione? Voglio che la nostra applicazione sia il più sicura possibile.

c# security client-server authorization code-security

posta michael 10.09.2014 - 15:09

fonte

2 risposte

Leggi altre domande sui tag c# security client-server authorization code-security

Dove eseguire il controllo di un codebase per l'utilizzo di codice pericoloso [chiuso] La mia conoscenza della licenza per JQuery.xmleditor è corretta?

score 2 · Answer 1

Il problema con i controlli di autorizzazione solo sul lato client è che in definitiva un utente malintenzionato può simulare il comportamento dell'applicazione. Robert Harvey sostiene che è improbabile che i tuoi utenti eseguano il debug dell'applicazione compilata o guardino il traffico di rete. Potrebbe essere molto bello.

Il problema è che non è la scienza missilistica a scoprire cosa sta succedendo. E se qualcuno infrange la sicurezza, non si può mai sapere, perché al server, tutto assomiglia al traffico regolare.

Quindi, la risposta è che potresti provare a proteggere la tua applicazione offuscandola e crittografando il traffico verso il server, ma questo solleva la barra per una violazione riuscita. Le società produttrici di videogiochi e film investono serie energie nello sviluppo di protezione per il software o il contenuto di un dispositivo non affidabile, ma è possibile vedere queste protezioni che vengono eluse abbastanza presto. L'esecuzione della parte relativa alla sicurezza su un computer fidato (come un server) è molto più efficace in termini di sforzo rispetto alla sicurezza.

score 1 · Answer 2

In primo luogo, dovresti firmare l'assembly in modo che gli utenti non possano manometterlo - Microsoft firma e assicura le sue assemblee nel GAC per impedire agli hacker di interferire con esse. Dovresti fare lo stesso.

Questo impedisce a qualcuno di modificare il tuo assembly usando un editor binario, sebbene dovrai anche provvedere a sostituirli completamente. Assicurati di offuscare il tuo assembly per rendere più difficile la decompliatura.

Devi anche proteggere il canale di comunicazione verso il server, oppure chiunque può installare wireshark per ispezionare i pacchetti inviati e quindi replicare la sequenza di autenticazione con le proprie, lievi modifiche. Vedete questo accadere tutto il tempo sui server di gioco ingenuamente scritti, alcune persone acquistano improvvisamente più risorse di gioco perché hanno falsificato i messaggi di rete per dire al server che hanno "pagato" una spinta enorme, onesta. (e tali giochi in stile flash tendono a non essere scritti da persone che hanno familiarità con la sicurezza aziendale).

La sicurezza della rete è abbastanza semplice in questo giorno di comunicazioni SSL.

È anche possibile migliorare le comunicazioni utilizzando un sistema di token sicuro (ad esempio Kerberos o simile - non provare a eseguire il rollover) che viene inviato con ogni messaggio al server per garantire che il messaggio provenga da un utente autenticato correttamente. Ciò impedisce a qualsiasi utente di riprodurre semplicemente i messaggi all'esterno dell'applicazione.

È ancora possibile essere hackerati dopo questo, ma questi passaggi ti rendono ragionevolmente sicuro.