it-swarm.com.de

Ist es sicher, dass ein Benutzer einen regulären Ausdruck als Sucheingabe eingibt?

Ich war vor ein paar Tagen in einem Einkaufszentrum und habe auf einer Anzeigetafel nach einem Geschäft gesucht.

Aus Neugier versuchte ich eine Suche mit (.+) und war ein bisschen überrascht, die Liste aller Geschäfte in der Mall zu bekommen.

Ich habe ein bisschen über böse Regexe gelesen, aber es scheint, dass diese Art von Angriff nur stattfinden kann, wenn der Angreifer sowohl die Kontrolle über den zu suchenden Eintrag als auch über die Sucheingabe (die Regex) hat.

Können wir das Mall-Anzeigefeld als DOS-sicher betrachten, wenn man bedenkt, dass der Angreifer nur die Kontrolle über die Sucheingabe hat? (Abgesehen von der Möglichkeit, dass ein Geschäft einen seltsamen Namen wie aaaaaaaaaaaa nennt.)

94
Xavier59

Ich würde das Akzeptieren von vom Benutzer bereitgestellten regulären Ausdrücken mit dem Parsen der meisten Arten von strukturierten Benutzereingaben wie Datumszeichenfolgen oder Abschriften im Hinblick auf das Risiko der Codeausführung vergleichen. Reguläre Ausdrücke sind viel komplexer als Datumszeichenfolgen oder Abschriften (obwohl die sichere Erstellung von HTML aus nicht vertrauenswürdigen Abschriften mit eigenen Risiken verbunden ist) und bieten daher mehr Raum für die Ausnutzung. Das Grundprinzip ist jedoch dasselbe: Bei der Ausnutzung werden unerwartete Nebenwirkungen des Parsing/Kompilierungs-/Matching-Prozess.

Die meisten Regex-Bibliotheken sind ausgereift und in vielen Sprachen Teil der Standardbibliothek. Dies ist ein ziemlich guter (aber nicht sicherer) Indikator dafür, dass sie keine größeren Probleme aufweisen, die zur Codeausführung führen.
Das heißt, es vergrößert zwar Ihre Angriffsfläche, aber es ist nicht unangemessen, die gemessene Entscheidung zu treffen, dieses relativ geringe Risiko zu akzeptieren.

Denial-of-Service-Angriffe sind etwas kniffliger. Ich denke, die meisten Bibliotheken für reguläre Ausdrücke sind auf Leistung ausgelegt, zählen jedoch nicht die Minderung absichtlich langsamer Eingaben zu ihren zentralen Entwurfszielen. Die Angemessenheit, vom Benutzer bereitgestellte reguläre Ausdrücke aus der DoS-Perspektive zu akzeptieren, ist bibliotheksabhängiger.
Zum Beispiel die .NET-Regex-Bibliothek akzeptiert ein Timeout , mit der DoS-Angriffe abgewehrt werden können.
RE2 garantiert die zeitliche Ausführung linear zur Eingabegröße Dies kann akzeptabel sein, wenn Sie wissen, dass Ihr Suchkorpus innerhalb einer angemessenen Größenbeschränkung liegt.

In Situationen, in denen die Verfügbarkeit absolut kritisch ist oder Sie versuchen, Ihre Angriffsfläche so gering wie möglich zu halten, ist es sinnvoll, die Akzeptanz von Regex für Benutzer zu vermeiden, aber ich denke, dies ist eine vertretbare Praxis.

82
Ryan Jenkins

Die Hauptbedrohung beim Akzeptieren regulärer Ausdrücke liegt in Ihrer Regex-Ausführungs-Engine, anstatt Regex selbst zu akzeptieren. Ich würde erwarten, dass die Bedrohung in jeder gut implementierten Engine sehr, sehr gering ist. Die Engine sollte keinen Zugriff auf privilegierte Systemressourcen benötigen und nur Logik für Eingaben ausführen müssen, die direkt an die Engine gesendet werden. Dies bedeutet, dass selbst wenn jemand im Interpreter einen Exploit findet, der Schaden, der angerichtet werden kann, minimal sein sollte.

