Share via


Denial of Service (Negazione del servizio)

Si verifica un attacco Denial of Service quando un sistema viene sommerso da una quantità di messaggi tale da non poter essere elaborata o da poter essere elaborata solo molto lentamente.

Eccessivo consumo di memoria

Quando viene letto un documento XML con un numero elevato di nomi locali, spazi dei nomi o prefissi univoci, può verificarsi un problema. Se si utilizza una classe che deriva da XmlReader e si chiama la proprietà LocalName, Prefix o NamespaceUri per ogni elemento, la stringa restituita viene aggiunta a una classe NameTable. Le dimensioni della raccolta contenuta nella classe NameTable non diminuiscono mai, creando una "perdita di memoria" virtuale degli handle di stringa.

Le prevenzioni includono:

  • Derivare dalla classe NameTable e imporre una quota della dimensione massima. Non è possibile impedire l'utilizzo di una classe NameTable o cambiare la classe NameTable quando è completa.

  • Evitare di utilizzare le proprietà citate e impiegare invece il metodo MoveToAttribute con il metodo IsStartElement quando possibile; questi metodi non restituiscono stringhe e non provocano quindi problemi di superamento della capacità della raccolta NameTable.

Il client dannoso invia un numero eccessivo di richieste di licenza al servizio

Se un client dannoso bombarda un servizio con un numero eccessivo di richieste di licenza, può costringere il server a utilizzare troppa memoria.

Prevenzione: utilizzare le proprietà seguenti della classe LocalServiceSecuritySettings:

  • MaxCachedCookies: controlla il numero massimo di classi SecurityContextToken temporali memorizzate nella cache dal server dopo la negoziazione SPNego o SSL.

  • IssuedCookieLifetime: controlla la durata della classe SecurityContextTokens rilasciata dal server in seguito alla negoziazione SPNego o SSL. Il server memorizza nella cache la classe SecurityContextToken per questo periodo di tempo.

  • MaxPendingSessions: controlla il numero massimo di conversazioni protette stabilite nel server, per cui però non sono stati elaborati messaggi dell'applicazione. Questa quota impedisce ai client di stabilire conversazioni protette nel servizio, facendo così in modo che il servizio mantenga lo stato per client, senza mai utilizzare i client.

  • InactivityTimeout: controlla il tempo massimo in cui il servizio mantiene attiva una conversazione protetta senza ricevere un messaggio dell'applicazione dal client per la conversazione. Questa quota impedisce ai client di stabilire conversazioni protette nel servizio, facendo così in modo che il servizio mantenga lo stato per client, senza mai utilizzare i client.

Necessità dell'autenticazione client per WSDualHttpBinding o per le doppie associazioni personalizzate

Per impostazione predefinita, WSDualHttpBinding ha la sicurezza abilitata. È tuttavia possibile che, se l'autenticazione client viene disattivata impostando la proprietà ClientCredentialType su None, un utente malintenzionato provochi un attacco Denial of Service in un terzo servizio. Ciò può verificarsi perché un client dannoso può indicare al servizio di inviare un flusso di messaggi a un terzo servizio.

Per prevenire il problema, non impostare la proprietà su None. Occorre essere consapevoli di questa possibilità quando si crea un'associazione personalizzata con un modello di messaggio doppio.

Possibilità di riempimento del registro eventi di controllo

Se un utente malintenzionato comprende che è attivato il controllo, può inviare messaggi non validi che causano la scrittura di voci di controllo. Ciò comporta a sua volta la generazione di errori nel sistema di controllo.

Per evitare questo problema, impostare la proprietà SuppressAuditFailure su true e utilizzare le proprietà del Visualizzatore eventi per controllare il comportamento di controllo. Per ulteriori informazioni su utilizzo del Visualizzatore eventi per visualizzare e gestire i registri eventi, vedere Visualizzatore eventi. Per ulteriori informazioni, vedere Controllo degli eventi di sicurezza.

Possibili blocchi del servizio causati da implementazioni non valide di IAuthorizationPolicy

La chiamata del metodo Evaluate su un'implementazione non valida dell'interfaccia IAuthorizationPolicy può causare il blocco del servizio.

Prevenzione: utilizzare solo codice attendibile. In altre parole, utilizzare solo codice scritto e verificato o proveniente da un provider attendibile. Non consentire l'aggiunta nel codice di estensioni non attendibili di IAuthorizationPolicy senza la dovuta considerazione. Questo vale per tutte le estensioni utilizzate in un'implementazione del servizio. WCF non fa distinzioni tra codice dell'applicazione e codice esterno aggiunto utilizzando punti di estensibilità.

Possibile necessità di ridimensionamento per la dimensione massima dei token Kerberos

