20. Security Considerations (Considerazioni sulla sicurezza)

Questa sezione è fornita per dettagliare le questioni riguardanti le implicazioni sulla sicurezza di cui le applicazioni WebDAV devono essere consapevoli.

Tutte le considerazioni sulla sicurezza di HTTP/1.1 (discusse in [RFC2616]) e XML (discusse in [RFC3023]) si applicano anche a WebDAV. Inoltre, i rischi per la sicurezza inerenti all'authoring remoto richiedono una tecnologia di autenticazione più forte, introducono diverse nuove preoccupazioni sulla privacy e possono aumentare i pericoli derivanti da un design del server inadeguato. Questi problemi sono dettagliati di seguito.

20.1. Authentication of Clients (Autenticazione dei client)

A causa della loro enfasi sull'authoring, i server WebDAV devono utilizzare la tecnologia di autenticazione per proteggere non solo l'accesso a una risorsa di rete, ma anche l'integrità della risorsa. Inoltre, l'introduzione della funzionalità di blocco richiede il supporto per l'autenticazione.

Una password inviata in chiaro su un canale non sicuro è un mezzo inadeguato per proteggere l'accessibilità e l'integrità di una risorsa poiché la password può essere intercettata. Poiché l'autenticazione di base per HTTP/1.1 esegue essenzialmente la trasmissione in testo chiaro di una password, l'autenticazione di base NON DEVE essere utilizzata per autenticare un client WebDAV su un server a meno che la connessione non sia sicura. Inoltre, un server WebDAV NON DEVE inviare una sfida di autenticazione di base in un'intestazione WWW-Authenticate a meno che la connessione non sia sicura. Un esempio di connessione sicura sarebbe una connessione Transport Layer Security (TLS) che impiega una suite di cifratura forte e l'autenticazione del server.

Le applicazioni WebDAV DEVONO supportare lo schema di autenticazione Digest [RFC2617]. Poiché l'autenticazione Digest verifica che entrambe le parti di una comunicazione conoscano un segreto condiviso, una password, senza dover inviare quel segreto in chiaro, l'autenticazione Digest evita i problemi di sicurezza inerenti all'autenticazione di base fornendo al contempo un livello di autenticazione utile in un'ampia gamma di scenari.

20.2. Denial of Service (Negazione del servizio)

Gli attacchi denial-of-service sono di particolare preoccupazione per i server WebDAV. WebDAV più HTTP consente attacchi denial-of-service su ogni parte delle risorse di un sistema.

Lo storage sottostante può essere attaccato effettuando PUT di file estremamente grandi.
Richiedere operazioni ricorsive su grandi collezioni può attaccare il tempo di elaborazione.
Effettuare più richieste pipeline su più connessioni può attaccare le connessioni di rete.

I server WebDAV devono essere consapevoli della possibilità di un attacco denial-of-service a tutti i livelli. La risposta appropriata a un tale attacco PUÒ essere semplicemente interrompere la connessione. Oppure, se il server è in grado di fornire una risposta, il server PUÒ utilizzare una richiesta di stato di livello 400 come 400 (Bad Request) e indicare perché la richiesta è stata rifiutata (una risposta di stato di livello 500 indicherebbe che il problema è con il server, mentre gli attacchi DoS involontari sono qualcosa che il client è in grado di rimediare).