Insgesamt dient Regex lediglich dazu, nach Mustern innerhalb eines Werts zu suchen. Solange die von Ihnen überprüften Werte ordnungsgemäß überprüft werden, gibt es keinen Grund, warum die Engine selbst Zugriff auf Änderungswerte haben sollte. Ich würde es als allgemein ziemlich sicher einstufen.

Das heißt, ich würde es auch nur in Situationen bereitstellen, in denen es vernünftig war, dies zu tun. Regex ist komplex, möglicherweise zeitaufwändig in der Ausführung und kann an den falschen Stellen verwendet werden. Dies kann einige unerwünschte Auswirkungen auf eine Anwendung außerhalb eines Sicherheitskontexts haben. Im richtigen Anwendungsfall sind sie jedoch äußerst leistungsfähig und äußerst wertvoll. (Ich bin ein Softwarearchitekt, der Hunderttausende von Codezeilen regelmäßig mit Regex umgestaltet.)

15
AJ Henderson

Wie die anderen Antworten gezeigt haben, wäre der Angriffsvektor höchstwahrscheinlich die Regex-Engine.

Während Sie davon ausgehen würden, dass diese Motoren ziemlich ausgereift, robust und gründlich getestet sind, ist dies in der Vergangenheit geschehen:

CVE-2010-1792 Arbitrary Code Execution in Apple Safari und iOS. Zitat aus dem Patch Notes :

Bei der Behandlung regulärer Ausdrücke durch WebKit liegt ein Problem mit der Speicherbeschädigung vor. Der Besuch einer böswillig gestalteten Website kann zu einer unerwarteten Beendigung der Anwendung oder zur Ausführung von willkürlichem Code führen.

Aber natürlich gilt das Argument einer möglicherweise fehlerhaften Bibliothek für alles - sogar vom Benutzer bereitgestellte JPEG-Dateien .

Der andere Aspekt, wenn auch nicht von Natur aus technisch, wäre der (.+) Fall, den Sie erwähnt haben: Sollte das Produkt das willkürliche Abrufen von Daten ermöglichen?

8
PhilLab

Das Problem ist, dass Regex-Engines "zurückverfolgen". Wenn Sie eine Reptitionsoperation (z. B. + oder *) in Ihrem Regex haben, versucht die Regex-Engine, diese mit so viel wie möglich der Eingabezeichenfolge abzugleichen. Wenn die Übereinstimmung später fehlschlägt, wird sie zurückverfolgt und versucht, Ihre Wiederholung mit einem kleineren Teil der Eingabezeichenfolge abzugleichen.

Mehrere Wiederholungsoperationen können zu verschachteltem Backtracking führen, und dies kann zu der Zeit führen, in der der Regex massiv in die Luft gesprengt wird, insbesondere wenn die Wiederholungsoperatoren verschachtelt sind.

https://www.regular-expressions.info/catastrophic.html

8
Peter Green

Nein, bei ReDoS muss der Angreifer keine unnatürlichen Suchergebnisse erstellen.

Die Grundidee von ReDoS besteht darin, dass Sie einen Unterausdruck haben, der auf verschiedene Weise übereinstimmen kann und fast überall in der gesuchten Zeichenfolge mit Ausnahme des Endes übereinstimmt, und diesen Unterausdruck iterieren, um ein katastrophales Backtracking zu erhalten. Wenn Ihre Shop-Beschreibung beispielsweise Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Lautet, können Sie einfach so etwas wie ([^q]|[^q][^q])+ (Oder komplexere Konstrukte mit beispielsweise Lookaheads) verwenden.

Ob dies ein Problem ist, hängt davon ab - wie andere Antworten erklärt haben, können Sie die für die Regex-Engine verfügbare Zeit einfach begrenzen.

5
Tgr