（一）Web安全测评概述

随着Web应用技术的不断发展和技术进步，其所面临的安全问题也越来越突出。据相关部门统计，大部分的黑客攻击发生在应用层，而针对网络协议或硬件漏洞的攻击只占一小部分。作为当前应用最为广泛的网络服务，Web应用面临的安全形势十分严峻。在这种情况下， Web应用的安全测评显得尤为重要。

Web应用安全的核心问题在于用户可以提交任意输入。这体现在：用户可干预客户端与服务器间传送的所有数据，包括请求参数、Cookie和HTTP消息头，可轻易避开客户端执行的任何安全控件（如输入确认验证）；用户可按任何顺序发送请求，用户的操作过程可能和开发人员的设想完全不同；用户可使用多种浏览器访问Web应用程序，大量攻击Web应用程序的工具可以整合到浏览器中。

影响Web应用安全的关键因素可以归纳为安全意识缺乏、开发过程对安全考虑不足、过度强调程序的简化、网络威胁日益严重、资源与时间限制等因素。例如，如果缺乏对网络威胁的及时跟踪，即使是Web应用项目开始时完全了解当前安全威胁的开发团队，也无法保证所开发和部署的应用程序能够完全应对新的威胁。

在Web应用程序出现之前，网络边界就是安全边界，通常采取的安全措施包括对服务进行加固、打补丁，在网络入口设置防火墙，但Web应用程序改变了这一切。对Web应用来说，要想用户正常访问，边界防火墙必须允许通过HTTP/HTTPS数据分组；Web应用程序要想实现它的一些功能，也必须允许它连接后端系统，如数据库、大型主机、后勤系统等。假如Web应用程序存在漏洞，攻击者就可以通过Web浏览器提交精心设计的数据内容，用于攻击后端的核心系统，由于这些攻击数据和Web应用正常的良性数据之间区别不大，很可能穿透所有网络防御。

（二）Web安全测评实施过程

针对典型的Web应用安全测评，可以将其划分为以下5个阶段：资产划分、信息收集、漏洞识别、安全评估以及解决方案的制定。

1、资产划分

在Web安全测评中，资产划分是所有工作的基础，正所谓“方向问题是根本问题”。不同的Web应用根据各自的功能、业务的不同，对于安全的需求有很大的差异。为了避免南辕北辙，往往需要在工作的准备阶段对全局有一个高屋建瓴的认识，明确工作目标以及被测对象在各个层面的安全需求。

如对于保险、医疗、通信等服务类行业，客户的数据无疑是十分敏感且重要的，这部分的数据库在资产划分中应获得较高的权重；而对于一些以高科技为导向的企业，则对自身的研究成果、员工资料等数据的安全性更加敏感。又如，同样一个企业，在员工内部使用的Web应用和面向互联网的Web应用之间明显有着优先级差异，因为部署在互联网上的Web应用可能面临着更多被攻击的风险，其对安全的要求也更高。

所以，在进行测评之前，要对所测试的Web系统进行资产划分，通过与Web系统的管理及开发人员进行沟通，对系统的业务需求、边界等基本情况进行了解与分析，基于被测试系统各部分的重要程度及所处的安全域，将系统的组成划分为以下几个部分：非常重要且不应被直接访问的（如数据库）、比较重要且可以被访问的（如Web应用）、重要程度较低的且可被随意访问的（如互联网）。资产划分的过程也是一个识别和明确被测对象的过程，基于以上思路可以使测试人员明确不同层面资产的安全需求，进而有针对性地开展安全测评。

2、信息收集

确定Web应用的资产划分、分级后，下一步要做的工作就是收集信息。对于Web应用而言，可以通过枚举应用程序的内容与功能，确定用户输入点、服务器端采用的技术架构、服务器端功能，并由此分析出可能实施攻击的位置。

枚举Web应用的内容和功能，其目的在于了解应用程序的实际功能和运行机制。通常情况下，手动浏览即可确定应用程序的绝大部分内容和功能，但为了更全面记录每一项确定的功能，可以使用工具帮助进行分析，如Web Scarab、Nikto等。枚举应用程序功能时，基本可以确定应用程序获取用户输入的位置，主要包括：

（1）URL字符串，包括查询字符串标记；

（2）GET方式提交的参数；

（3）POST请求主体中提交的参数；