20.3. Security through Obscurity (Sicurezza attraverso l'oscurità)

WebDAV fornisce, attraverso il metodo PROPFIND, un meccanismo per elencare le risorse membro di una collezione. Questo riduce notevolmente l'efficacia delle tecniche di sicurezza o privacy che si basano solo sulla difficoltà di scoprire i nomi delle risorse di rete. Gli utenti dei server WebDAV sono incoraggiati a utilizzare tecniche di controllo degli accessi per prevenire l'accesso indesiderato alle risorse, piuttosto che dipendere dalla relativa oscurità dei loro nomi di risorsa.

20.4. Privacy Issues Connected to Locks (Problemi di privacy connessi ai blocchi)

Quando si invia una richiesta di blocco, un user agent può anche inviare un campo XML 'owner' fornendo informazioni di contatto per la persona che acquisisce il blocco (per quei casi in cui una persona, piuttosto che un robot, sta acquisendo il blocco). Queste informazioni di contatto sono memorizzate in una proprietà DAV:lockdiscovery sulla risorsa e possono essere utilizzate da altri collaboratori per iniziare la negoziazione sull'accesso alla risorsa. Tuttavia, in molti casi, queste informazioni di contatto possono essere molto private e non dovrebbero essere ampiamente diffuse. I server DOVREBBERO limitare l'accesso in lettura alla proprietà DAV:lockdiscovery in modo appropriato. Inoltre, gli user agent DOVREBBERO fornire il controllo su se le informazioni di contatto vengano inviate o meno, e se le informazioni di contatto vengono inviate, il controllo su esattamente quali informazioni vengono inviate.

20.5. Privacy Issues Connected to Properties (Problemi di privacy connessi alle proprietà)

Poiché i valori delle proprietà vengono tipicamente utilizzati per contenere informazioni come l'autore di un documento, esiste la possibilità che possano sorgere preoccupazioni sulla privacy derivanti dall'accesso diffuso ai dati delle proprietà di una risorsa. Per ridurre il rischio di divulgazione involontaria di informazioni private tramite le proprietà, i server sono incoraggiati a sviluppare meccanismi di controllo degli accessi che separino l'accesso in lettura al corpo della risorsa e l'accesso in lettura alle proprietà della risorsa. Questo consente a un utente di controllare la diffusione dei propri dati delle proprietà senza limitare eccessivamente l'accesso ai contenuti della risorsa.

20.6. Implications of XML Entities (Implicazioni delle entità XML)

XML supporta una funzionalità nota come "entità esterne", definita nella Sezione 4.2.2 di [REC-XML], che istruisce un processore XML a recuperare e includere XML aggiuntivo. Un'entità XML esterna può essere utilizzata per aggiungere o modificare la dichiarazione del tipo di documento (DTD) associata a un documento XML. Un'entità XML esterna può anche essere utilizzata per includere XML all'interno del contenuto di un documento XML. Per XML non validante, come l'XML utilizzato in questa specifica, includere un'entità XML esterna non è richiesto da XML. Tuttavia, XML afferma che un processore XML può, a sua discrezione, includere l'entità XML esterna.

Le entità XML esterne non hanno alcuna affidabilità intrinseca e sono soggette a tutti gli attacchi endemici a qualsiasi richiesta HTTP GET. Inoltre, è possibile per un'entità XML esterna modificare la DTD e quindi influenzare la forma finale di un documento XML, nel peggiore dei casi, modificando significativamente la sua semantica o esponendo il processore XML ai rischi di sicurezza discussi in [RFC3023]. Pertanto, gli implementatori devono essere consapevoli che le entità XML esterne dovrebbero essere trattate come non affidabili. Se un server sceglie di non gestire le entità XML esterne, DOVREBBE rispondere alle richieste contenenti entità esterne con il codice di condizione 'no-external-entities'.

Esiste anche il rischio di scalabilità che accompagnerebbe un'applicazione ampiamente distribuita che facesse uso di entità XML esterne. In questa situazione, è possibile che ci siano numeri significativi di richieste per un'entità XML esterna, potenzialmente sovraccaricando qualsiasi server che gestisce richieste per la risorsa contenente l'entità XML esterna.

Inoltre, esiste anche un rischio basato sulla valutazione delle "entità interne" come definito nella Sezione 4.2.2 di [REC-XML]. Una piccola richiesta accuratamente elaborata utilizzando entità interne annidate può richiedere enormi quantità di memoria e/o tempo di elaborazione per essere elaborata. Gli implementatori di server dovrebbero essere consapevoli di questo rischio e configurare i loro parser XML in modo che richieste come queste possano essere rilevate e rifiutate il prima possibile.

20.7. Risks Connected with Lock Tokens (Rischi connessi ai token di blocco)

Questa specifica incoraggia l'uso di "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]) per i token di blocco (Sezione 6.5), al fine di garantire la loro unicità nello spazio e nel tempo. Gli UUID versione 1 (definiti nella Sezione 4) POSSONO contenere un campo "node" che "consiste di un indirizzo MAC IEEE 802, solitamente l'indirizzo dell'host. Per i sistemi con più indirizzi IEEE, può essere utilizzato qualsiasi indirizzo disponibile". Poiché un server WebDAV emetterà molti blocchi durante la sua vita, l'implicazione è che potrebbe anche esporre pubblicamente il suo indirizzo IEEE 802.

Esistono diversi rischi associati all'esposizione degli indirizzi IEEE 802. Utilizzando l'indirizzo IEEE 802:

È possibile tracciare il movimento dell'hardware da una subnet all'altra.
Potrebbe essere possibile identificare il produttore dell'hardware che esegue un server WebDAV.
Potrebbe essere possibile determinare il numero di ogni tipo di computer che esegue WebDAV.

Questo rischio si applica solo alle versioni UUID basate sull'indirizzo dell'host. La Sezione 4 di [RFC4122] descrive diversi altri meccanismi per generare UUID che non coinvolgono l'indirizzo dell'host e quindi non soffrono di questo rischio.

20.8. Hosting Malicious Content (Hosting di contenuti dannosi)

HTTP ha la capacità di ospitare programmi che vengono eseguiti su macchine client. Questi programmi possono assumere molte forme tra cui script Web, eseguibili, moduli plug-in e macro nei documenti. WebDAV non cambia nessuna delle preoccupazioni sulla sicurezza relative a questi programmi, tuttavia WebDAV è spesso utilizzato in contesti in cui un'ampia gamma di utenti può pubblicare documenti su un server. Il server potrebbe non avere una stretta relazione di fiducia con l'autore che sta pubblicando il documento. I server che consentono ai client di pubblicare contenuti arbitrari possono utilmente implementare precauzioni per verificare che i contenuti pubblicati sul server non siano dannosi per altri client. I server potrebbero farlo con tecniche come la limitazione dei tipi di contenuto che possono essere pubblicati e l'esecuzione di software di rilevamento di virus e malware sui contenuti pubblicati. I server possono anche mitigare il rischio avendo appropriate restrizioni di accesso e autenticazione degli utenti che sono autorizzati a pubblicare contenuti sul server.