11. Security Considerations (Sicherheitsüberlegungen)
Dieser Abschnitt bietet eine kurze Analyse der Sicherheitsüberlegungen für CoAP. Der empfohlene primäre Sicherheitsmechanismus ist DTLS [RFC6347]. Die Sicherheitsumgebung und Anforderungen für CoAP werden weiter in [CoAP-SECUR] diskutiert.
11.1. Parsing the Protocol and Processing URIs (Parsen des Protokolls und Verarbeiten von URIs)
Implementierungen müssen alle Eingaben sorgfältig parsen und validieren, um Pufferüberläufe, Injection-Angriffe und andere Sicherheitsschwachstellen zu verhindern, die aus fehlerhaften Nachrichten oder URIs entstehen können.
11.2. Proxying and Caching (Proxying und Caching)
Proxys und Caches führen zu zusätzlichen Sicherheitsüberlegungen, einschließlich Informationsoffenlegung und Man-in-the-Middle-Angriffen. Die Verwendung von DTLS zum Schutz von Verbindungen zwischen Proxys und Servern ist wichtig.
11.3. Risk of Amplification (Risiko der Verstärkung)
CoAP-Anfragen können zu Antworten führen, die deutlich größer sind als die Anfrage selbst, was für Verstärkungsangriffe ausgenutzt werden könnte. Server sollten Ratenbegrenzung implementieren, und Antworten auf Multicast-Anfragen sollten wie in Abschnitt 8.2 beschrieben verzögert werden.
11.4. IP Address Spoofing Attacks (IP-Adressen-Spoofing-Angriffe)
Die Ausführung über UDP macht CoAP anfällig für IP-Adressen-Spoofing-Angriffe. Die Verwendung von DTLS oder IPsec kann dieses Risiko mindern. Die Randomisierung von Tokens hilft auch, Response-Spoofing zu verhindern.
11.5. Cross-Protocol Attacks (Cross-Protocol-Angriffe)
CoAP-zu-HTTP-Proxys könnten ausgenutzt werden, um Cross-Protocol-Angriffe durchzuführen. Proxys sollten Anfragen sorgfältig validieren und Header und URIs vor dem Weiterleiten bereinigen.
11.6. Constrained Node Considerations (Überlegungen zu eingeschränkten Knoten)
Eingeschränkte Knoten haben möglicherweise nicht ausreichend Ressourcen, um vollständige Sicherheitsmechanismen zu implementieren. In solchen Fällen kann Link-Layer- oder Network-Layer-Sicherheit eine geeignete Alternative sein.
Implementierer sollten basierend auf ihrem spezifischen Bedrohungsmodell und ihren Ressourcenbeschränkungen geeignete Sicherheitsmodi wählen.