（4）Cookie；

（5）HTTP消息头，如User-Agent、Accept-Language等。

确定服务器端技术架构的方法较多，如版本信息、HTTP指纹、页面文件扩展名、目录名称、会话令牌和第三方代码组件。如图3所示，可通过网络数据分析工具获取HTTP指纹，从而确定服务器端的技术架构。

 HTTP指纹

通过留意观察应用程序，一般可推断出与服务器端功能和结构有关的大量信息。例如，应用程序是否执行了全局性的输入确认检查、应用程序是否会查询已到期内容等。

3、漏洞识别

获取Web应用的相关信息后，就对目标应用的功能、技术架构和可能的攻击点有了基本的了解，下一步就要识别Web应用存在的各类安全漏洞。

目前，针对Web应用的安全测评方法主要分为模拟真实的动态攻击以发现漏洞的黑盒测试法和以扫描源代码发现漏洞的白盒测试法两类：黑盒测试在Web应用运行的时候对其进行分析，以发现攻击者可能发现的弱点，优点是可以验证漏洞及其可利用性，但也存在一些不足，如黑盒测试处于开发生命周期后端，可能导致不完整的测试覆盖，黑盒测试也不能指出漏洞产生于应用代码中的具体位置；白盒测试主要针对Web应用的源代码进行分析，定位源代码中可能出现的安全缺陷，优点是在开发生命周期的编码阶段就可以对其安全性进行检测，及早介入以降低损失和维护成本。同时，白盒测试可以指出漏洞在应用代码中的位置，但白盒测试并不真正运行应用代码，可能会出现漏报。

在实际测评工作中，可以采用黑盒测试与白盒测试相结合的方式，在开发生命周期的不同阶段对系统进行安全测试，降低漏洞产生的几率。具体的漏洞识别方法主要有以下4个方面。

（1）代码审查。代码审查是软件开发中常用的白盒测试手段，和品质保证（QA，Quality Assurance）测试相比，它更容易发现与架构及时序相关的问题。对 Web 应用程序代码进行审查时需要仔细检查的相关安全功能组件包括用户验证组件、会话管理组件、访问控制组件、输入输出确认组件、外部组件接口。Web应用程序可以在很多平台上进行开发，进行代码审查时需要审查的代码不尽相同，但在不同的平台上进行代码审查，通常都包括确定用户提交数据的方法、检查会话交互过程、检查潜在危险的API使用和检查平台安全配置这几个步骤。许多类型的Web应用漏洞在代码中都有相对一致的特征，这也意味着通过扫描和搜索代码就可以确定一个Web应用的大部分漏洞。如SQL注入漏洞通常存在于各种硬编码的字符串，与用户可终止的数据串联成最终执行语句；跨站脚本漏洞存在于用户收到的HTML代码中，部分是由用户可控制的数据构成的；路径遍历漏洞存在于用户可控制的输入，未经确认就被传送到文件系统API执行。

（2）数据流建模。数据流建模也是一种基于白盒测试的方法，需要Web应用的开发人员对Web系统可能产生的数据流从起点到终点进行全面、不遗漏的列举。通过梳理Web系统数据的来源盒走向，从Web系统的内部寻找可能造成危害的来源，也包括应用程序的运行是否简洁高效，是否可能存在导致系统意外崩溃的弱点等。

（3）边界分析。边界分析是针对各个安全域的边界进行的分析。由于不同安全域的重要程度不同，其所运用的安全策略也应该有所差异，此时边界安全就显得尤为重要。如位于Web应用的用户是否可以通过某些不应存在的通路访问本地局域网的数据，又如位于互联网层面的用户是否有跳过必要的认证（如登录）而对Web应用进行访问的可能。边界分析就是通过对Web应用中是否存在不合理的越界访问来定位一些典型的安全漏洞。

（4）渗透测试。相对于上述3种白盒测试方法，渗透测试完全从网络攻击者的角度，思考并尝试各种入侵Web应用系统的通道。渗透测试可以避免测试者陷入系统开发者固有的逻辑习惯和操作假设，其测试结果往往更为直观，因此对于Web应用的安全测评是非常重要的环节。常见的渗透测试方法包括针对 Web 应用认证机制的口令字典攻击和暴力破解、针对Web应用访问权限的权限提升、针对Web应用与后台数据库交互的SQL注入、针对文件上传、下载的路径遍历型漏洞等。

