Die Code-Injektion ist eine kritische Schwachstelle, die es einem Drittanbieter ermöglicht, Code auf der serverseitigen Software auszuführen. Die Expression Language Injection ist eine Art der Remote-Code-Ausführung, die sensible Daten vom Server offenlegt. Der Remote-Code wird ausgeführt und zeigt Variablen, Passwörter, Funktionen oder Code an. Im schlimmsten Fall kann es einem Angreifer eine Fernsteuerung des Servers ermöglichen.
Was ist Expression Language Injection?
Die Expression Language Injection ist eine Schwachstelle, die JavaServer Pages (JSP), Active Server Pages (ASP) und andere auf einem Webserver gehostete Ausdruckssprachen betrifft. Diese Sprachen sind interpretierte Sprachen, sodass jeder an den Server gesendete Code während der Laufzeit der Anwendung kompiliert wird, im Gegensatz zu Standard-kompilierten Sprachen mit binären ausführbaren Dateien. In einer interpretierten Sprache wird der Code auf dem Server kompiliert, wenn ein Benutzer eine Seite anfordert.
Wenn eine EL-Anwendung (Expression Language) anfällig für die Injektion der Expressionssprache ist, sendet ein Angreifer erstellten Code als Eingabe an die Anwendung, entweder in der Abfragezeichenfolge oder in einem Formobjekt. Der Code wird zur Laufzeit zusammengestellt und kann dann Variablen, Passwörter und andere sensible Informationen anzeigen. EL-Schwachstellen treten in veralteten Versionen interpretierter Sprachen häufig auf. Daher sollten veraltete Anwendungen vor der Bereitstellung in der Produktion durchdringt werden. Nach einem kritischen Ereignis benötigen Unternehmen Disaster-Recovery-Pläne, um die Datenoffenlegung und -nutzung zu beheben.
So funktioniert die Expression Language Injection
Jede Anwendung, die eine interpretierte Sprache ausführt, sollte Code und Sonderzeichen aus der Eingabe entfernen. Ohne Scrubbing-Eingabe akzeptiert die Anwendung Code und führt ihn auf dem Server aus. Die meisten EL-Injektionsschwachstellen betreffen JSP, daher verwenden wir im folgenden Beispiel JSP-Code. Der folgende Ausschnitt ist ein Beispiel für eine einzige Codezeile, die anfällig für die EL-Injektion ist:
<spring:message code="${param['message']}" text=""/>
In diesem Beispiel nimmt das Codeattribut einen Parameter, der eine Zeichenfolge enthält. Wenn ein Angreifer Code in den Parameter einfügt, wird er auf dem Server kompiliert und ausgeführt. Benutzer sehen diesen Code nicht auf ihrer lokalen Webseite, sodass Angreifer gängige Skripte verwenden, um Schwachstellen bei der EL-Injektion zu finden.
Häufige Schwachstellen, die zur Expression Language Injection führen
Ähnlich wie bei jeder Injektionsschwachstelle stammt die EL-Injektionsschwachstelle aus keiner Validierung der Eingaben in der Serveranwendung. Im gleichen Beispiel wie oben kann es sich bei der Nachrichtenzeichenfolge um eine harmlose Zeichenfolge handeln, aber auch um Code. Anstatt eine harmlose Zeichenfolge zu senden, sollte der Benutzer Folgendes senden:
${"aaaa".toString().concat(T(java.lang.Runtime).getRuntime().exec('ls -l'))}
Die obige Eingabe versucht, den Systembefehl „ls -l“ auf dem Server auszuführen. Dieser Befehl listet die Dateien und Verzeichnisse im aktuellen Verzeichnis auf. Bei einer Liste von Dateien könnte ein Angreifer dann versuchen, einen weiteren Befehl zum Öffnen und Anzeigen des Inhalts einer Datei in seinem Fenster zu senden. Eine Datei kann sensible Daten wie Passwörter enthalten. Von dort könnte der Angreifer potenziell auf den Server zugreifen und zusätzliche bösartige Aktionen durchführen.
Expression Language Injection erkennen
Durchdringungstests – sowohl in der White Box als auch in der Black Box – werden Schwachstellen bei der EL-Injektion erkennen. White-Box-Tests sind eine Methode, bei der Sicherheitsexperten den Code auf Schwachstellen überprüfen. Unternehmen geben den Code an Sicherheitsprüfer weiter, und Prüfer identifizieren alle Codeschwachstellen in einem Bericht. Dies ist ein gemeinsamer proaktiver Ansatz beim Datenschutz.
Beim Black-Box-Penetrationstest wird dieselbe Form von Scans und Schwachstellenerkennung verwendet wie bei einem Angreifer. Sicherheitsexperten greifen die Anwendung an, ohne den Code zu kennen, sodass jede Validierung oder Verteidigung getestet werden kann. Bei Grau-Box-Tests handelt es sich um eine Mischung aus Black-Box- und White-Box-Tests und ist oft eine Methode zur Penetrationsprüfung von Webanwendungen.
Verhindern der Injektion von Expressionssprachen
Die beste Möglichkeit, EL-Injektionsangriffe zu erkennen, besteht darin, Code zu validieren und Eingaben mit bestimmten Zeichen zu entfernen. Beispielsweise sollte die Eingabe für ein Namensfeld keine „<” or “>“-Zeichen enthalten. Entwickler sollten Bibliotheken verwenden, die erstellt wurden, um diese Zeichen zu erkennen und zu entfernen oder die Eingabe zu löschen und dem Benutzer einen Fehler anzuzeigen.
Andere Zeichen können auch bösartig sein. Auf einer JSP-Seite beginnen Code-Snippets mit den „<%” characters and end with the “%>“-Zeichen. Diese Zeichen sollten zusammen aus der Eingabe entfernt werden. Angreifer führen zahlreiche Kombinationen von bösartigem Code durch, um die Erkennung zu umgehen, sodass die beste Möglichkeit, sie zu erkennen, darin besteht, eine für die Eingabevalidierung entwickelte Bibliothek zu verwenden. SIEM-Anwendungen können auch Exploits erkennen und Analysen bereitstellen, wenn Ihre Anwendung ein Ziel ist.
Fazit
EL-Injektionsschwachstellen sollten als kritische Sicherheitsprobleme behandelt werden. Lassen Sie Ihre interpretierten Sprachanwendungen immer auf Schwachstellen bei der Injektion und auf alle anderen Personen testen, die sensible Daten offenlegen könnten. Entwickler sollten Validierungstools verwenden, um EL-Injektionen zu erkennen und zu stoppen, und veraltete Anwendungen, die JSP und ASP verwenden, sollten engmaschig auf Angriffe überwacht werden.
Pure Storage verfügt über die Sicherheitsinfrastruktur und Bedrohungsüberwachung, um Ihre Anwendungen vor Sicherheitsangriffen zu schützen.
