20. Security Considerations (Considérations de sécurité)

Cette section est fournie pour détailler les questions concernant les implications de sécurité dont les applications WebDAV doivent être conscientes.

Toutes les considérations de sécurité de HTTP/1.1 (discutées dans [RFC2616]) et XML (discutées dans [RFC3023]) s'appliquent également à WebDAV. De plus, les risques de sécurité inhérents à la création à distance nécessitent une technologie d'authentification plus forte, introduisent plusieurs nouvelles préoccupations en matière de confidentialité et peuvent augmenter les dangers d'une mauvaise conception de serveur. Ces questions sont détaillées ci-dessous.

20.1. Authentication of Clients (Authentification des clients)

En raison de leur accent sur la création, les serveurs WebDAV doivent utiliser une technologie d'authentification pour protéger non seulement l'accès à une ressource réseau, mais aussi l'intégrité de la ressource. De plus, l'introduction de la fonctionnalité de verrouillage nécessite un support pour l'authentification.

Un mot de passe envoyé en clair sur un canal non sécurisé est un moyen inadéquat pour protéger l'accessibilité et l'intégrité d'une ressource car le mot de passe peut être intercepté. Étant donné que l'authentification de base pour HTTP/1.1 effectue essentiellement une transmission en texte clair d'un mot de passe, l'authentification de base NE DOIT PAS être utilisée pour authentifier un client WebDAV auprès d'un serveur à moins que la connexion ne soit sécurisée. De plus, un serveur WebDAV NE DOIT PAS envoyer un défi d'authentification de base dans un en-tête WWW-Authenticate à moins que la connexion ne soit sécurisée. Un exemple de connexion sécurisée serait une connexion Transport Layer Security (TLS) employant une suite de chiffrement forte et une authentification de serveur.

Les applications WebDAV DOIVENT prendre en charge le schéma d'authentification Digest [RFC2617]. Étant donné que l'authentification Digest vérifie que les deux parties d'une communication connaissent un secret partagé, un mot de passe, sans avoir à envoyer ce secret en clair, l'authentification Digest évite les problèmes de sécurité inhérents à l'authentification de base tout en fournissant un niveau d'authentification utile dans un large éventail de scénarios.

20.2. Denial of Service (Déni de service)

Les attaques par déni de service sont particulièrement préoccupantes pour les serveurs WebDAV. WebDAV plus HTTP permet des attaques par déni de service sur chaque partie des ressources d'un système.

Le stockage sous-jacent peut être attaqué en effectuant un PUT de fichiers extrêmement volumineux.
Demander des opérations récursives sur de grandes collections peut attaquer le temps de traitement.
Effectuer plusieurs demandes en pipeline sur plusieurs connexions peut attaquer les connexions réseau.

Les serveurs WebDAV doivent être conscients de la possibilité d'une attaque par déni de service à tous les niveaux. La réponse appropriée à une telle attaque PEUT être de simplement abandonner la connexion. Ou, si le serveur est capable de faire une réponse, le serveur PEUT utiliser une demande de statut de niveau 400 telle que 400 (Bad Request) et indiquer pourquoi la demande a été refusée (une réponse de statut de niveau 500 indiquerait que le problème vient du serveur, alors que les attaques DoS involontaires sont quelque chose que le client est capable de remédier).

20.3. Security through Obscurity (Sécurité par l'obscurité)

WebDAV fournit, via la méthode PROPFIND, un mécanisme pour lister les ressources membres d'une collection. Cela diminue considérablement l'efficacité des techniques de sécurité ou de confidentialité qui reposent uniquement sur la difficulté de découvrir les noms des ressources réseau. Les utilisateurs de serveurs WebDAV sont encouragés à utiliser des techniques de contrôle d'accès pour empêcher l'accès non désiré aux ressources, plutôt que de dépendre de l'obscurité relative de leurs noms de ressources.

20.4. Privacy Issues Connected to Locks (Problèmes de confidentialité liés aux verrous)

Lors de la soumission d'une demande de verrouillage, un agent utilisateur peut également soumettre un champ XML 'owner' donnant des informations de contact pour la personne prenant le verrou (pour les cas où une personne, plutôt qu'un robot, prend le verrou). Ces informations de contact sont stockées dans une propriété DAV:lockdiscovery sur la ressource et peuvent être utilisées par d'autres collaborateurs pour commencer une négociation sur l'accès à la ressource. Cependant, dans de nombreux cas, ces informations de contact peuvent être très privées et ne doivent pas être largement diffusées. Les serveurs DEVRAIENT limiter l'accès en lecture à la propriété DAV:lockdiscovery de manière appropriée. De plus, les agents utilisateurs DEVRAIENT fournir un contrôle sur l'envoi ou non d'informations de contact, et si des informations de contact sont envoyées, un contrôle sur exactement quelles informations sont envoyées.

20.5. Privacy Issues Connected to Properties (Problèmes de confidentialité liés aux propriétés)

