1. 项目概述最近在梳理一些开源GIS组件的安全风险GeoServer这个老牌的地图服务器自然绕不过去。CVE-2023-25157这个SQL注入漏洞挺有意思它不像常规的Web应用注入点那么直接而是藏在WMS服务的GetFeatureInfo请求参数里利用PostGIS数据存储的encode函数特性进行绕过。网上公开的POC虽然能复现但很多细节语焉不详比如为什么是这个参数、注入点如何精准定位、不同版本和配置下的差异等。我花了些时间在本地搭建了完整的漏洞环境从流量分析、漏洞原理到利用链构造都走了一遍这篇文章就把这个过程的详细记录和踩过的坑分享出来目标是让你不仅能复现更能理解背后的“为什么”。这个漏洞影响范围是GeoServer 2.18.x到2.22.x的多个版本在默认使用内置H2或文件存储数据的情况下不受影响但一旦用户配置了外部的PostGIS数据库作为数据源风险就来了。攻击者无需认证通过构造特殊的WMS请求就能将恶意SQL语句注入到数据库查询中可能导致数据泄露甚至服务器权限丢失。对于运维和开发同学来说理解这个漏洞的触发路径无论是为了加固自己的系统还是提升安全测试能力都很有价值。2. 漏洞原理深度解析2.1 GeoServer WMS服务与SQL查询链路要理解这个漏洞得先搞清楚GeoServer处理WMSWeb Map Service请求的流程。当用户通过前端地图点击一个位置发起GetFeatureInfo请求来查询该位置的要素属性信息时GeoServer后端会执行一系列操作。关键链路是这样的请求参数如BBOX,X,Y被接收后GeoServer会根据请求的图层Layer找到其背后关联的数据存储Data Store比如一个PostGIS数据库连接。然后它会根据视图范围和点击位置动态生成一个SQL查询语句去数据库中检索对应的地理要素。问题就出在这个动态SQL的生成环节。为了提高灵活性GeoServer允许在样式化图层描述符SLD中使用PropertyName元素和ogc:Function来定制查询中的字段和函数。而encode函数本意是用来处理二进制字段如图片的编码转换如转为base64但在某些版本的GeoServer中对传入encode函数的参数过滤不严导致用户可控的输入被直接拼接进了最终的SQL语句里。2.2 CVE-2023-25157 具体成因根据官方通告和补丁分析漏洞根因在于org.geotools.data.jdbc.JDBCDataStore类中处理GetFeatureInfo请求时对encode函数参数的处理逻辑存在缺陷。攻击者可以在请求中通过精心构造的viewparams或FILTER参数注入包含SQL片段的payload并利用encode函数的执行上下文使这些片段逃逸出字符串字面量的限制成为SQL查询语法的一部分。简单来说正常查询可能是这样的SELECT geom, name FROM cities WHERE ST_Intersects(geom, ST_MakeEnvelope(...))当攻击者注入恶意参数后生成的查询可能变成了SELECT geom, encode((恶意SQL片段)::bytea, base64) FROM cities WHERE ...由于对恶意SQL片段的内容没有进行正确的转义或验证它就可能提前闭合字符串并执行额外的SQL命令比如UNION SELECT来窃取其他表的数据。注意这里需要特别说明实际的注入点非常隐蔽并非所有参数都可利用。公开的POC通常针对cql_filter或viewparams参数因为它们的内容会直接参与SQL WHERE子句的构建。而像bbox这样的几何参数通常会被严格解析为WKT格式不易直接注入。2.3 影响版本与配置前提这个漏洞有明确的版本和配置要求不是所有GeoServer实例都存在风险。受影响版本GeoServer 2.20.x 2.20.7GeoServer 2.19.x 2.19.7GeoServer 2.18.x 2.18.7GeoServer 2.21.x 2.21.4GeoServer 2.22.x 2.22.2必须的配置条件使用了PostGIS数据存储这是漏洞触发的核心。漏洞利用链依赖于PostGIS数据库的encode函数。如果数据存储在Shapefile、GeoPackage或内置的H2中则不受影响。数据源配置了可查询的图层并且该图层通过WMS服务对外发布。未启用预处理语句Prepared Statements在GeoServer的PostGIS数据存储配置中有一个“preparedStatements”选项。如果启用查询会使用参数化查询能有效防御SQL注入。但默认配置或某些优化场景下可能未启用。如果你的GeoServer满足以上条件就需要立刻警惕了。3. 漏洞复现环境搭建纸上得来终觉浅绝知此事要躬行。要真正理解漏洞亲手搭建环境复现一遍是最好的方式。3.1 环境准备与组件版本选择为了还原真实的漏洞场景我们需要搭建一个包含以下组件的环境有漏洞的GeoServer选择2.20.6版本它处于受影响范围且相对稳定。PostgreSQL/PostGIS数据库作为外置数据存储。选择PostgreSQL 12 和 PostGIS 3.1这是一个常见的搭配。测试数据在PostGIS中创建一个包含空间数据和普通属性表的数据库。我推荐使用Docker来搭建可以快速构建和清理环境。以下是docker-compose.yml的核心部分version: 3.8 services: postgis: image: postgis/postgis:12-3.1 container_name: geoserver-postgis environment: POSTGRES_DB: geodata POSTGRES_USER: geoserver POSTGRES_PASSWORD: geoserver123 ports: - 5432:5432 volumes: - ./init-data.sql:/docker-entrypoint-initdb.d/init-data.sql restart: unless-stopped geoserver: image: geoserver/geoserver:2.20.6 container_name: geoserver-vuln ports: - 8080:8080 environment: GEOSERVER_ADMIN_PASSWORD: admin depends_on: - postgis restart: unless-stoppedinit-data.sql文件用于初始化测试数据-- 创建一个测试表 CREATE TABLE IF NOT EXISTS public.vulnerable_locations ( id serial PRIMARY KEY, name varchar(100), description text, geom geometry(Point, 4326) ); -- 插入一些测试数据 INSERT INTO public.vulnerable_locations (name, description, geom) VALUES (Test Point A, A test location, ST_SetSRID(ST_MakePoint(116.397, 39.907), 4326)), (Test Point B, Another test point, ST_SetSRID(ST_MakePoint(121.473, 31.230), 4326)); -- 创建一个包含敏感信息的表模拟被攻击目标 CREATE TABLE IF NOT EXISTS public.secret_users ( uid int PRIMARY KEY, username varchar(50), password_hash varchar(100), email varchar(100) ); INSERT INTO public.secret_users VALUES (1, admin, 5f4dcc3b5aa765d61d8327deb882cf99, adminexample.com);3.2 GeoServer与PostGIS连接配置启动容器后访问http://localhost:8080/geoserver用默认账号admin和密码admin登录。新建工作区Workspace命名为test。新建数据存储Store选择“PostGIS - PostGIS Database”。关键连接参数如下host:postgis(Docker服务名如果宿主机直接连接则用localhost)port:5432database:geodatauser:geoserverpassword:geoserver123重要找到“Advanced”或“Connection Parameters”部分确保preparedStatements选项未勾选。这是漏洞能够成功利用的关键配置之一。发布图层Layer连接成功后发布vulnerable_locations表为一个新的图层坐标系选择EPSG:4326。确保该图层在test工作空间下的WMS服务中是可用的。实操心得在Docker环境中GeoServer容器连接PostGIS容器时主机名应使用Docker Compose中定义的服务名如postgis。如果配置后测试连接失败检查网络是否互通可以进入GeoServer容器内部用ping postgis或nc -zv postgis 5432测试连通性。4. 漏洞利用与POC构造分析环境就绪后我们就可以开始探测和利用漏洞了。核心思路是通过GetFeatureInfo请求在可控参数中嵌入SQL注入Payload。4.1 探测漏洞是否存在首先我们需要一个正常的GetFeatureInfo请求作为基线。打开GeoServer的图层预览选择WMS格式在地图上点击或者直接构造一个简单的请求URLhttp://localhost:8080/geoserver/test/wms? SERVICEWMS VERSION1.1.1 REQUESTGetFeatureInfo LAYERStest:vulnerable_locations STYLES SRSEPSG:4326 BBOX116,39,117,40 WIDTH800 HEIGHT600 QUERY_LAYERStest:vulnerable_locations INFO_FORMATtext/html X400 Y300这个请求会返回点击位置附近vulnerable_locations表的信息。接下来我们尝试注入。一个经典的探测方法是利用时间盲注观察服务器响应延迟。例如通过cql_filter参数注入一个sleep函数PostgreSQL中是pg_sleepcql_filternameTest Point A AND (SELECT CASE WHEN (11) THEN pg_sleep(5) ELSE pg_sleep(0) END)1将这段Payload进行URL编码后替换或追加到上面的请求URL中。如果服务器响应明显延迟了大约5秒说明注入点可能存在且数据库是PostgreSQL。但请注意GeoServer的cql_filter解析器本身有一定过滤直接这样可能不成功。公开的POC利用了encode函数更底层的特性。4.2 理解公开POC的构造网络上流传的POC通常类似以下结构已做简化说明非直接可用viewparamsfilter: AND (SELECT encode(CAST((SELECT version()) AS BYTEA), hex)) IS NOT NULL AND 11这个Payload的精妙之处在于viewparams参数用于向WMS请求传递视图参数其内容在某些情况下会被解析并传递到SQL查询的WHERE子句中。利用encode函数Payload将想要执行的SQL语句SELECT version()放在encode函数的第一个参数里。由于漏洞点在于对encode参数的处理不当这里的SELECT version()可能被直接执行。闭合SQL语句通过 AND ... AND 11来巧妙地闭合原本的查询条件使得注入的SQL成为合法查询的一部分。在实际测试中你需要根据目标GeoServer的版本、图层属性字段名来调整Payload的闭合方式。一个更通用的测试步骤是使用错误回显注入先探测出字段名和数量。4.3 分步手工注入实战让我们尝试手工构造一个从secret_users表窃取数据的注入流程。假设我们已经通过错误信息或枚举知道了vulnerable_locations表查询返回的字段数。步骤一确定字段数和可回显位置首先尝试通过UNION SELECT确定查询的列数。这需要利用错误信息或布尔逻辑。一个试探性的Payload可能通过cql_filter或viewparams注入viewparamsp0: UNION SELECT NULL,NULL,NULL,NULL --不断增加NULL的数量直到页面不报错或返回正常内容从而确定主查询的字段数。假设我们确定是4个字段。步骤二探测数据库信息确定字段数后我们可以用UNION SELECT来替换原有查询结果回显我们想要的信息。例如获取当前数据库用户和版本viewparamsp0: UNION SELECT current_user, version(), NULL, NULL FROM generate_series(1,1) --如果注入成功返回的GetFeatureInfo信息中原本显示name或description的地方就会变成数据库用户和版本号。步骤三提取敏感数据最后构造Payload从secret_users表中提取数据viewparamsp0: UNION SELECT username, password_hash, email, NULL FROM secret_users --重要警告以上Payload仅为原理演示实际构造极其复杂需要精确闭合原查询的字符串、处理字段类型匹配几何字段geom需要特殊处理或置为NULL、以及绕过GeoServer对cql_filter语法的解析限制。公开的EXP往往需要精确的上下文信息。在真实测试中强烈建议使用成熟的SQL注入工具如sqlmap的tamper脚本或深入研究已公开的漏洞利用代码而不是盲目尝试手工拼接。4.4 使用自动化工具验证对于渗透测试人员使用sqlmap这类工具可以更高效地验证漏洞。但针对GeoServer这个特定漏洞需要自定义tamper脚本来处理特殊的参数和过滤规则。保存请求文件将上面那个正常的GetFeatureInfo请求保存为req.txt文件。使用sqlmap探测sqlmap -r req.txt -p viewparams --level 5 --risk 3 --tamperspace2comment --dbmspostgresql-r req.txt: 从文件加载HTTP请求。-p viewparams: 指定测试viewparams参数。--level 5 --risk 3: 提高测试的广度和深度。--tamperspace2comment: 使用注释符替换空格的tamper脚本可能有助于绕过一些过滤。--dbmspostgresql: 指定后端数据库为PostgreSQL提高检测效率。由于GeoServer的WMS接口可能对参数格式有严格要求sqlmap的默认Payload可能无法成功。这时就需要分析拦截到的正常请求和错误响应编写专门的tamper脚本将sqlmap生成的Payload转换成符合viewparams或cql_filter语法格式的字符串。5. 漏洞修复与安全加固建议复现漏洞是为了更好地防御它。如果你正在运维受影响的GeoServer请立即采取以下措施。5.1 官方补丁升级最根本的解决方案是升级到已修复的版本GeoServer 2.22.2 及以上GeoServer 2.21.4 及以上GeoServer 2.20.7 及以上GeoServer 2.19.7 及以上GeoServer 2.18.7 及以上升级前务必做好数据备份和完整的测试因为大版本升级可能涉及配置文件和API的变更。5.2 临时缓解措施如果无法立即升级可以采用以下临时方案禁用PostGIS数据存储的encode函数这是官方推荐的缓解措施。可以通过修改GeoServer的配置文件或通过REST API在PostGIS数据存储的设置中禁用encode函数的使用。具体位置在数据存储的“高级”配置中查找与函数过滤器Function Filter或编码函数Encode Function相关的选项。禁用后攻击链的关键一环就被打断了。启用预处理语句Prepared Statements在PostGIS数据存储的连接参数中找到preparedStatements选项并勾选启用。这会使GeoServer使用参数化查询来执行SQL将用户输入始终视为数据而非代码从而从根本上防御SQL注入。这是非常推荐的安全最佳实践即使打了补丁也应启用。网络层防护WAFWeb应用防火墙部署WAF并配置规则拦截包含encode、UNION SELECT、pg_sleep等关键字的异常WMS请求。但要注意WAF可能被绕过不能作为唯一防线。最小化网络暴露将GeoServer部署在内网通过反向代理如Nginx对外提供有限的服务接口并严格限制可访问的源IP。5.3 安全配置自查清单定期对GeoServer进行安全审计建议检查以下项目检查项安全配置检查方法版本信息使用不受漏洞影响的版本访问{GeoServer_URL}/geoserver/web/查看页面底部版本号数据存储对所有PostGIS存储启用preparedStatements在“数据”-“存储”中编辑每个PostGIS存储检查连接参数服务设置限制不必要的服务如WFS-T, WPS在“服务”-“全局”设置中禁用生产环境不需要的服务用户权限遵循最小权限原则检查“安全”-“用户、组、角色”配置避免使用默认弱密码图层发布仅发布必要的图层和属性检查每个图层的“发布”和“安全”标签页隐藏敏感字段6. 漏洞挖掘与POC编写思考对于安全研究人员这个漏洞也提供了很好的学习案例。它的挖掘思路可以概括为功能点-参数传递链-SQL语句拼接点。功能点分析关注那些需要与数据库交互的动态功能。WMS的GetFeatureInfo、WFS的GetFeature都是重点。参数追踪使用代理工具如Burp Suite拦截所有请求特别关注那些看起来像是过滤条件、查询参数的输入点如cql_filter,viewparams,filter,propertyName等。代码审计/黑盒模糊测试如果条件允许可以审计JDBCDataStore、FilterToSQL等类的源码。黑盒测试则可以向上述参数注入各种SQL关键字、特殊字符单引号、括号、分号、时间延迟函数等观察响应差异、错误信息或延迟。构造有效Payload当发现可能的注入点后难点在于构造一个能被GeoServer解析器接受同时又能被数据库执行的Payload。这需要理解GeoServer的Filter表达式语法CQL/ECQL、OGC Filter以及它是如何被翻译成SQL的。例如你需要知道如何用encode函数包裹你的注入代码如何正确处理几何字段以避免语法错误。编写一个健壮的POC不仅要能触发漏洞还要考虑通用性。一个好的POC应该自动识别目标检查GeoServer版本、是否存在PostGIS数据存储。智能探测注入点尝试多个参数cql_filter,viewparams等和不同的闭合方式。提供多种利用方式如布尔盲注、时间盲注、错误回显注入的Payload。规避常见防御对Payload进行适当的编码和混淆以绕过简单的字符串过滤。7. 防御性编程与安全开发启示从开发角度CVE-2023-25157再次敲响了警钟永远不要信任用户输入。对于GeoServer这类处理复杂标准OGC WMS/WFS和动态查询的应用防御SQL注入需要多层次的手段输入验证与过滤在接收到viewparams、cql_filter等参数时应进行严格的语法验证只允许符合ECQL或OGC Filter标准的字符和结构。使用白名单机制比黑名单更可靠。使用参数化查询或预处理语句这是防御SQL注入的银弹。确保所有通过JDBC执行的SQL语句都使用PreparedStatement将用户输入作为参数绑定而不是字符串拼接。GeoServer中启用preparedStatements选项正是基于此原理。最小权限原则连接数据库的账户只应拥有操作特定业务表所需的最小权限切忌使用sa、postgres等超级管理员账户。这样即使发生注入攻击者能造成的破坏也有限。错误信息处理将详细的数据库错误信息返回给前端是致命的。在生产环境中应配置自定义的错误页面只返回通用的错误提示避免泄露数据库结构、字段名等敏感信息。依赖组件安全及时关注GeoTools、PostGIS JDBC驱动等底层组件的安全更新它们也可能引入安全风险。这个漏洞的复现和分析过程让我深刻体会到安全是一个贯穿设计、开发、测试、部署和运维全生命周期的持续过程。对于运维者及时更新和正确配置是第一道防线对于开发者将安全思维融入编码习惯至关重要对于安全人员则需不断学习新漏洞的利用与防御模式以攻促防。