20. Security Considerations (Sicherheitsüberlegungen)

Dieser Abschnitt wird bereitgestellt, um Fragen bezüglich Sicherheitsauswirkungen zu detaillieren, derer sich WebDAV-Anwendungen bewusst sein müssen.

Alle Sicherheitsüberlegungen von HTTP/1.1 (besprochen in [RFC2616]) und XML (besprochen in [RFC3023]) gelten auch für WebDAV. Darüber hinaus erfordern die Sicherheitsrisiken, die dem Remote-Authoring innewohnen, eine stärkere Authentifizierungstechnologie, führen mehrere neue Datenschutzbedenken ein und können die Gefahren durch schlechtes Serverdesign erhöhen. Diese Probleme werden im Folgenden detailliert beschrieben.

20.1. Authentication of Clients (Authentifizierung von Clients)

Aufgrund ihrer Betonung auf Authoring müssen WebDAV-Server Authentifizierungstechnologie verwenden, um nicht nur den Zugriff auf eine Netzwerkressource zu schützen, sondern auch die Integrität der Ressource. Darüber hinaus erfordert die Einführung von Sperrfunktionalität Unterstützung für die Authentifizierung.

Ein Passwort, das im Klartext über einen unsicheren Kanal gesendet wird, ist ein unzureichendes Mittel zum Schutz der Zugänglichkeit und Integrität einer Ressource, da das Passwort abgefangen werden kann. Da die Basisauthentifizierung für HTTP/1.1 im Wesentlichen eine Klartextübertragung eines Passworts durchführt, DARF die Basisauthentifizierung NICHT verwendet werden, um einen WebDAV-Client bei einem Server zu authentifizieren, es sei denn, die Verbindung ist sicher. Darüber hinaus DARF ein WebDAV-Server KEINE Basisauthentifizierungs-Challenge in einem WWW-Authenticate-Header senden, es sei denn, die Verbindung ist sicher. Ein Beispiel für eine sichere Verbindung wäre eine Transport Layer Security (TLS)-Verbindung, die eine starke Cipher-Suite und Serverauthentifizierung verwendet.

WebDAV-Anwendungen MÜSSEN das Digest-Authentifizierungsschema [RFC2617] unterstützen. Da die Digest-Authentifizierung überprüft, dass beide Parteien einer Kommunikation ein gemeinsames Geheimnis, ein Passwort, kennen, ohne dieses Geheimnis im Klartext senden zu müssen, vermeidet die Digest-Authentifizierung die Sicherheitsprobleme, die der Basisauthentifizierung innewohnen, und bietet gleichzeitig ein Authentifizierungsniveau, das in einer Vielzahl von Szenarien nützlich ist.

20.2. Denial of Service (Dienstverweigerung)

Denial-of-Service-Angriffe sind für WebDAV-Server von besonderer Bedeutung. WebDAV plus HTTP ermöglicht Denial-of-Service-Angriffe auf jeden Teil der Systemressourcen.

Der zugrunde liegende Speicher kann angegriffen werden, indem extrem große Dateien mit PUT übertragen werden.
Die Anforderung rekursiver Operationen auf großen Sammlungen kann die Verarbeitungszeit angreifen.
Das Erstellen mehrerer Pipeline-Anfragen über mehrere Verbindungen kann Netzwerkverbindungen angreifen.

WebDAV-Server müssen sich der Möglichkeit eines Denial-of-Service-Angriffs auf allen Ebenen bewusst sein. Die angemessene Reaktion auf einen solchen Angriff KANN sein, einfach die Verbindung zu trennen. Oder, wenn der Server in der Lage ist, eine Antwort zu geben, KANN der Server eine 400-Level-Statusanfrage wie 400 (Bad Request) verwenden und angeben, warum die Anfrage abgelehnt wurde (eine 500-Level-Statusantwort würde darauf hinweisen, dass das Problem beim Server liegt, während unbeabsichtigte DoS-Angriffe etwas sind, das der Client beheben kann).

20.3. Security through Obscurity (Sicherheit durch Verschleierung)

