Prevenire il reverse engineering delle applicazioni client

L'offuscamento potrebbe sembrare il primo passo ovvio, ma l'offuscamento deve proteggere qualcosa nel codice e che qualcosa non può essere funzionalità del servizio web perché viene decodificato intercettando il traffico anche se è crittografato con SSL. Il blocco dei certificati può impedire l'intercettazione SSL semplice affidandosi a un certificato predefinito.

Puoi crittografare simmetricamente i dati di comunicazione e memorizzare la chiave nel client quindi utilizzare l'offuscamento per rendere più difficile l'accesso a tale chiave e all'algoritmo di crittografia. E puoi anche proteggere l'offuscamento rendendo più difficile la decompilazione. Un esempio di flash offfuscator e anti-decompilatore è SWFencrypt e BISguard .

I precedenti sono protezioni del codice sorgente statico ma non proteggono da attacchi live / dinamici. Un modo per proteggere da questi attacchi è che il client usi controlli di integrità su memoria e risorse. Ci sono anche alcune tecniche di reverse engineering che possono rendere più difficile il debug live.

L'altro modo per prevenire attacchi dal vivo è utilizzare un software che cerchi eventuali manomissioni del sistema che potrebbero essere utilizzate per la manomissione del software client. Questo è il regno dei motori anti-cheat di rootkit come Punkbuster, Warcraft's Warden e Valve's VAC.

Un diverso tipo di protezione è la firma del codice e la firma della memoria (fino alla pagina di memoria) su piattaforme chiuse come iOS e Android. In questo modo, puoi limitare le modifiche statiche a quelle binarie e dinamiche del client alla sua memoria e al sistema operativo.

Anche il vecchio CAPTCHA può essere utilizzato come protezione contro l'automazione, ma danneggia la facilità d'uso. È inoltre possibile rilevare l'automazione sul server, attraverso il comportamento degli utenti e i modelli di utilizzo, quindi accoppiarli con CAPTCHA per ridurre i falsi positivi.

Oltre alle protezioni tecniche, puoi usare con mezzi legali e persino incentivi. Fornisci il miglior cliente in modo che gli utenti non siano inclini a modificare i tuoi oa scrivere i propri. Oppure fai in modo che un cliente personalizzato o hackerato non dia un vantaggio molto maggiore all'hacker. I mezzi legali non sono la mia forza e variano in base al paese, ma ho sentito parlare di azioni legali sul reverse engineering. La minaccia legale potrebbe scoraggiare le aziende e gli individui dalla vendita o dalla fornitura di clienti personalizzati.

Infine, è possibile capovolgere l'intero problema e rendere il servizio web facilmente accessibile tramite API flessibili e proteggerlo dagli abusi sul server. Potresti anche addebitare piccole commissioni per la funzionalità superiore che i tuoi hacker desiderano. :)

Fondamentalmente non puoi proteggere il tuo cliente. Nella migliore delle ipotesi puoi oscurare e offuscare al fine di rendere più difficile per un utente malintenzionato modificare il client.

Hai detto che non si tratta di un problema di sicurezza perché il server è correttamente protetto, ma solo un fastidio. Potrebbe essere più fastidioso cercare di oscurare il tuo cliente piuttosto che lasciare che alcuni client modificati facciano cattive richieste respinte dal server.

Dipende davvero dai tuoi modelli di minaccia. Nella maggior parte dei clienti su cui ho lavorato, non mi sono preoccupato di oscurità o offuscamento, dal momento che il server era completamente protetto e non sarebbe stato ottenuto nulla modificando il client.

Ora, se stiamo parlando di provare a proteggere un client stesso (ad esempio a causa di problemi di IP, non vuoi che qualcuno rubi il client) potrebbe essere più sensato dedicare del tempo a rendere questo difficile da realizzare (mentre ancora Tenendo presente che non sarai mai in grado di proteggere completamente un cliente, nella migliore delle ipotesi puoi causare aggressivi attaccanti a rinunciare e ritardare gli aggressori motivati).

Nessuno. Se non decompilano la tua app, la inseriranno semplicemente attraverso un proxy con il proprio certificato SSL. Il tuo cliente non può fornire sicurezza per il tuo back-end.

what measures would you take to limit the risk of people tampering with your client software?

C'è un equilibrio qui che solo tu puoi misurare. Supponendo che la tua protezione non infastidisca gli utenti validi, devi solo bilanciare il valore, per te, di proteggere il software dal valore per l'utente malintenzionato di rompere la protezione.

Se parli di software o servizio che non è molto costoso e i client non sono il tipo da andare oltre i semplici mezzi, allora l'offuscamento potrebbe essere sufficiente.

Se stai parlando di un servizio o di un software che è molto costoso, o che è altrimenti utile se usato in modo improprio, e i clienti sono determinati a utilizzare il servizio con il proprio software, allora dovrai usare molto di più mezzi rigorosi.

Nel primo caso, gli strumenti esistono già.

nel secondo caso l'opzione migliore è utilizzare Adobe Air, che consente applicazioni firmate che non vengono eseguite nel browser. È possibile verificare utilizzando la crittografia a chiave pubblica che si sta 1) parlando con l'applicazione e 2) che l'applicazione non è stata alterata. È complicato se devi contrastare aggressori molto diligenti (e, onestamente, nulla è assolutamente impenetrabile) ma con un design accurato e frequenti aggiornamenti forzati puoi eliminare la maggior parte degli attacchi semplicemente facendo un sacco di lavoro per attaccare.