Evitare la rappresentazione del client con Rest Api

2

Sono certo che questo caso d'uso abbia una soluzione conosciuta, ma non riesco a trovare nulla su google o non so quali parole chiave usare. Stiamo costruendo un'app Angolare supportata da un'API di riposo. Per Autorizzazione utilizziamo OAUTH 2 e memorizziamo il token in un cookie solo HTTP e utilizziamo anche la protezione XSRF ( Cross Protezione dei falsi della richiesta del sito )

Abbiamo anche ricevuto una richiesta per creare un'app mobile. Non ho trovato alcun materiale chiaro su come esporre REST Api all'app mobile, senza creare la possibilità che un hacker possa creare un client falso in grado di impersonare il nostro servizio e ingannare gli utenti ad accedere utilizzando il client falso.

Aggiorna

Lascia che ti spieghi di più. Assumiamo il seguente scenario.

L'API è ospitata su api.com . L'api ha due endpoint

  • / Token - > questo endpoint genererà un token JWT, se le credenziali passate con POST sono valide

  • / GetData - > questo è un endpoint, che sarà accessibile da un utente autorizzato.

l'app a pagina singola è ospitata su spa.com .

La nostra architettura di sicurezza si basa su questo articolo . L'idea principale è che non è sicuro memorizzare i token jwt nella directory locale e dovremmo sfruttare i cookie per questo. L'API imposterà due cookie dopo una richiesta di successo a / Login

  • Un cookie solo http, che contiene il token jwt. Questo cookie verrà inoltrato nella seguente richiesta solo al dominio dell'API.
    • Un token XSRF. Questo è un token casuale che non è solo http, ma impostato sul dominio spa.com. Questo cookie è accessibile solo da javascript in esecuzione su spa.com. Questa è una protezione contro XSRF, perché ogni richiesta, che viene inviata dalla SPA, conterrà questo token nell'intestazione della richiesta.

Non sono un esperto di sicurezza, ma basato sulla lettura di materiali da stormpath e altri, penso che questa sia un'architettura di sicurezza decente per l'app web.

Secondo scenario, app per dispositivi mobili.

Come ho già detto, l'API controlla due token per autorizzare un utente. Immaginiamo, c'è un terzo endpoint su api.com:

  • / TokenMobile - > questo endpoint riceverà le credenziali inviate da un'app mobile.

Come tutti sappiamo, le app mobili non sono sicure. Possono essere decompilati. SSL può essere eluso. Un hacker, con abbastanza tempo e conoscenza, potrebbe capire come sto facendo tutte le mie richieste e come autorizzo un utente. Questo hacker potrebbe creare un sito web improvvisato simile alla nostra app e utilizzare gli endpoint mobili per accedere all'utente. Certo, questo può essere possibile con un po 'di ingegneria sociale.

Quindi le mie domande: Mi sto perdendo qualcosa? Posso proteggere i miei utenti dalla rappresentazione del servizio? Sono paranoico? Questo caso d'uso è davvero un problema di sicurezza?

    
posta Alex Maie 15.01.2016 - 15:04
fonte

0 risposte

Leggi altre domande sui tag