WebDAV bietet über die PROPFIND-Methode einen Mechanismus zum Auflisten der Mitgliedsressourcen einer Sammlung. Dies verringert die Wirksamkeit von Sicherheits- oder Datenschutztechniken erheblich, die nur auf der Schwierigkeit beruhen, die Namen von Netzwerkressourcen zu entdecken. Benutzern von WebDAV-Servern wird empfohlen, Zugriffskontrolltechniken zu verwenden, um unerwünschten Zugriff auf Ressourcen zu verhindern, anstatt sich auf die relative Verschleierung ihrer Ressourcennamen zu verlassen.

20.4. Privacy Issues Connected to Locks (Datenschutzprobleme im Zusammenhang mit Sperren)

Beim Senden einer Sperranfrage kann ein Benutzeragent auch ein 'owner' XML-Feld senden, das Kontaktinformationen für die Person bereitstellt, die die Sperre erwirbt (für die Fälle, in denen eine Person und nicht ein Roboter die Sperre erwirbt). Diese Kontaktinformationen werden in einer DAV:lockdiscovery-Eigenschaft der Ressource gespeichert und können von anderen Mitarbeitern verwendet werden, um Verhandlungen über den Zugriff auf die Ressource zu beginnen. In vielen Fällen können diese Kontaktinformationen jedoch sehr privat sein und sollten nicht weit verbreitet werden. Server SOLLTEN den Lesezugriff auf die DAV:lockdiscovery-Eigenschaft angemessen einschränken. Darüber hinaus SOLLTEN Benutzeragenten die Kontrolle darüber bieten, ob Kontaktinformationen überhaupt gesendet werden, und wenn Kontaktinformationen gesendet werden, die Kontrolle darüber, welche Informationen genau gesendet werden.

20.5. Privacy Issues Connected to Properties (Datenschutzprobleme im Zusammenhang mit Eigenschaften)

Da Eigenschaftswerte typischerweise verwendet werden, um Informationen wie den Autor eines Dokuments zu halten, besteht die Möglichkeit, dass Datenschutzbedenken aufgrund des weitreichenden Zugriffs auf die Eigenschaftsdaten einer Ressource entstehen könnten. Um das Risiko einer versehentlichen Freigabe privater Informationen über Eigenschaften zu verringern, werden Server ermutigt, Zugriffskontrollmechanismen zu entwickeln, die den Lesezugriff auf den Ressourcenkörper und den Lesezugriff auf die Eigenschaften der Ressource trennen. Dies ermöglicht es einem Benutzer, die Verbreitung seiner Eigenschaftsdaten zu kontrollieren, ohne den Zugriff auf den Inhalt der Ressource übermäßig einzuschränken.

20.6. Implications of XML Entities (Auswirkungen von XML-Entitäten)

XML unterstützt eine Funktion, die als "externe Entitäten" bekannt ist und in Abschnitt 4.2.2 von [REC-XML] definiert ist, die einen XML-Prozessor anweist, zusätzliches XML abzurufen und einzuschließen. Eine externe XML-Entität kann verwendet werden, um die mit einem XML-Dokument verbundene Dokumenttyp-Deklaration (DTD) anzuhängen oder zu ändern. Eine externe XML-Entität kann auch verwendet werden, um XML innerhalb des Inhalts eines XML-Dokuments einzuschließen. Für nicht validierendes XML, wie das in dieser Spezifikation verwendete XML, ist das Einschließen einer externen XML-Entität von XML nicht erforderlich. XML gibt jedoch an, dass ein XML-Prozessor nach eigenem Ermessen die externe XML-Entität einschließen kann.

Externe XML-Entitäten haben keine inhärente Vertrauenswürdigkeit und unterliegen allen Angriffen, die für jede HTTP GET-Anfrage endemisch sind. Darüber hinaus ist es möglich, dass eine externe XML-Entität die DTD modifiziert und somit die endgültige Form eines XML-Dokuments beeinflusst, im schlimmsten Fall seine Semantik erheblich ändert oder den XML-Prozessor den in [RFC3023] diskutierten Sicherheitsrisiken aussetzt. Daher müssen sich Implementierer bewusst sein, dass externe XML-Entitäten als nicht vertrauenswürdig behandelt werden sollten. Wenn ein Server sich entscheidet, externe XML-Entitäten nicht zu verarbeiten, SOLLTE er auf Anfragen, die externe Entitäten enthalten, mit dem Bedingungscode 'no-external-entities' antworten.

