5. Sicherheitsüberlegungen
5. Sicherheitsüberlegungen
Die Sicherheitsüberlegungen für PATCH sind nahezu identisch mit den Sicherheitsüberlegungen für PUT ([RFC2616], Abschnitt 9.6). Dazu gehören die Autorisierung von Anfragen (möglicherweise durch Zugriffskontrolle und/oder Authentifizierung) und die Sicherstellung, dass Daten nicht durch Übertragungsfehler oder versehentliches Überschreiben beschädigt werden. Alle Mechanismen, die für PUT verwendet werden, können auch für PATCH verwendet werden. Die folgenden Überlegungen gelten besonders für PATCH.
Ein Dokument, das gepatcht wird, ist möglicherweise anfälliger für Beschädigungen als ein Dokument, das vollständig überschrieben wird, aber diese Sorge kann durch die Verwendung von Mechanismen wie bedingten Anfragen (conditional requests) mit ETags und dem If-Match-Anfrage-Header, wie in Abschnitt 2 beschrieben, angegangen werden. Wenn eine PATCH-Anfrage fehlschlägt, kann der Client eine GET-Anfrage an die Ressource ausgeben, um zu sehen, in welchem Zustand sie sich befindet. In den meisten Fällen kann der Client den Inhalt der Ressource überprüfen, um zu sehen, ob der PATCH zum erwarteten Zustand geführt hat.
Manchmal versucht ein HTTP-Vermittler (intermediary), Viren, die über HTTP gesendet werden, zu erkennen, indem er den Body der PUT/POST-Anfrage oder GET-Antwort überprüft. Die PATCH-Methode erschwert eine solche Überwachung, da weder das Quelldokument noch das Patch-Dokument ein Virus sein müssen, das Ergebnis jedoch sein könnte. Diese Sicherheitsüberlegung unterscheidet sich nicht wesentlich von denen, die bereits durch Byte-Range-Downloads (byte-range downloads), das Herunterladen von Patch-Dokumenten, das Hochladen von gezippten (komprimierten) Dateien usw. eingeführt wurden.
Einzelne Patch-Dokumentformate haben ihre eigenen spezifischen Sicherheitsüberlegungen, die mit diesen Formaten dokumentiert werden. Anwendungen, die PATCH verwenden, sollten alle Sicherheitsüberlegungen berücksichtigen, die mit den von ihnen unterstützten spezifischen Formaten verbunden sind. Einige allgemeine Überlegungen gelten jedoch für alle Patch-Dokumentformate, einschließlich:
- Patch-Dokumente können Anweisungen enthalten, Teile einer Ressource zu ändern, die der Client nicht berechtigt ist zu ändern. Ein solcher PATCH sollte vom Server abgelehnt werden.
- Einige Patch-Dokumentformate können Bestimmungen für bedingte Anfragen haben. Der Server MUSS (MUST) sicherstellen, dass solche Bedingungen basierend auf dem Zustand der Ressource zum Zeitpunkt der Operation bewertet werden, nicht auf dem Zustand zum Zeitpunkt der Anfrage.
- Server MÜSSEN (MUST) vorsichtig sein bei der Validierung von Ressourcen, die nicht vertrauenswürdigen Inhalt enthalten (z. B. vom Benutzer bereitgestellte Daten). Viele Validierungsoperationen erfordern das Parsen der Ressource, und das Parsen nicht vertrauenswürdiger Inhalte bietet Möglichkeiten für Denial-of-Service-Angriffe (denial-of-service attacks) und andere bösartige Verhaltensweisen.
- Patch-Dokumente haben möglicherweise keine maximale Größe, die im Patch-Dokumentformat definiert ist. Server möchten möglicherweise ihre eigene maximale Größe für Patch-Dokumente festlegen, um sich vor Angriffen zu schützen, die sehr große Patch-Dokumente verwenden, und zu große Patch-Dokumente mit dem Statuscode 413 (Request Entity Too Large) ablehnen.
- Anwendungsdesigner sollten die Auswirkungen von Patch-Operationen auf Ressourcen berücksichtigen, die möglicherweise über mehrere Standorte verteilt sind. Beispielsweise kann ein Patch auf einer Kopie einer Ressource erfolgreich sein, aber auf einer anderen fehlschlagen, was zu einer Ressourcenstatusdivergenz (resource state divergence) führt.