Se un client appartiene a un gran numero di gruppi (circa 900, anche se il numero effettivo varia a seconda dei gruppi), può verificarsi un problema quando il blocco dell'intestazione di un messaggio supera i 64 kilobyte. In questo caso, è possibile aumentare la dimensione massima dei token Kerberos, come descritto nell'articolo del Supporto tecnico Microsoft sul malfunzionamento dell'autenticazione Kerberos di Internet Explorer dovuto alla connessione insufficiente del buffer a IIS" (la pagina potrebbe essere in inglese). Può inoltre essere necessario aumentare la dimensione massima dei messaggi WCF per adattarla al più ampio token Kerberos.

Generazione da parte della registrazione automatica di più certificati per computer con lo stesso nome di soggetto

La registrazione automatica è la funzionalità di Windows Server 2003 per registrare automaticamente certificati per utenti e computer. Quando un computer si trova in un dominio con questa funzionalità attivata, viene automaticamente creato un certificato X.509 con l'obiettivo di eseguire l'autenticazione client, tale certificato viene quindi inserito nell'archivio dei certificati personali del computer locale ogni qualvolta un nuovo computer viene associato alla rete. Tuttavia, la registrazione automatica utilizza lo stesso nome di soggetto per tutti i certificati creati nella cache.

Può quindi accadere che l'apertura dei servizi WCF abbia esito negativo nei domini con la registrazione automatica. Ciò si verifica perché i criteri predefiniti per la ricerca delle credenziali X.509 del servizio potrebbero essere ambigui, dal momento che esistono più certificati con il nome DNS (Domain Name System) completo del computer. Un certificato ha origine dalla registrazione automatica, l'altro potrebbe invece essere un certificato autorilasciato.

Per prevenire il problema, fare riferimento al certificato esatto da utilizzare specificando un criterio di ricerca più preciso nell'serviceCredentials element. Utilizzare, ad esempio, l'opzione FindByThumbprint e specificare il certificato in base all'identificazione personale univoca (hash).

Per ulteriori informazioni su funzionalità di certificazione automatica, vedere la pagina sulla registrazione automatica dei certificati in Windows Server 2003 (la pagina potrebbe essere in inglese).

Utilizzo per l'autorizzazione dell'ultimo dei diversi nomi di soggetto alternativi

Nel raro caso che un certificato X.509 contenga più nomi di soggetto alternativi e si esegua l'autorizzazione utilizzando il nome di soggetto alternativo, l'autorizzazione potrebbe avere esito negativo.

Protezione dei file di configurazione con elenchi di controllo di accesso (ACL)

È possibile specificare attestazioni obbligatorie e facoltative nel codice e nei file di configurazione per i token rilasciati da CardSpace. Ciò comporta l'emissione di elementi corrispondenti nei messaggi RequestSecurityToken inviati al servizio token di sicurezza. L'autore di un attacco può modificare il codice o la configurazione per rimuovere attestazioni obbligatorie o facoltative, facendo in modo che il servizio token di sicurezza rilasci un token che non consente l'accesso al servizio di destinazione.

Per prevenire il problema: richiedere l'accesso al computer per modificare il file di configurazione. Utilizzare elenchi di controllo di accesso (ACL) per proteggere i file di configurazione. WCF richiede che il codice si trovi nella directory dell'applicazione o nella Global Assembly Cache prima di consentirne il caricamento dalla configurazione. Utilizzare elenchi di controllo di accesso alle directory per proteggere le directory.

Raggiunto il numero massimo di sessioni protette per un servizio

Quando un client viene correttamente autenticato da un servizio e viene stabilita una sessione protetta con il servizio, il servizio tiene traccia della sessione fino a quando il client non la annulla o la sessione non scade. Ogni sessione stabilita viene conteggiata a fronte del numero massimo consentito di sessioni attive simultanee con un servizio. Quando viene raggiunto questo limite, i client che tentano di creare una nuova sessione con il servizio in questione vengono rifiutati fino a quando una o più sessioni attive non scadono o non vengono annullate da un client. Un client può avere più sessioni con un servizio e ognuna di esse viene conteggiata per il raggiungimento del limite.

Aa702790.note(it-it,VS.100).gifNota:
Se si utilizzano sessioni con stato, non vale quanto detto nel paragrafo precedente. Per ulteriori informazioni su sessioni con stato, vedere Procedura: creare un token di contesto di sicurezza per una sessione sicura.

Per prevenire il problema, impostare il limite per il numero massimo di sessioni attive e la durata massima di una sessione impostando la proprietà SecurityBindingElement della classe SecurityBindingElement.

Vedere anche

Concetti

Diffusione di informazioni
Elevazione dei privilegi
Denial of Service (Negazione del servizio)
Attacchi di tipo replay
Manomissioni
Scenari non supportati

Altre risorse

Considerazioni sulla protezione