Kennen Sie schon unseren Podcast? Thomas Bahn diskutiert mit Gästen aus Wirtschaft und Wissenschaft über Künstliche Intelligenz und Chatbots. Jetzt reinhören

de · en

Kritisches Sicherheitsproblem in vielen Domino-Web-Anwendungen

von Thomas,
assono GmbH, Standort Kiel,

In der Web-Entwicklung gilt gemeinhin der Leitspruch: "Eval is evil". Diese Aussage trifft natürlich besonders auf Script-Sprachen wie z.B. PHP zu. Nur allzu leicht gerät hier eine ungefilterte Benutzereingabe oder ein anderer manipulierbarer String in einen Aufruf der Funktion Eval, was dazu führt, dass potenziell gefährlicher Programmcode im Kontext des Web-Servers ausgeführt wird. Ein Szenario das in der Vergangenheit schon zu so manchen Problemen geführt hat.

Viele Lotus Notes und Domino-Entwickler sehen in der aus LotusScript und Java bekannten Funktion Evaluate jedoch kaum eine Gefahr, da hier "nur" Formelsprachen-Ausdrücke ausgeführt werden, die im Web sogar noch zusätzlichen Beschränkungen unterliegen. Diese vermeintliche Sicherheit ist jedoch äußerst trügerisch.

Ein oft gesehener Fehler ist der Gebrauch von Evaluate zum Decodieren von URL-enkodierten Werten mit der Funktion @URLDecode. Dieses Vorgehen bietet sich deshalb so an, weil es in LotusScript keine Entsprechung für diesen Befehl gibt (entsprechendes gilt auch für @URLEncode).

Das Problem ist an dieser Stelle, dass oft aus Nachlässigkeit bzw. aus der falschen Annahme heraus, dies sei unkritisch, keine Überprüfung von Eingaben vorgenommen wird. So passiert es dann, dass Benutzereingaben ungefiltert in den zu evaluierenden String geraten und ausgeführt werden können. Normalerweise geht dann alles gut und der Code arbeitet zuverlässig. Weniger gut geht es, wenn zufällig ein String in die Eingabe gerät, der den Formelsprachen-Ausdruck ungültig werden lässt und einen Fehler verursacht. Richtig gefährlich wird es aber dann, wenn ein gezielter Angriff auf diese Lücke erfolgt. So könnte man z.B. mit einem einfachen @MailSend den Web-Server in eine Spam-Schleuder verwandeln. Je nach dem, ob dem Evaluate noch ein Notes-Dokument mitgegeben wurde, lässt sich dieses dann auch gleich noch auslesen und mit an die Mail anhängen.

Die einfache, aber unsichere Variante:
Public Function URLEncode(value As String) As String

Dim result As Variant

' nicht gut:
' -----------
' die Variable "value" wird ungeprüft in die Evaluate-Zeichenkette eingefügt
result = Evaluate(|@URLEncode("UTF-8"; "| + value + |")|)
URLEncode = result(0)
End Function
Um das Einschleusen von Code zuverlässig zu verhindern, sollten zunächst unter allen Umständen Metazeichen wie der Backslash \ und doppelte Anführungszeichen " ersetzt bzw. durch voranstellen eines Backslash maskiert werden. Dabei sollte bedacht werden, dass in der Formelsprache auch die geschweiften Klammern als Begrenzer für Zeichenketten verwendet werden können, bei Bedarf müssen diese also ebenfalls maskiert werden.

Bessere Variante:
Public Function URLEncode(value As String) As String

Dim result As Variant
Dim tmp As String

' besser:
' ---------
' zunächst die Metazeichen ersetzen
tmp = Replace(value, |\|, |\\|)
tmp = Replace(tmp, |"|, |\"|)

' und den so entschärften Wert weiter verwenden
result = Evaluate(|@URLEncode("UTF-8"; "| + tmp + |")|)
URLEncode = result(0)
End Function
Das Üble an derartig eingeführtem Code ist, dass er für gewöhnlich vollkommen spurlos ausgeführt wird; so könnte darüber fast unbemerkt Spam verschickt werden - zumindest lange genug, um die eigene IP-Adresse in mehrere Blacklists zu bringen, was den legitimen Mailversand dann schnell zum erliegen bringt.

Der beste Ansatz wäre sicherlich, Evaluate gänzlich aus Web-Anwendungen zu verbannen, eine Ausnahme könnte man für Ausdrücke wie @WebDBName machen, da hier keine Parameter erforderlich sind.

Diese Art von Schwachstelle ist übrigens recht verbreitet wie eine Untersuchung einiger Produkte zeigte. Es ist daher sehr zu empfehlen, eingesetzte Anwendungen, insbesondere solche die über das Web verfügbar sind, genau zu überprüfen. Hierbei sollten nicht nur mögliche Benutzereingaben überprüft werden, auch das verarbeiten von HTTP-Headern (z. B. user-agent) ist keinesfalls sicher, da sich HTTP-Requests problemlos manipulieren lassen.

Fachbeitrag HCL Domino Sicherheit Entwicklung

Sie haben Fragen zu diesem Artikel? Kontaktieren Sie uns gerne: blog@assono.de

Sie haben Interesse an diesem Thema?

Gerne bieten wir Ihnen eine individuelle Beratung oder einen Workshop an.

Kontaktieren Sie uns

Weitere interessante Artikel

Sie haben Fragen?

Wenn Sie mehr über unsere Angebote erfahren möchten, können Sie uns jederzeit kontaktieren. Gerne erstellen wir eine individuelle Demo für Sie.

assono GmbH

Standort Kiel (Zentrale)
assono GmbH
Lise-Meitner-Straße 1–7
24223 Schwentinental

Standort Hamburg
assono GmbH
Bornkampsweg 58
22761 Hamburg

Telefonnummern:
Zentrale: +49 4307 900 407
Vertrieb: +49 4307 900 411

E-Mail-Adressen:
kontakt@assono.de
bewerbung@assono.de