4、安全评估

漏洞的危害程度主要受 2 个方面因素影响，即漏洞利用可能性与漏洞造成的损失。如某个溢出漏洞，在当前环境下其利用过程极其困难或者说基本无法利用，那么这个漏洞就是危害程度较低，因为被利用的可能性很小。又如某公司把共享资料的用户名密码直接以明文形式显示于内网某Web站点上，这个漏洞被利用的可能性是很高的，任何位于局域网内的用户都可以获取该信息，而共享的资料为非机密性的学习类资料，则造成的损失较小，通过综合分析判定该漏洞的危害程度在可接受范围内。在真实的测评工作中，在识别漏洞以及安全评估时，需要紧密结合Web应用系统自身的安全需求和测评人员以往工作的经验。

5、解决方案制定

Web安全测评的最终产物是安全解决方案。安全解决方案是根据资产划分、信息收集、漏洞识别及安全评估等阶段的结果生成的一套有针对性的解决办法。Web安全解决方案的制定有两点原则：简洁性与可用性。对于某些大型的Web应用，可能稍有改动都会付出巨大的人力物力，这时需要测试者给出的解决方案是简单有效的，能在解决安全问题的基础上最大程度地压缩成本。如对于某个可导致命令执行的框架漏洞，整体的代码升级固然是根本的解决方案，但是如果漏洞只针对个别页面，则直接将其删除无疑是一种更加简洁易操作的解决方法。

另外，随着Web应用的快速发展，不能因安全解决方案的实施而牺牲了Web应用本身的可用性或性能。如某电子商务网站，出于安全考虑，在用户每次交易时都必须经过各种冗余复杂的验证流程，那么这种解决方案就是失败的。最终解决方案应在Web应用的易用性与安全之间找到一个平衡点，统筹兼顾，从设计上遵循高聚合，低耦合，易于扩展的原则。

（三）Web安全渗透测试

前面介绍了Web安全测评实施过程，其中，漏洞识别是最为关键的一个环节，下面重点介绍用于实现漏洞识别的主要技术手段——渗透测试，并按照典型的Web安全漏洞进行分类讲述。

1、SQL注入攻击测试

SQL注入是指在输入字符串中注入特殊构造的SQL指令，逃避应用程序检查，在数据库服务器上被当作正常SQL指令执行的攻击过程。这种攻击所造成的后果往往很大，一般整个数据库的信息都能被读取或篡改。通过SQL注入，攻击者甚至能够获得更多的包括管理员的权限。SQL注入也是目前Web应用中最为常见的安全漏洞。

SQL注入攻击一般分为4个过程：测试注入点、判断数据库、猜表及字段、猜字段值。如果对SQL注入类型进行划分，可将其分为数字型、字符型、搜索型，这3种类型的SQL注入原理相同，所不同的只是在进行SQL注入时，字符型、搜索型需要注意单引号的闭合问题。下面以数字型SQL注入为例来说明注入方法。

（1）测试注入点

假如现在要测试“http：//www.xxx.com/showdetail.asp?id=49”这个 URL 地址是否存在SQL注入，本文在正常的URL后添加“and 1=1”和“and 1=2”。

如果存在注入，添加“and 1=1”不会影响正常的SQL语句执行，添加“and 1=2”则会影响正常的SQL语句执行。所以，如果添加“and 1=1”时，页面返回正常，而添加“and 1=2”时页面返回不正常，则说明该URL存在注入点。如果添加“and 1=1”“and 1=2”后页面返回都正常，说明网站对SQL注入进行了过滤，但依然显示了正常页面。如果添加“and 1=1”“and 1=2”后页面返回都不正常，说明网站也对SQL注入进行了过滤，这时网站通常会弹出一些提示。

（2）判断数据库

进行数据库判断不是必须的，但有时判断出数据库后，可以有针对性地进行攻击。通常利用数据库之间的SQL语法差异、系统表等来判断。

常见数据库SQL语法与系统表

（3）猜表及字段

假如表存在，表的记录数应≥0，所以本文可以在正常的URL后添加“And（Select Count （*）from Admin）≥0”语句对数据库中是否存在Admin表进行猜测，如下所示。

