it-swarm-eu.dev

Come posso proteggere il mio REST API?

Nel dettaglio ecco il problema:

Sto creando un'app Android, che consuma la mia REST API sul back-end. Per iniziare, devo creare un'API di registrazione e accesso. Dopo aver cercato con Google per un po ', sento che ci sono solo due approcci che posso adottare.

  • Durante la registrazione, utilizzo https e ottengo le credenziali dell'utente; salvarlo nel mio DB con il nome utente (lato server). Durante l'accesso, utilizzo nuovamente https e chiedo le credenziali dell'utente; verifica la password con hash sul DB e restituiscigli un ID di sessione, che sto pianificando di non scadere mai a meno che non si disconnetta. Ulteriori eventuali altre chiamate API (GET/POST) effettuate dall'utente saranno accompagnate da questo ID sessione in modo che io possa verificare l'utente.

Ma con l'approccio sopra sono costretto a usare https per qualsiasi chiamata API, altrimenti sono vulnerabile a Man in The Middle Attack , ovvero se qualcuno annusa il mio ID di sessione, può ricostruire richieste GET/POST simili che non vorrei. Ho ragione con il presupposto sopra?

  • La seconda opzione è seguire il percorso di Amazon Web Services , dove utilizzo l'autenticazione con chiave pubblica/privata. Quando un utente si registra, utilizzo un'API https per salvare le sue credenziali nel DB. Da quel momento in poi uso la password con hash dell'utente come chiave privata. Qualsiasi ulteriore chiamata API effettuata dall'utente avrà un BLOB con hash dell'URL della richiesta utilizzando la chiave privata dell'utente. Sul lato server ricostruisco l'hash usando la chiave privata salvata. Se l'hash è una corrispondenza lascio che l'utente faccia il suo compito, altrimenti rifiuta. In questa opzione devo usare https solo per l'API di registrazione. Il REST può continuare su http.

