8. Security Considerations (Sicherheitsüberlegungen)

8. Security Considerations (Sicherheitsüberlegungen)

Obwohl technisch außerhalb des Umfangs dieser Spezifikation, gilt Abschnitt 10 ("Sicherheitsüberlegungen" (Security Considerations)) von RFC 3629 [STD63] für Implementierungen. Besondere Beachtung muss dem letzten Absatz von Abschnitt 3 ("UTF-8-Definition" (UTF-8 definition)) von RFC 3629 [STD63] geschenkt werden. Eine I-Regexp-Implementierung muss möglicherweise Einschränkungen der Plattformimplementierung in dieser Hinsicht abmildern.

Wie in Abschnitt 6 erörtert, können komplexere Regexp-Bibliotheken ausnutzbare Fehler (Exploitable Bugs) enthalten, die zu Abstürzen und Remote-Code-Ausführung (Remote Code Execution) führen können. Es gibt auch das Problem, dass solche Bibliotheken oft Leistungsmerkmale (Performance Characteristics) haben, die schwer vorherzusagen sind, was zu Angriffen führt, die eine Implementierung durch Abgleich mit einem teuren, vom Angreifer kontrollierten Regexp überlasten.

I-Regexps wurden so konzipiert, dass sie eine Implementierung auf eine Weise ermöglichen, die gegen beide Bedrohungen widerstandsfähig ist. Dieses Ziel muss während der gesamten Implementierungsarbeit angegangen werden. Nicht-prüfende Implementierungen (siehe Abschnitt 3.1) werden wahrscheinlich Sicherheitseinschränkungen jeder von ihnen verwendeten Regexp-Engine aufdecken, was weniger problematisch sein kann, wenn diese Engine mit Sicherheitsüberlegungen im Hinterkopf gebaut wurde (z.B. [RE2]). In jedem Fall ist eine prüfende Implementierung (Checking Implementation) dennoch EMPFOHLEN.

Implementierungen, die speziell die I-Regexp-Teilmenge implementieren, können mit Sorgfalt so konzipiert werden, dass sie im Allgemeinen in linearer Zeit und Raum (Linear Time and Space) in der Eingabe laufen und erkennen, wenn dies nicht der Fall wäre (siehe unten).

Bestehende Regexp-Engines sollten in der Lage sein, die meisten I-Regexps leicht zu handhaben (nach den in Abschnitt 5 besprochenen Anpassungen), können aber für einige Arten von I-Regexps übermäßige Ressourcen verbrauchen oder sie vollständig ablehnen, weil sie keine effiziente Ausführung garantieren können. (Beachten Sie, dass verschiedene Versionen derselben Regexp-Bibliothek für diese Fälle mehr oder weniger anfällig für übermäßigen Ressourcenverbrauch sein können.)

Insbesondere bieten Bereichsquantifizierer (Range Quantifiers) (wie in a{2,4}) besondere Herausforderungen sowohl für bestehende als auch für auf I-Regexp fokussierte Implementierungen. Implementierungen können daher Bereichsquantifizierer in der Zusammensetzbarkeit (Composability) einschränken (Verschachtelte Bereichsquantifizierer wie (a{2,4}){2,4} verbieten) oder im Bereich (sehr große Bereiche wie a{20,200000} verbieten) oder jeden übermäßigen Ressourcenverbrauch erkennen und ablehnen, der durch Bereichsquantifizierer verursacht wird.

I-Regexp-Implementierungen, die zur Auswertung von Regexps aus nicht vertrauenswürdigen Quellen verwendet werden, müssen in diesen Fällen robust (Robust) sein. Implementierer, die bestehende Regexp-Bibliotheken verwenden, werden ermutigt:

• ihre Dokumentation zu überprüfen, um zu sehen, ob Abhilfen (Mitigations) konfigurierbar sind, wie z.B. Grenzen beim Ressourcenverbrauch, und
• ihren eigenen Grad an Robustheit zu dokumentieren, der sich aus der Anwendung solcher Abhilfen ergibt.