http://www.xxx.com/showdetail.asp?id=49 and （select count（*） from Admin）≥0

如返回页面与正常URL相同，表示附加条件成立，即表Admin存在；反之则不存在。

将上述 Count（*）替换成 Count（字段名），如下所示。

http://www.xxx.com/showdetail.asp?id=49 and（select count（USERNAME）from Admin）≥0

如返回页面与正常URL相同，表示附加条件成立，即字段USERNAME存在；反之则不存在。

（4）猜字段值

进行字段值的猜测通常有3种方法：select、union select、ASCII码逐字猜解法。select方法通常在网站未对出错进行处理时使用，union select、ASCII码逐字猜解法具有一般性，此处不再赘述。

在确认Web应用存在SQL注入漏洞时，可以采用基于存储过程的注入过滤、基于参数化查询的注入过滤等方式，对Web应用代码进行修改，从而避免注入漏洞。另外，建议用以下2种附加的方法来加以防范。

一种是最小权限法。为了避免注入攻击对数据库造成的损害，可以把每个数据库用户的权限尽可能缩小，不要把DBA或管理员的权限赋予应用程序账户，仅赋予用户执行其操作必需的权限，不要赋予其任何不必要的权限，这对于降低SQL注入漏洞的危害性是非常重要的。

另一种是输入验证白名单法。输入验证能够在数据传递到SQL查询前就察觉到输入是否正确合法，采用白名单而不是黑名单则能在更大程度上保证数据的合法性。

2、跨站脚本（XSS）攻击测试

跨站脚本攻击是近年来使用较多的一种攻击方式。由于Web开发者对用户输入的数据过滤不充分，使攻击者可以向Web页面里嵌入恶意代码，当用户浏览Web页面时，用户浏览器展示整个HTML文档的过程中出现了不被预期的脚本指令并执行，用户浏览器被攻击者控制，这一控制用户浏览器的攻击称为XSS攻击。

XSS根据效果的不同可以分成三类：反射型XSS（也称非持久型XSS）、存储型XSS（也称持久型XSS）和文本对象模型（DOM，Document Object Model）XSS。

（1）反射型XSS

反射型XSS就是将用户提交的数据“反射”给浏览器。即攻击者往往需要诱使用户访问一个经过精心构造的恶意链接，才能攻击成功。

http：//127.0.0.1/xss/xss1.php?param=26

上述示例即为反射型XSS，攻击者需要将以上URL发送给需要攻击的目标用户，当目标用户访问以上URL，浏览器才可解析执行。

（2）存储型XSS

存储型XSS是指用户提交给Web应用程序的数据被永久地保存在服务器的数据库、文件系统或其他地方，后续访问时就能显示到Web页面上。假设某一网站允许用户给其他用户留言，但事实上攻击者没有留言而是写入了一段代码，如图4所示，那么服务器将会存储这些信息，当其他用户单击攻击者伪造的留言所在的页面时，用户的浏览器就会执行攻击者刚才写入的代码，如图5所示。

输入恶意代码

 XSS攻击成功

（3）DOM XSS

在下面的html页面中定义了一段Java Script，根据用户的输入，显示一段HTML代码，攻击者可以在输入时插入一段恶意脚本，最终展示时会执行恶意脚本。DOM XSS和上述2种跨站攻击的差别是，DOM XSS是纯页面脚本的输出，只有规范使用Java Script才可以防御。

test dom xss

确认Web应用存在XSS漏洞时，可采取以下方法进行弥补。

1）验证输入

检查每个输入（包括用户输入、请求头、Cookie、数据库数据…）的有效性，至少应检查输入的类型和数据长度。如Web页面中有一个文本框用于接受用户输入的邮政编码，唯一有效的类型是数字（0~9），且长度应该是6，不能多也不能少。

2）HTML/XML页面输出规范

所有HTML和XML中输出的数据，应该作html escape转义；Java Script内容中输出的“用户可控数据”，应该作Java Script escape转义；对输出到富文本中的“用户可控数据”，应该作富文本安全过滤（允许用户输出HTML的情况）；输出在URL中的数据，应该作URL安全输出；一些HTML标签的属性，如果接收“用户可控数据”，应该作安全检查；针对DOM跨站的解决方案，应参照Java Script安全编码规范进行编程；在给用户设置认证COOKIE时，应该加入HTTPONLY；在style内容中输出的“用户可控数据”，应该作CSS escape转义。

