Sicurezza per i dati prodotti dal servizio Web ASP.NET

Question

Sicurezza per i dati prodotti dal servizio Web ASP.NET

#1 da (4 voti)
#2 da (1 voti)
#3 da (1 voti)

2

Sto sviluppando un servizio Web ASP.NET 2.0 che serve dati XML da un database. Quasi tutto il traffico dati è a senso unico, da server a client e non ci sono dati specifici dell'utente. Tutti i client riceveranno gli stessi dati. Ma voglio solo che i clienti approvati siano in grado di consumare i dati. In questa situazione, quali sono le migliori opzioni per crittografare i dati prodotti dal servizio web?

Ho esaminato SSL, ma mi è stato detto dalla direzione di trovare un altro modo, in modo da evitare il fastidio di impostare un certificato SSL sul sito o implementare sia SSL che la mia soluzione.
Crittografia SOAP è stato suggerito, ma voglio avere un buon supporto per i client iOS, e non esiste non sembra essere il supporto SOAP integrato nell'SDK di iOS o disponibile open-source.
Poiché nessun dato viene modificato dal lato server e non disponiamo di dati specifici dell'utente o di account utente, non penso che OAuth sia necessario. Diverrà necessario in futuro, ma attraverseremo quel ponte quando ci arriveremo. Ho sbagliato qui?
Ho suggerito di crittografare il contenuto dei dati XML in modo che <Prop1>StringData</Prop1 diventi <Prop1>EncryptedGarbageHere</Prop1> , ma mi è stato detto che non è un approccio sicuro come la crittografia SOAP.

EDIT: In entrambi i casi, sto anche programmando di aggiungere una sorta di parametro "password" richiesto da tutti i WebMethods nel servizio web, e sarà richiesto da ogni applicazione client unica.

security asp.net web-services

posta Mr. Jefferson 02.06.2011 - 00:07

fonte

3 risposte

1

...I only want approved clients to be able to consume the data

Sembra più un problema di autenticazione che un problema di crittografia.

Fornisci ai client autorizzati chiavi di accesso univoche da incorporare nell'URL del servizio web; nessuna chiave, nessun dato.

risposta data 02.06.2011 - 00:42

fonte

1

I only want approved clients to be able to consume the data.

Questo è un problema di autenticazione. Questo significa che vuoi che i tuoi clienti si identifichino con il server, in modo che tu possa utilizzare una sorta di accesso (magari una chiave di licenza con hash invece delle credenziali di nome utente / password) o qualche altro tipo di segreto che solo i client approvati avere, ad esempio una chiave API o un certificato.

La mia raccomandazione è di passare a .NET 4 e utilizzare WCF con una chiave API .

Una chiave API consente di autenticare i client individualmente (o forse solo per numero di versione). Il video nel link fornisce un esempio del perché desideri una chiave API anche se non hai credenziali di accesso.
Con WCF, hai più opzioni per la sicurezza dei messaggi.

risposta data 02.06.2011 - 16:43

fonte

Leggi altre domande sui tag security asp.net web-services

Design della classe e separazione delle preoccupazioni Server Sql: compatto e locale Denali

score 4 · Accepted Answer

In ogni caso vorrai che la sicurezza del livello di trasporto sia SSL. Se non altro per proteggere il tuo login. La gestione è abbastanza sbagliata qui; senza SSL tutto ciò che fai è praticamente inutile a meno che non si riesca a implementare di nuovo SSL. Aggiungerò che è possibile avere certificati SSL validi per $ 50 o meno all'anno.

Per quanto riguarda il problema, dato che sei bloccato su 2.0, le tue opzioni sono limitate. Francamente, la cosa più semplice sarebbe usare un'intestazione SOAP personalizzata per inviare una chiave API. È quindi possibile richiedere ed elaborare la chiave API prima di elaborare la messaggistica.

Tutto ciò detto, se iOS è il tuo cliente chiave, dovresti ripensare alle scelte della tua piattaforma un po '- perché sei bloccato su ASP.NET 2.0 Web Services? Non c'è davvero una buona ragione per rimanere bloccati con strumenti vecchi nel 2011.

EDIT / APPENDICE

Dalle tue modifiche e descrizioni, hai un grosso problema di fondo: mancanza di risorse sottostanti per farlo accadere. I server moderni e SSL sono relativamente economici, a centinaia e non migliaia all'anno.

Superare 2.0 non dovrebbe essere terribilmente difficile - qualsiasi cosa più recente può fare riferimento agli assembly 2.0 che hai a disposizione. Se deve rimanere 2.0, puoi comunque fare alcune cose. Se vuoi utilizzare uno stack completo, dai un'occhiata a OpenRasta . Se il servizio è veramente di sola lettura, puoi facilmente scrivere il tuo servizio utilizzando le implementazioni IHttpHandler personalizzate. La chiave API diventa semplicemente un altro parametro GET in entrambi i casi.