Étant donné que les valeurs de propriété sont généralement utilisées pour contenir des informations telles que l'auteur d'un document, il existe la possibilité que des préoccupations en matière de confidentialité puissent survenir en raison d'un accès généralisé aux données de propriété d'une ressource. Pour réduire le risque de divulgation involontaire d'informations privées via les propriétés, les serveurs sont encouragés à développer des mécanismes de contrôle d'accès qui séparent l'accès en lecture au corps de la ressource et l'accès en lecture aux propriétés de la ressource. Cela permet à un utilisateur de contrôler la diffusion de ses données de propriété sans restreindre excessivement l'accès au contenu de la ressource.

20.6. Implications of XML Entities (Implications des entités XML)

XML prend en charge une fonctionnalité connue sous le nom d'"entités externes", définie dans la section 4.2.2 de [REC-XML], qui demande à un processeur XML de récupérer et d'inclure du XML supplémentaire. Une entité XML externe peut être utilisée pour ajouter ou modifier la déclaration de type de document (DTD) associée à un document XML. Une entité XML externe peut également être utilisée pour inclure du XML dans le contenu d'un document XML. Pour le XML non validant, tel que le XML utilisé dans cette spécification, inclure une entité XML externe n'est pas requis par XML. Cependant, XML déclare qu'un processeur XML peut, à sa discrétion, inclure l'entité XML externe.

Les entités XML externes n'ont aucune fiabilité inhérente et sont soumises à toutes les attaques endémiques à toute demande HTTP GET. De plus, il est possible pour une entité XML externe de modifier la DTD et donc d'affecter la forme finale d'un document XML, dans le pire des cas, en modifiant considérablement sa sémantique ou en exposant le processeur XML aux risques de sécurité discutés dans [RFC3023]. Par conséquent, les implémenteurs doivent être conscients que les entités XML externes doivent être traitées comme non fiables. Si un serveur choisit de ne pas gérer les entités XML externes, il DEVRAIT répondre aux demandes contenant des entités externes avec le code de condition 'no-external-entities'.

Il existe également un risque d'évolutivité qui accompagnerait une application largement déployée qui utiliserait des entités XML externes. Dans cette situation, il est possible qu'il y ait un nombre important de demandes pour une entité XML externe, surchargeant potentiellement tout serveur qui traite les demandes pour la ressource contenant l'entité XML externe.

De plus, il existe également un risque basé sur l'évaluation des "entités internes" telles que définies dans la section 4.2.2 de [REC-XML]. Une petite demande soigneusement élaborée utilisant des entités internes imbriquées peut nécessiter d'énormes quantités de mémoire et/ou de temps de traitement pour être traitée. Les implémenteurs de serveurs doivent être conscients de ce risque et configurer leurs analyseurs XML afin que des demandes comme celles-ci puissent être détectées et rejetées le plus tôt possible.

20.7. Risks Connected with Lock Tokens (Risques liés aux jetons de verrouillage)

Cette spécification encourage l'utilisation de "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]) pour les jetons de verrouillage (section 6.5), afin de garantir leur unicité dans l'espace et le temps. Les UUID de version 1 (définis dans la section 4) PEUVENT contenir un champ "node" qui "se compose d'une adresse MAC IEEE 802, généralement l'adresse de l'hôte. Pour les systèmes avec plusieurs adresses IEEE, n'importe laquelle disponible peut être utilisée". Étant donné qu'un serveur WebDAV émettra de nombreux verrous au cours de sa durée de vie, l'implication est qu'il peut également exposer publiquement son adresse IEEE 802.

Plusieurs risques sont associés à l'exposition des adresses IEEE 802. En utilisant l'adresse IEEE 802:

Il est possible de suivre le déplacement du matériel de sous-réseau en sous-réseau.
Il peut être possible d'identifier le fabricant du matériel exécutant un serveur WebDAV.
Il peut être possible de déterminer le nombre de chaque type d'ordinateur exécutant WebDAV.

Ce risque ne s'applique qu'aux versions UUID basées sur l'adresse de l'hôte. La section 4 de [RFC4122] décrit plusieurs autres mécanismes pour générer des UUID qui n'impliquent pas l'adresse de l'hôte et ne souffrent donc pas de ce risque.

20.8. Hosting Malicious Content (Hébergement de contenu malveillant)

HTTP a la capacité d'héberger des programmes qui sont exécutés sur des machines clientes. Ces programmes peuvent prendre de nombreuses formes, notamment des scripts Web, des exécutables, des modules de plug-in et des macros dans des documents. WebDAV ne modifie aucune des préoccupations de sécurité autour de ces programmes, mais WebDAV est souvent utilisé dans des contextes où un large éventail d'utilisateurs peut publier des documents sur un serveur. Le serveur peut ne pas avoir une relation de confiance étroite avec l'auteur qui publie le document. Les serveurs qui permettent aux clients de publier du contenu arbitraire peuvent utilement mettre en œuvre des précautions pour vérifier que le contenu publié sur le serveur n'est pas nuisible aux autres clients. Les serveurs pourraient le faire par des techniques telles que la restriction des types de contenu autorisés à être publiés et l'exécution de logiciels de détection de virus et de logiciels malveillants sur le contenu publié. Les serveurs peuvent également atténuer le risque en ayant des restrictions d'accès appropriées et une authentification des utilisateurs autorisés à publier du contenu sur le serveur.