Attualmente stiamo progettando un servizio Web che restituisce un messaggio JSON formattato. Di seguito sono riportate le implementazioni pianificate per la sicurezza del servizio:
-
Una certificazione SSL al servizio per la sicurezza delle comunicazioni su Internet.
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communication security over the Internet. The server sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA) and the server's public encryption key. - wikipedia.org
-
Crittografia di dati sensibili utilizzando hash e salt.
Encryption is in Symmetric (Rijndael) Key - Rijndael can be specified with block and key sizes in any multiple of 32 bits, with a minimum of 128 bits. The blocksize has a maximum of 256 bits, but the keysize has no theoretical maximum. - wikipedia.org
-
Autenticazione client utilizzando nome utente e convalida password personalizzati
WCF allows for custom user name and password authentication schemes, also known as validators. - msdn.microsoft.com
Il servizio verrà utilizzato da diversi client e i dati dovrebbero essere protetti. I seguenti sono i possibili rischi [1] :
- Autenticazione e gestione delle sessioni interrotte - Le funzioni dell'applicazione relative all'autenticazione e alla gestione delle sessioni spesso non vengono implementate correttamente, consentendo agli autori di attacchi di compromettere password, chiavi, token di sessione o sfruttare altri difetti di implementazione per assumere le identità degli altri utenti.
- Riferimenti agli oggetti diretti non sicuri : un riferimento ad oggetti diretti si verifica quando uno sviluppatore espone un riferimento a un oggetto di implementazione interno, ad esempio un file, una directory o una chiave di database. Senza un controllo di accesso o altra protezione, gli autori di attacchi possono manipolare questi riferimenti per accedere a dati non autorizzati.
- Configurazione errata della sicurezza : una buona protezione richiede che sia definita e distribuita una configurazione sicura per l'applicazione, i framework, il server delle applicazioni, il server Web, il server di database e la piattaforma. Tutte queste impostazioni devono essere definite, implementate e gestite in quanto non vengono fornite con impostazioni predefinite sicure. Ciò include l'aggiornamento di tutti i software, incluse tutte le librerie di codici utilizzate dall'applicazione.
- Archiviazione crittografica non sicura : molte applicazioni Web non proteggono adeguatamente dati sensibili, come carte di credito, SSN e credenziali di autenticazione, con crittografia o hashing appropriati. Gli aggressori possono rubare o modificare tali dati debolmente protetti per compiere furti d'identità, frodi con carte di credito o altri crimini.
- Protezione livello di trasporto insufficiente : le applicazioni spesso non riescono a autenticare, crittografare e proteggere la riservatezza e l'integrità del traffico di rete sensibile. Quando lo fanno, a volte supportano algoritmi deboli, utilizzano certificati scaduti o non validi o non li usano correttamente.
Se un attacco è riuscito a penetrare nel nostro servizio, una grande perdita cadrà nella nostra azienda. I seguenti sono i possibili risultati di un attacco riuscito:
- Qualsiasi dato manipolato in modo malevolo potrebbe causare una grande perdita nei profitti della nostra azienda.
- L'accesso ai client non autenticati consente loro di modificare e aggiungere dati dannosi e / o di rallentare o interrompere il servizio, rendendo il servizio inaccessibile.
La nostra implementazione pianificata per la sicurezza del servizio è sufficiente per prevenire questi rischi? Quali altri problemi di sicurezza dobbiamo prendere in considerazione?
[1] Il nome e la definizione del rischio si basano su Rischi per la sicurezza delle applicazioni OWASP .