C'è un modo per impedire a qualcuno di creare la propria app client per il mio webservice? [duplicare]

Questo sarebbe impossibile. È fondamentale che la tua app contenga tutte le istruzioni necessarie per utilizzare la tua API. Chiunque abbia abbastanza abilità e tempo sarà in grado di estrarre questi segreti e creare il proprio cliente.

È abbastanza semplice e diretto creare il proprio client indipendentemente dal fatto che REST o SOAP siano utilizzati, purché il Cliente esistente sia disponibile per tutti nel Play Store. Catturare il traffico HTTP da un dispositivo Android utilizzando Fiddler e progettare il proprio client in base al traffico catturato.

Anche il traffico HTTPS può essere facilmente decrittografato usando Fiddler . I metodi HTTP, gli URL, le intestazioni, i cookie, il corpo e la tua chiave sono tutti visibili. Non penso che questo sia sicuro. (Ci sono altri proxy inversi là fuori che possono fare lo stesso di Fiddler.)

Dal punto di vista della sicurezza, no, non c'è modo di farlo. Indipendentemente dal grado di offuscamento che hai inserito nel codice e nei protocolli, il fatto che il codice per accedere all'API e il traffico di rete prodotto quando l'accesso all'API è nelle mani dei tuoi utenti, possono utilizzare qualsiasi strumento di reverse engineering loro vogliono su di esso.

Dal punto di vista del business, è necessario valutare il costo per te se qualcuno produce un cliente alternativo contro il costo aggiuntivo per implementare misure per impedire che ciò accada. Ad esempio, è possibile utilizzare interamente un'API proprietaria strongmente offuscata (evitando REST, SOAP e altri protocolli standardizzati) interamente, ma ciò sarà più difficile da implementare e quindi costare di più. D'altra parte, sarebbe molto più difficile per qualcuno fare il reverse engineering. Devi valutare se tali misure (o altre misure appropriate) valgono la pena per la tua attività.

Da un punto di vista legale, molti luoghi hanno termini di servizio che vietano la produzione o l'utilizzo di client di terze parti. Spetta a te far rispettare ciò monitorando il traffico verso il tuo server per determinare se è probabile che si stia utilizzando un client di terze parti o guardando l'aspetto di client di terze parti negli store di app. Dipende anche da te decidere se hai le risorse per intraprendere un'azione legale, e se vale la pena che tu intraprenda tale azione.

Dal punto di vista delle relazioni con gli utenti, potresti voler riconsiderare l'idea di vietare a tutti i client di terze parti una regola generale. Ovviamente nessuno vuole che uno sviluppatore produca un cliente orribile con la propria pubblicità, ma molti servizi in questi giorni consentono agli sviluppatori di terze parti di registrare le loro applicazioni e ricevere una chiave API. Il processo di registrazione può essere semplice o complesso come si desidera, che va da un semplice termini di utilizzo (ad esempio "non inserire le proprie inserzioni nell'app") a una valutazione della loro interfaccia o ad un esame completo della loro fonte codice (ovviamente, più è semplice, più gli sviluppatori saranno disposti a registrarsi). Consentire agli sviluppatori di terze parti di utilizzare la tua API non è necessariamente una cosa negativa: potrebbe voler produrre un'app che utilizza il tuo servizio come un'origine dati ma non è correlata in alcun modo, e in tal caso potrebbero in realtà ti portano più affari se mettono l'accreditamento appropriato nella loro app, o potrebbero voler riempire un mercato che la tua azienda non ha intenzione di entrare, o potrebbero davvero avere un'idea migliore per un'app client per il tuo servizio, che è qualcosa da cui puoi imparare per migliorare la tua app.

Non è possibile rendere impossibile l'accesso non autorizzato all'API in senso di sicurezza, ma è possibile ridurlo al minimo. Non è davvero una domanda di sicurezza, ma il concetto del modello di minaccia è piuttosto appropriato: chi vuoi impedire l'accesso alla tua API e che tipo di danno vuoi evitare?

Molti siti Web di grandi dimensioni proibiscono mezzi alternativi di accesso al loro servizio, di solito in modo che possano continuare a pubblicare annunci. Lo fanno attraverso una combinazione di misure a molti livelli:

• verifica le intestazioni delle richieste e il programma utente (che blocca un gran numero di utenti normali occasionali)
• complicare l'API aggiungendo lo stato dinamico, l'offuscamento e altre misure (che fermano il reverse-engineering casuale, ma non il determinato)
• che lo vietano nei loro Termini di servizio (che blocca altre attività legittime e alcuni individui coscienziosi)
• applicare il ToS attraverso il giuramento (che potrebbe essere necessario contro le imprese non etiche, ma farà più male che bene se schierato contro i piccoli utenti individuali).