3）AJAX输出规范

XML输出“用户可控数据”时，应该对数据部分作HTML转义；json输出要先对变量内容中的“用户可控数据”单独作 html Escape，再对变量内容作一次 Java Script Escape；非XML输出（包括json、其他自定义数据格式），response包中的http头的content Type，必须为json，且用户可控数据作html Escape后才能输出。

3、业务逻辑漏洞测试

所有的Web业务应用都是通过一系列逻辑步骤实现各种复杂功能的。在代码编写阶段将业务应用分解成一些独立简单的逻辑步骤，按特定顺序执行这些步骤就可以完成相应的业务。在分解的过程中保证程序的安全性是很困难的，所以这些业务逻辑可能会存在各种各样的功能缺陷。

业务逻辑缺陷是由于程序设计者和开发者在程序设计和开发时做出的错误假设导致的。由于程序在设计时很难面面俱到，尤其当应用程序所要实现的功能较为复杂时，使应用程序逻辑缺陷是一种很常见的安全问题，如欺骗密码找回功能、顺序执行缺陷等。即使是最简单的Web应用程序，每个阶段都会执行大量的逻辑操作，这些逻辑操作代表着一个复杂的攻击面。业务逻辑漏洞是比较难以辨别的，因为这种漏洞没有容易辨别的特征签名，每一种逻辑漏洞似乎都是唯一的，无法使用通用的漏洞扫描器发现它们。

业务逻辑缺陷的本质就是设计者或开发者在思考问题过程中做出的特殊假设存在明显的或隐晦的错误，如开发者假设用户会按照一个特定的顺序执行每一个步骤，当攻击者不按这一特定顺序访问，而是跳过其中几个步骤或者调换逻辑步骤的执行顺序，就会进入一种完全出乎开发者意料的情况，导致严重的安全缺陷。

下面给出2个业务逻辑漏洞测试的典型案例。

（1）某网站后台无需登录就可以进入超级管理员用户界面

首先，使用搜索引擎搜索关键词“site：xxxx.com.cn intext：管理登录”找到网站后台登录界面，如图6所示。

搜索登录界面

打开登录界面尝试登录，在没有用户名和口令的情况下无法进入后台管理界面。但是，如果直接使用关键词“site:xxxx.com.cn inurl：admin”搜索后台管理界面，很容易就找到了后台管理界面URL，如图7所示。

 搜索后台管理界面

单击搜索到的链接，就可以直接进入管理页面，得到了超级管理员权限。

（2）某网站逻辑漏洞导致可以无限刷红包

某网站的注册推广活动存在逻辑漏洞导致可以无限刷红包。该网站为了推广业务推出了邀请注册送红包活动，每一个注册用户都会有一个邀请链接，其他用户通过该链接注册成功之后，邀请人会收到一个红包。开发者为了杜绝虚假注册制定了特殊规则，在注册时需要绑定手机号，同一个手机号只能注册一次。测试流程如下。

首先，注册时填写真实的手机号提交，以便能收到短信验证码。在验证页面输入手机收到的短信验证码进行验证。验证的时候使用抓包工具截取提交的数据分组，将其中的手机号改为任意手机号，之后发送该数据分组完成注册，如图8所示。

 修改手机号后提交的数据分组

使用任意手机号绑定注册成功，并提示获取了新手红包。进入用户界面可以查看收到的所有红包，状态都是可以使用的，重复这一系列步骤可以无限领取红包。

4、拒绝服务攻击测试

拒绝服务（Do S，Denial of Service）攻击是让目标网络或目标主机停止提供正常服务的一种攻击形式。这种攻击形式通常是由网络协议、主机操作系统或某些应用程序自身的缺陷造成的，由于这种攻击形式实施简单且追踪困难，攻击者常常出于商业目的而实施此类攻击，如攻击竞争对手的网游主机、媒体服务器或电子交易平台。

常见的拒绝服务攻击方式有SYN Flood、UDP洪水攻击、Ping洪流攻击、Teardrop攻击、Land攻击、Smurf攻击、Fraggle攻击等。

（1）SYN Flood

