Cosa deve sapere un programmatore prima dell'audit client del servizio web

7

Situazione: ho creato un client WS (.net wcf) per il cliente che accede a un servizio Web di terzi (Websphere). Questo WS utilizza HTTPS e ottengo un certificato dal fornitore WS. Funziona tutto bene, ho consegnato il client WS al cliente, il cliente ha ordinato il suo certificato ... ma all'improvviso ho ricevuto la posta dal controllore della sicurezza del cliente, dove mi chiedeva cose che non capisco perché sia interessante. Quindi mi cedo impreparato a questa storia.

Se capirò l'obiettivo dell'auditor della sicurezza, capirò cosa vuole veramente. Sta chiedendo su 1) qual è il livello minimo del protocollo che supporta il requisito WS (SSLv2 o SSLv3)? 2) qual è la lunghezza minima della chiave 128 o 256 bit?

Ho sentito parlare di attacchi di rollback SSL, ma questo dovrebbe essere interessante per l'amministratore WS ( terze parti ), non per il controllore della sicurezza della rete client WS ( mio cliente ). Perché l'utente del client WS potrebbe essere interessante in queste cose? Ci possono essere impostazioni del firewall che dovrebbe regolare?

    
posta Roman Pokrovskij 24.01.2011 - 11:24
fonte

2 risposte

4

La sicurezza dovrebbe essere garantita su entrambi i lati client e server. Perché in caso di attacco Man In The Middle qualcuno può spingere il cliente a usare cifrari deboli, come nell'attacco di downgrade SSH: link

Non so molto di WCF ma sembra che dal programma sia possibile specificare SSL o TL in ServicePointManager.SecurityProtocol.

Sembra che se l'applicazione utilizza l'API Microsoft Crypto l'unico modo per limitare l'utilizzo di SSL / TLS a determinati algoritmi è quello di apportare modifiche all'intero sistema come descritto in link

E WCF utilizza MS Crypto API: link (se il programma non sta utilizzando un certificato personalizzato validator)

    
risposta data 25.01.2011 - 00:51
fonte
6

Da quello che hai detto, questo sembrerebbe essere un problema di audit comune che verrebbe sollevato da un approccio alla sicurezza basato sulla conformità.

Mi aspetto che il revisore della sicurezza stia cercando di identificare se la nuova implementazione supporta i cypher SSL deboli e quindi aumenta il rischio basato su questo.

Se il tuo cliente ha un requisito PCI / DSS , allora l'audit può sembrare per confermare quanto segue:

PCI DSS Requirements
4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks.

Per ulteriori informazioni, OWASP ha una buona quantità di informazioni su questo e consiglia -

Only Support Strong Cryptographic Ciphers The strength of the encryption used within a TLS session is determined by the encryption cipher negotiated between the server and the browser. In order to ensure that only strong cryptographic ciphers are selected the server must be modified to disable the use of weak ciphers. It is recommended to configure the server to only support strong ciphers and to use sufficiently large key sizes.

    
risposta data 24.01.2011 - 13:12
fonte

Leggi altre domande sui tag