Nessuno di questi è efficace al 100%, ma non è necessario che lo sia. L'importante è che riducano la perdita. Pensa a ciò che vuoi realizzare e scegli le contromisure di conseguenza.

Say I have a RESTful web service and a commercial Android app on the front end which is used to interact with it. I may use SSL so that the endpoints are not visible, but someone could still do some reverse engineering to find them.

SSL non nasconde l'indirizzo IP di destinazione, quindi non hanno nemmeno bisogno di decodificare nulla. Tutto il resto può essere ottenuto tramite il certificato Fiddler + MITM.

I could also use SOAP instead, so that the call to the web service is a bit more complicated. But, I still don't know if this gives me any real advantage over RESTful based service.

Bene, più sforzi esegui, più lo sforzo che un hacker dovrà effettuare, suppongo.

Detto questo, gli hacker hanno molto più tempo libero di te, e ce ne sono molti, e solo uno di loro deve pubblicare la soluzione su una bacheca elettronica ed è game over.

Quindi, probabilmente non ne vale la pena.

I was thinking about hardcoding the key into my client app, so that only my client app could use the service. Also, maybe some code obfuscation may help. But, how much does this really help?

Gli hacker ora hanno strumenti di deobfuscation a portata di mano, quindi non sono d'aiuto come prima.

Probabilmente non ne vale la pena.

Fiddler could be used to decrypt https and see the full request. However, if I use Android app only, this may be solved by hardcoding server certificate in Android client app. And also, there is SOAP WS-Security, but I guess a tool can be made to function in similar way as fidler to circumvent that.

L'hacker potrebbe decodificare tutto molto più rapidamente di quanto potresti crearlo.

Quindi, probabilmente non ne vale la pena.

You can't stop a hacker from reverse engineering any code that runs on the client. So whatever safeguards you put in, the hacker can imitate them.

Esattamente. Non perdere tempo su questo.

Invece, prova a progettare la tua applicazione in modo che le funzionalità sensibili siano eseguite sul server, dove puoi proteggerlo.

Passa il resto del tuo tempo a migliorare le funzionalità della tua app in modo che i clienti non vogliano nient'altro.

Vuoi:

prevent someone from making his own client app for my webservice

Vuoi che il tuo webservice identifichi la tua app sui dispositivi dell'utente prima di ulteriori interazioni, questo sembra impossibile in quanto non hai alcuna garanzia sull'integrità dell'app che potrebbe essere modificata con il reverse engineering.

Potresti prendere in considerazione la possibilità di rivedere l'architettura della tua soluzione.

Sì, questo può essere fatto, anche se ovviamente non esiste una soluzione perfetta.

Dovresti aggiungere la crittografia e l'autenticazione dei messaggi sia al client che al server. Entrambi negoziano una chiave di sessione basata su un segreto condiviso, eventualmente con l'aggiunta di un ID cliente univoco. C'è abbondanza di documentazione su come farlo (parole chiave: chiave di sessione, scambio di chiavi, chiave API). La chiave di questo sistema è che la comunicazione è crittografata e firmata con le chiavi di sessione, non con la chiave effettiva (ovvero il segreto condiviso). In questo modo, la vera chiave non viaggia mai sul filo e non può essere intercettata.

Un utente malintenzionato potrebbe ancora decodificare il client per estrarre il segreto condiviso e il meccanismo per derivarne la chiave di sessione. Ma questo richiede competenze più elevate quindi semplicemente ascoltando alcune chatter REST.

L'unico motivo per cui è possibile impedire l'utilizzo indesiderato è eseguire una qualche forma di autenticazione dell'utente. Come richiedere all'utente della tua app di fornire un nome utente e una password ogni volta che avviano l'app e passano al server. Se il server convalida l'utente, restituisce un token di sessione che deve essere utilizzato in tutte le successive chiamate API. Tuttavia, potrebbe essere che la tua applicazione non sia adatta a far accedere gli utenti.

Senza il login sarà sempre possibile per qualcuno che ha accesso alla tua API perché può decodificare il codice e / o spiare i dati per passare avanti e indietro. Quindi il tuo obiettivo è quello di rendere il più difficile possibile per qualcuno di decodificare il codice e le API. Assicurati di non fornire un valore fisso dal client al server. È semplice da trovare e quindi utilizzare in client alternativi.

Invece, vuoi generare un nuovo codice ogni volta che accedi al tuo server in modo che ogni volta che qualcuno spii il traffico vedano un valore diverso e non possano semplicemente riprodurre quel valore. Ciò li costringe a decodificare il codice per scoprire l'algoritmo utilizzato per generare la chiave. Fare uno sforzo per rendere quel codice difficile da comprendere e quindi replicarlo.