SYN Flood是最常见的一种攻击方式，这种方式利用了TCP协议的三次握手机制。在TCP连接的三次握手中，假设客户端向服务器发送了SYN分组后突然死机或掉线，那么服务器在发出SYN+ACK应答分组后会无法收到客户端的ACK分组，第三次握手也将无法完成。这种情况下服务器一般会再次发送SYN+ACK给客户端，并等待一段时间后丢弃这个未完成的连接，这个等待的时间称为SYN Timeout，一般是0.5~2 min。一个客户端出现异常导致服务器的一个线程等待这段时间并不是很大的问题，但如果恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源。实际上，如果服务器的TCP/IP协议栈设计得不够健壮，最后的结果往往是堆栈溢出崩溃。即使服务器端足够健壮，服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求。这时从正常客户的角度看来，服务器失去正常的响应。

（2）UDP洪水攻击

攻击者利用简单的TCP/IP服务，如Chargen和Echo来传送毫无用处的占满带宽的数据。通过伪造与某一主机Chargen服务之间的一次UDP连接，回复地址指向开着Echo服务的一台主机，这样就造成在2台主机之间存在很多无用的数据流，这些无用数据流将会导致带宽被耗尽。

（3）Ping洪流攻击

许多操作系统的TCP/IP协议栈都规定ICMP数据分组的大小为64 KB，且在对数据分组的首部进行读取之后，会根据该首部包含的信息来为有效载荷生成缓冲区。当产生畸形、声称自己超过64 KB上限的数据分组时，就会出现内存分配错误，导致TCP/IP堆栈崩溃。

在实际的攻击过程中，攻击者常采用分布式拒绝服务（DDoS，distributed denial of service）攻击的形式，以更快地达到让目标主机停止服务的目的。分布式拒绝服务攻击借助于远程控制技术，发动大量计算设备对一个或多个目标主机同时开展拒绝服务攻击，从而成倍地提高拒绝服务攻击的并发请求数量和带宽，以达到快速有效地使目标主机无法提供服务的目的。DDoS攻击是目前网络层面常见的攻击形式，近年来更是出现了以域名系统作为重点攻击目标、反射放大攻击逐渐增多、利用境外流量攻击境内目标大幅增加等发展趋势。

5、跨站请求伪造攻击测试

跨站请求伪造也被称为“one click attack”或“session riding”，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS完全不同。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不太流行和难以防范，所以被认为比XSS更具危险性。

CSRF是一种依赖Web浏览器、被混淆过的代理人攻击。CSRF的常见特性是依靠用户标识危害网站，利用网站对用户标识的信任，欺骗用户的浏览器发送HTTP请求给目标站点。由于CSRF攻击可以非法获取网站对合法用户的信任，因此经常被攻击者用于对金融系统（如网银系统）的攻击。

6、路径遍历及信息泄露测试

路径遍历漏洞的存在使攻击者可以通过专门设计的路径访问到网站根目录以外的文件，如网站的配置文件、系统关键文件。路径遍历漏洞一般出现在文件读取或展示图片功能这种需要通过参数提交文件名的模块。防范路径遍历漏洞的方法是处理好向文件系统传递过来的参数；合理设置文件和目录的访问权限。

信息泄露指的是攻击者利用Web应用返回的错误信息和公开信息，结合个人经验，获取对攻击Web应用有价值的信息。对网站来说，如果没有做好出错处理，将可能导致直接将网站后台数据库的一些信息暴露给攻击者。此外，也有一些公开途径可以了解关于网站的信息，如Whois查询，如图9所示。有些中小型的网站，通过浏览新闻发布者便可获知对网站具有一定权限的用户。

 Whois查询

7、服务器配置漏洞测试

服务器配置漏洞可能存在于Web应用的各个层次，如服务器操作系统、数据库管理系统、系统框架、应用代码中。开发人员需要和网络管理人员共同确保所有层次都合理配置，如是否缺少补丁、缺省用户是否存在、缺省口令是否修改、是否启用了不必要的服务等。

服务器配置漏洞往往使攻击者能够访问未被授权的系统数据和功能，有时甚至会导致整个系统被破坏。针对此类漏洞的防范工作主要是充分验证系统的安全配置，确保覆盖整个平台和系统，对所有组件都安装了最新的补丁，完善分析变更带来的安全影响，对所有安全配置进行记录，并使用自动化工具对系统进行验证。