Alla ricerca di indicazioni generali sulla protezione dell'applicazione Web API per applicazioni e utenti client

2

Ho un servizio web creato con WebAPI che accetta richieste JSON e risponde di conseguenza. L'architettura principale è costruita ma non c'è alcuna autenticazione / autorizzazione.

Dopo molte ricerche su google e sondaggi su progetti di esempio, non sono sicuro da dove cominciare. Ho trovato un sacco di materiale dal 2008 e dal 2009 ma non un sacco di guide / flussi di lavoro recenti per applicazioni WebAPI / singola pagina. Penso che il flusso di lavoro dovrebbe essere il seguente:

  1. Verifica se l'utente è connesso: come può essere fatto con javascript? Devo inviare un cookie al mio webAPI? In tal caso, posso inviare quel cookie come parametro nel corpo della richiesta?

  2. Consenti all'utente di accedere / registrarsi: come vengono crittografati / decodificati questi dati? Sicuramente non posso inviare password sul filo ... è qui che entra in gioco SSL?

  3. Fornire loro l'accesso a ciò a cui hanno diritto di accesso: penso di averlo ottenuto - posso solo autorizzarlo nei controllori in base alle richieste.

Qualsiasi informazione sarebbe fantastica.

    
posta RobVious 04.04.2013 - 15:52
fonte

2 risposte

2

Il modo più semplice è utilizzare una connessione SSL, chiedere loro di fornire le credenziali di autenticazione e quindi restituire un token di sessione da utilizzare con le richieste future per quella sessione. Puoi quindi scadere il token di sessione dopo l'ammontare di tempo desiderato (a quel punto sarebbe necessario che inviino un altro messaggio di autenticazione).

Ovviamente, supponiamo che non ci sia una gestione delle sessioni integrata in WebAPI. È un po 'prima del mio tempo, quindi non sono così familiare. Per lo più ho finito con l'utilizzo di servizi basati su WCF in cui vi è molto da fare in termini di gestione delle sessioni.

    
risposta data 04.04.2013 - 16:11
fonte
2
  1. I cookie sono usati per mantenere sessioni, ma hanno molti pericoli in agguato. Assicurati che i dati siano passati indietro e amp; avanti è ben criptato, il valore TTL non è troppo lungo e usa metodi noti per funzionare (meglio non reinventare la ruota) link delinea come .net gestisce le sessioni.

  2. Login / registrazione (o qualsiasi dato sensibile) HA BISOGNO di essere criptato via cavo. Sniffare non è così difficile e se sei preoccupato per la sicurezza, questo è IL primo passo.

  3. I diritti di accesso sono buoni per bloccare all'interno dell'applicazione web. Tuttavia, dovresti anche bloccare il server web, il box su cui è in esecuzione, eventuali porte aperte, ecc. Il link è una buona lettura e un punto di partenza per comprendere e implementare la sicurezza delle applicazioni Web.

risposta data 04.04.2013 - 17:41
fonte