Es besteht auch das Skalierbarkeitrisiko, das eine weit verbreitete Anwendung begleiten würde, die externe XML-Entitäten verwendet. In dieser Situation ist es möglich, dass es erhebliche Zahlen von Anfragen für eine externe XML-Entität gibt, die potenziell jeden Server überlasten, der Anfragen für die Ressource mit der externen XML-Entität verarbeitet.

Darüber hinaus besteht auch ein Risiko basierend auf der Bewertung von "internen Entitäten", wie in Abschnitt 4.2.2 von [REC-XML] definiert. Eine kleine, sorgfältig gestaltete Anfrage mit verschachtelten internen Entitäten kann enorme Mengen an Speicher und/oder Verarbeitungszeit zur Verarbeitung erfordern. Server-Implementierer sollten sich dieses Risikos bewusst sein und ihre XML-Parser so konfigurieren, dass solche Anfragen so früh wie möglich erkannt und abgelehnt werden können.

20.7. Risks Connected with Lock Tokens (Risiken im Zusammenhang mit Sperr-Tokens)

Diese Spezifikation ermutigt die Verwendung von "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]) für Sperr-Tokens (Abschnitt 6.5), um deren Einzigartigkeit über Raum und Zeit zu garantieren. Version 1 UUIDs (definiert in Abschnitt 4) KÖNNEN ein "node"-Feld enthalten, das "aus einer IEEE 802 MAC-Adresse besteht, normalerweise die Hostadresse. Für Systeme mit mehreren IEEE-Adressen kann jede verfügbare verwendet werden". Da ein WebDAV-Server während seiner Lebensdauer viele Sperren ausgibt, besteht die Implikation darin, dass er möglicherweise auch seine IEEE 802-Adresse öffentlich preisgibt.

Mit der Offenlegung von IEEE 802-Adressen sind mehrere Risiken verbunden. Unter Verwendung der IEEE 802-Adresse:

Es ist möglich, die Bewegung von Hardware von Subnetz zu Subnetz zu verfolgen.
Es kann möglich sein, den Hersteller der Hardware zu identifizieren, auf der ein WebDAV-Server läuft.
Es kann möglich sein, die Anzahl jedes Computertyps zu bestimmen, auf dem WebDAV läuft.

Dieses Risiko gilt nur für hostadressbasierte UUID-Versionen. Abschnitt 4 von [RFC4122] beschreibt mehrere andere Mechanismen zum Generieren von UUIDs, die die Hostadresse nicht einbeziehen und daher nicht von diesem Risiko betroffen sind.

20.8. Hosting Malicious Content (Hosting bösartiger Inhalte)

HTTP hat die Fähigkeit, Programme zu hosten, die auf Client-Maschinen ausgeführt werden. Diese Programme können viele Formen annehmen, einschließlich Web-Skripte, ausführbare Dateien, Plug-in-Module und Makros in Dokumenten. WebDAV ändert keine der Sicherheitsbedenken rund um diese Programme, doch wird WebDAV oft in Kontexten verwendet, in denen eine breite Palette von Benutzern Dokumente auf einem Server veröffentlichen kann. Der Server hat möglicherweise keine enge Vertrauensbeziehung zum Autor, der das Dokument veröffentlicht. Server, die es Clients ermöglichen, beliebige Inhalte zu veröffentlichen, können nützlicherweise Vorsichtsmaßnahmen implementieren, um zu überprüfen, dass auf dem Server veröffentlichte Inhalte für andere Clients nicht schädlich sind. Server könnten dies durch Techniken wie die Einschränkung der Arten von Inhalten, die veröffentlicht werden dürfen, und das Ausführen von Viren- und Malware-Erkennungssoftware auf veröffentlichten Inhalten tun. Server können das Risiko auch mindern, indem sie angemessene Zugriffsbeschränkungen und Authentifizierung von Benutzern haben, die Inhalte auf dem Server veröffentlichen dürfen.