Crittografia della risposta dell'API in un'applicazione singola

Come ho capito bene, hai un sito web che serve alcuni dati e vuoi semplicemente impedire agli utenti di raccoglierlo.

L'ultima volta che ho affrontato questo problema nel modo seguente:

1. Raccogli il registro delle operazioni nel database che è utile per la memorizzazione dei registri. Qualcosa in scala orizzontale. Raccogli quante più informazioni possibili, quindi nessun log HTTP tipico ma il registro dettagliato, idealmente in modo strutturato.
2. Analizza i log e prova ad isolare gli utenti che abusano del servizio
3. Blocca utenti che abusano del servizio

Questo è un metodo abbastanza difficile ma molto efficace, e ci sono anche altri modi che possono essere usati con esso, vedi sotto.

Fondamentalmente si prendono questi registri e si tenta di "comprimerlo" nel modo in cui si produce una sorta di rapporto con riepiloghi. Tale rapporto contiene richieste all'ora durante ad es. Mercoledì, varietà dei dati richiesti, durata della sua attività, ad es. dalle 9:00 alle 17:00 e così via. La segheria produce rapporti simili, quindi è bene darci un'occhiata. Più dati hai meno falsi positivi e un miglior rilevamento avrai. L'aspetto principale è che viene eseguito periodicamente, quindi ad esempio si potrebbero elaborare registri nel modo in cui si generano i risultati ogni giorno e li si archivia nel database come report generati per utente al giorno, e quindi è possibile produrre settimanalmente, rapporti mensili e annuali e in questo modo puoi dire con precisione chi sta abusando di esso.

L'idea migliore di limitazione della velocità penso che sia solo per limitare il numero di richieste al minuto / ora / giorno. Questo può essere fatto usando un altro database come Redis per esempio. Se il limite viene superato, è sufficiente restituire l'errore pertinente. Pensa come "metriche in tempo reale". Se superi la soglia di alcune richieste totali per periodo, sei semplicemente bloccato.

Un'altra idea è usare gli inviti. Come ha fatto Google Mail in passato. In questo modo è più facile rintracciare utenti malintenzionati.

Un'altra cosa sarebbe concentrarsi sulla sicurezza dell'account. Per assicurarti che gli utenti siano reali (come conferma del numero di telefono come su Facebook o CC) e che gli account non siano condivisi, ad es. usato da due persone contemporaneamente.

Per quanto riguarda l'offuscamento dei dati, è un buon approccio in quanto limita effettivamente il numero di attori malintenzionati. Uno dei modi per farlo è cambiare frequentemente gli algoritmi o persino farli codificare in anticipo e cambiarli automaticamente ogni mese. Il modo in cui non può essere automatizzato. Tuttavia, tieni presente che esistono strumenti come PhantomJS che possono funzionare come normali browser e fare comunque quella roba. Quindi forse alcuni Captcha potrebbero essere necessari anche quando raggiungi determinati limiti.

È inoltre possibile modificare il formato del database di volta in volta, ad esempio le risposte json.

Per quanto riguarda gli utenti, potresti aver bisogno di accedere tramite l'account Google per esempio in modo che sia più facile che controllarli da soli, in modo simile a Facebook.

E non dimenticare di includere l'EULA. E in T & C scrivi chiaramente cosa è permesso e cosa no.

La tua API dovrebbe controllare per vedere chi sta effettuando la chiamata ed eseguire qualsiasi tipo di restrizioni sul lato server.

Il modo in cui affrontarlo consiste nell'implementare autorizzazione sul lato server e mitigare riferimento dell'oggetto sicuro e controllo di accesso a livello di funzione . Questi dovrebbero essere comunque standard.

Se la tua API restituisce informazioni che non vuoi che il chiamante sia in grado di vedere, hai implementato l'API errata. Non c'è nulla che tu possa fare per proteggere i dati a quel punto in quanto l'utente può semplicemente monitorare il traffico di rete usando qualcosa come la console di Chrome. Anche se lo si cripta, il codice per decodificarlo risiede nel browser dell'utente finale e può essere decodificato. Suppongo che potresti ritirare la chiave da tutti tranne gli utenti autorizzati, ma che senso ha usare la larghezza di banda restituendo dati che non possono essere letti? Invece di crittografarlo, puoi anche ridurlo, ad es. sostituirlo con parole completamente casuali o sostituirlo con stringhe vuote. Fallo lato server.

Un browser Web non è una piattaforma DRM, punto e basta.

Lo stato dell'arte in questa area generale sono le tecniche di distribuzione del malware e l'offuscamento di javascript. Google è la migliore fonte per le ultime notizie, questo spazio cambia rapidamente.

Rispetto allo stato dell'arte, le tecniche menzionate nella domanda non distoglierebbero un esperto analista interessato a recuperare sistematicamente i dati resi disponibili per più di un paio di giorni al massimo. Passare attraverso il codice lato client con un debugger rivela i segreti desiderati molto rapidamente.