Ma qui lo svantaggio è che sono costretto a ospitare la mia API di registrazione in una directory virtuale separata (sto usando IIS e non sono sicuro di poter ospitare sia http che https API nella stessa directory virtuale. Quindi sono costretto a sviluppare l'API di registrazione in un file di progetto separato. Ancora una volta ho ragione con l'assunto di cui sopra?

Modifica: Sto usando ASP.NET MVC4 per creare l'API Web.

Il motivo per cui sono riluttante a usare https per tutti i miei REST Le chiamate API sono che ritengo che non sia leggero e creino più payload di rete, il che potrebbe non essere più adatto per un'app mobile. Ulteriore crittografia/decrittografia e ulteriore stretta di mano necessarie potrebbero influenzare ulteriormente la durata della batteria di un cellulare? O non lo è significativo?

Quale dei due approcci precedenti suggeriresti?

PS: siamo andati con Https ovunque ed è stata la decisione migliore. Più di questo sul mio blog .

84
noob Mama

Andrei con SSL/TLS ovunque (dal momento che controlli entrambe le parti, forzare TLS 1.2 dovrebbe essere fattibile). È relativamente semplice da usare e hai molte funzionalità di sicurezza gratuite. Ad esempio, se non usi SSL, dovrai preoccuparti di ripetere gli attacchi.

Se sei preoccupato per le prestazioni, assicurati che la ripresa della sessione sia supportata sia dal server che dal client. Questo rende le strette di mano successive molto più economiche. Poiché l'handshake è piuttosto costoso in SSL rispetto alla crittografia dei dati effettivi, ciò riduce considerevolmente il carico complessivo.

Se si utilizza HTTP 2, è anche possibile inviare più richieste su una singola connessione, in questo modo si evita l'overhead completo di handshake TCP e SSL nelle richieste successive).

54
CodesInChaos

Consiglio di usare OAuth. Dovresti assolutamente leggerlo se non lo conosci. Inoltre, puoi utilizzare provider di identità di terze parti, in modo che i tuoi utenti possano utilizzare i loro account Google/Windows Live/ecc. Per la tua applicazione, risparmiando la registrazione.

Anche se desideri creare il tuo framework di autenticazione, non ti consiglio di utilizzare sessioni non in scadenza. La sessione dovrebbe scadere dopo un tempo di inattività sufficiente, altrimenti questo dà più spazio allo sfruttamento (dirottamento della sessione, ad esempio).

23

Dipende da quanto deve essere sicuro . Ogni volta che rendi la soluzione più complessa, è anche probabile che lasci un buco. È meglio utilizzare una sorta di modulo di autorizzazione e autenticazione standard del settore.

Probabilmente starai bene, purché tu sia:

  • crittografia della password (con qualcosa come AES o Blowfish)
  • salare la password
  • invio dei dati tramite HTTPS

Un'alternativa è OAuth.

Se qualcuno vuole hackerarti abbastanza male, troverà sempre un modo. Il segreto sta aumentando il tempo e gli sforzi richiesti abbastanza da non valere la pena di qualcuno. Pertanto, se non si dispone di enormi quantità di dati di clienti e/o finanziari e non si è un'azienda di alto profilo, un'implementazione di sicurezza standard come quella sopra dovrebbe andare bene.

4
Dan Blows

Non sarai mai sicuro al 100% che la tua API sia sicura.

Il motivo principale di ciò è che probabilmente stai consegnando un binario ai tuoi clienti/utenti che semplicemente funziona. Quindi hanno tutto il tempo nel mondo per analizzare il binario per cercare chiavi/segreti su di esso, usato per autenticarsi in modo sicuro sul tuo server API. L'endpoint dell'API client è il punto più debole, perché possiede il dispositivo su cui è in esecuzione il tuo binario, quindi può manipolare i certificati che il suo dispositivo considera validi o meno.

Un chiaro esempio di ciò di cui sto parlando è questo articolo ("Un tutorial per il reverse engineering dell'API privata del tuo software: hackerare il tuo divano"). E vorrei finalizzare questa risposta citando uno degli ultimi paragrafi in essa contenuti:

È possibile impedire completamente l'utilizzo di un'API privata da parte di client di terze parti? Io non la penso così. L'uso del pinning SSL impedirebbe di annusare le richieste API usando una semplice tecnica proxy trasparente come descritto in precedenza. Alla fine, anche se offuschi il binario, un hacker motivato con alcune risorse e tempo sarà sempre in grado di decodificare il binario dell'app e ottenere la chiave/certificato privato. Penso che il presupposto che l'endpoint client sia sicuro sia intrinsecamente sbagliato. Un client API è un punto debole.

2
knocte

In JEE abbiamo l'idea di sicurezza gestita dal container. Nel qual caso ho impostato i miei servizi riposanti per utilizzare l'autenticazione di base, che per impostazione predefinita utilizza l'autenticazione della password HTTP rispetto a un realm impostato sul server delle app. Ciò elude la necessità di un modulo HTML per l'accesso o la complessità della distribuzione dei certificati lato client.

L'applicazione presuppone solo che ci sarebbe un principale utente e forse altri dati come i dettagli di identificazione che vengono passati con la richiesta. Ciò include le API restanti.

Nel mio setup, ho implementato un modulo di autenticazione del server OAuth2 JASPIC [ Fonte ] che memorizza il token OAuth che è crittografato simmetricamente dove il la chiave risiede nel server che ha anche una durata limitata nel cookie e lo usa come autenticazione per l'applicazione.

Facendo quanto sopra tengo l'applicazione lontana dalla semantica di autenticazione e come bonus quando voglio eseguire test di integrazione funzionale usando Selenium sono in grado di eseguire il downgrade all'utilizzo delle password HTTP invece di avere un test complesso che si connette a un OAuth provider per tutto il tempo.

Inoltre, userò ancora SSL per assicurarmi che almeno il tuo trasporto sia sicuro. Non utilizzare SSL aggiunge solo troppa complessità nella gestione di attacchi comuni alla tua applicazione.

Ricorda che si tratta di JEE ma i meccanismi possono essere applicati a qualsiasi tecnologia.

2

Solo HTTPS è un must.

Man mano che controlli sia l'app che l'API, implementerei Pinning certificato. Il pinning certificato può essere sconfitto ma è un buon deterrente contro l'ispettore occasionale.

Puoi aggiungere un altro livello con Payload Encryption. Ciò comporta il costo di un solido processo di distribuzione e rotazione delle chiavi.

Se la tua app utilizza token di accesso o cookie di sessione per l'autorizzazione ad API specifiche, assicurati che scadano. Osservo così spesso token al portatore che non scadono per giorni, mesi o per sempre.

Regola d'oro: un O/S mobile è un ambiente ostile. Trattalo con cura e mancanza di fiducia.

1
rustyMagnet

Sento che non è leggero e crea più payload di rete

Ha un certo impatto sulla latenza, quindi se è necessario elaborare i dati in ordine di 10s di millsecondi, potrebbe essere una considerazione. Ma anche nel 2012, l'hardware di base può gestire le spese generali di elaborazione con un impatto trascurabile.

che potrebbe non essere più adatto per un'app mobile

Quindi quanto sopra non è un problema.

0
symcbean