等保2.0数据输入有效性检验测评研究

林川

（海南正邦信息科技有限公司，海南海口，570100）

0 引言

近年来，利用网络安全漏洞实施攻击的安全事件频发，给网络空间安全带来了不可逆的危害。而漏洞产生的很大一个原因是程序员在软件编码时，未考虑对用户提交的数据进行有效性校验，应用系统程序直接使用用户提交上来的数据[1]。导致攻击者可通过浏览器或攻击工具，在URL或其他输入区域（如表单等），向服务器发送特殊请求，从中发现应用系统程序存在的漏洞，进而操纵和控制应用系统程序，窃取或修改用户数据，甚至获取服务器管理权限。因此，加强对数据输入有效性校验成为保障应用系统程序安全性的一个重要手段。但事实上，很多程序员缺乏安全编程知识和经验，他们所理解的数据输入有效性检验，更多的是基于软件容错的数据格式或边界值的校验，却忽略了更为重要的恶意代码检验[2]。本文作者曾长期从事软件编码工作，当前又主要从事等级测评工作。本文将结合软件编码和等级测评工作实践，尝试为测评人员提供一些数据输入有效性检验办法。

网络安全行业对数据输入有效性校验内涵的理解变化，从等保1.0到等保2.0相关标准要求项内容的演变也可见一斑：

通过表1可以看出，等保1.0对数据有效性检验的要求主要是从传统的应用软件容错角度出发，要求对输入的数据格式或长度进行校验。而等保2.0在等保1.0的基础上提出了更高更合理的要求，从安全性的角度出发，要求对输入的内容进行校验，不再仅限于数据格式和长度，从而扩大了校验范围。同时把该要求项归类到入侵防范控制点，更能体现数据输入有效性检验对等保对象安全性的重要影响。

表1 等保1.0和等保2.0对数据有效性检验要求项比较

《GB/T 28448—2019信息安全技术 网络安全等级保护测评要求》中针对第三级等级保护对象“应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求”要求项提出的测评实施要求包括以下两项：（1）应核查系统设计文档的内容是否包括数据有效性检验功能的内容或模块；（2）应测试验证是否对人机接口或通信接口输入的内容进行有效性检验。

本文将围绕第二项测评实施要求，从技术实施的角度，介绍常见的因为缺少数据输入有效性校验而导致的安全性漏洞及其测试验证方法，并给出该要求项的单项测评方法及风险判定方法。

1 常见数据输入类别

常见的数据输入类别主要包括以下两种类别：

（1）人机接口输入：泛指通过人机交互界面输入的数据，包含桌面应用、Web应用、手机APP应用等人机交互界面数据输入；（2）通信接口输入：泛指通过API（Application Programming Interface）接口向后台服务器发送数据的数据输入，包含中间件调用、公共类/函数调用、Web Service服务调用等。

2 常见漏洞分析及测试验证方法

2.1 弱口令漏洞

2.1.1 漏洞分析

弱口令漏洞，就是应用系统程序存在容易被别人猜测到或被破解工具破解的口令。弱口令漏洞的产生通常是应用系统程序在用户注册时，没有对用户输入的口令进行长度、复杂度等校验，导致用户可以设置弱口令[3]。该漏洞可能导致攻击者利用互联网公开的常见弱口令尝试登录管理后台，进而利用后台管理功能窃取或修改数据，甚至可能通过对后台进行漏洞挖掘及利用，最终获取服务器权限。

弱口令漏洞无论是人机接口输入，还是通信接口输入，都普遍存在。

2.1.2 测试验证方法

（1）在用户注册页面，尝试使用弱口令注册一个测试用户。看是否可以注册成功。

（2）在用户登录页面，尝试使用已存在的用户登录，输入常见弱口令。看是否可以登录成功。

（3）使用暴力破解工具（如Burpsuite）抓取用户登录请求，通过加载弱口令字典进行暴力破解。看是否可以破解成功。

2.2 SQL注入漏洞

2.2.1 漏洞分析

SQL注入漏洞，就是恶意攻击者通过将SQL命令插入到Web表单提交、输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意SQL命令。具体来说，它是利用应用系统程序对恶意SQL语句缺乏检验的缺陷，将恶意SQL命令注入到后台数据库引擎执行，达到窃取、更改、删除数据的目的。甚至进一步对服务器植入后门程序，获取服务器权限。

通常情况下，容易注入SQL的位置包括：（1）URL参数提交，主要为GET请求参数；（2）表单提交，主要是POST请求，也包括GET请求；（3）Cookie参数提交；（4）HTTP请求头部的一些可修改的值，比如Referer、User_Agent等。

2.2.2 测试验证方法

传入SQL语句可控参数分为以下三类：

（1）数字型：参数不用被引号括起来，如http://host/test.php?id=1

（2）字符型：参数要被引号括起来,如http://host/test.php?name=’张三’

（3）搜索型：搜索输入框的参数

对于数字型可控参数，可以在参数后面添加and 1=1和and 1=2两个字符串判断是否存在注入点。如果http://host/test.php?id=1and1=1返回正常内容，而http://host/test.php?id=1 and 1=2返回空内容，则可以判定该点存在SQL注入漏洞。

对于字符型可控参数，可以在参数后面添加‘and‘1’=’1和‘and‘1’=’2两个字符串判断是否存在注入点。如果http://host/test.php?name=’张三’and‘1’=’1返回正常内容，而http://host/test.php?name=’张三’and‘1’=’2返回空内容，则可以判定该点存在SQL注入漏洞。

对于搜索型的可控参数，可以在搜索输入框输入’和%字符判断是否存在注入点。如果输入’返回错误，输入%字符正常返回，则可以判定该点存在SQL注入漏洞。

2.3 XSS跨站脚本攻击漏洞

2.3.1 漏洞分析

XSS跨站脚本攻击漏洞，就是恶意攻击者利用Web应用程序对恶意脚本语句缺乏检验的缺陷，往Web页面里插入恶意Js代码，当用户打开有恶意代码的链接或页面时，恶意代码通过浏览器自动执行，从而达到进行窃取隐私、钓鱼欺骗、窃取密码、传播恶意代码等目的。

XSS跨站脚本攻击漏洞包括以下两种类型：

（1）反射型跨站脚本攻击：这是目前最普遍的跨站类型。跨站代码一般存在于链接中，请求这样的链接时，跨站代码经过服务端反射回来，这类跨站的代码不存储到服务端（比如数据库中）；

（2）存储型跨站脚本攻击：这是危害最直接的跨站类型，跨站代码存储于服务端（比如数据库中）。常见情况是某用户在论坛发贴，如果论坛没有过滤用户输入的Javascript代码数据，就会导致其他浏览此贴的用户的浏览器会执行发贴人所嵌入的Javascript代码。

2.3.2 测试验证方法

（1）反射型跨站脚本攻击验证

容易出现反射型跨站脚本攻击漏洞的功能点一般是URL参数需要在页面显示的功能点，例如站内搜索、查询功能点。

测试时可以在输入的参数后添加＜script＞alert（Test XSS）＜/script＞语句，比如http://host/test.php?name=＜script＞alert（TestXSS）＜/script＞。如果页面弹出显示TestXSS的告警框，则可以判定该点存在反射型跨站脚本攻击漏洞。如果没有弹出显示TestXSS的告警框，则在返回的页面上单击鼠标右键，选择“查看源文件”，查找网页源文件中是否包含完整的字符串＜script＞alert（TestXSS）＜/script＞，如果有也可以判定该点存在反射型跨站脚本攻击漏洞。

（2）存储型跨站脚本攻击验证

容易出现存储型跨站脚本攻击漏洞的功能点一般是用户输入的文本信息保存到数据库中，并能够在页面展示的功能点，例如用户留言、发送站内消息、个人信息修改等功能点。

测试时可以在表单输入框里输入＜script＞alert（Test XSS）＜/script＞再保存表单。然后访问该信息的展示页面，如果页面弹出显示TestXSS的告警框，则可以判定该点存在存储型跨站脚本攻击漏洞。如果没有弹出显示TestXSS的告警框，则在页面上单击鼠标右键，选择“查看源文件”，查找网页源文件中是否包含完整的字符串＜script＞alert（Test XSS）＜/script＞，如果有也可以判定该点存在存储型跨站脚本攻击漏洞。

2.4 越权漏洞

2.4.1 漏洞分析

越权漏洞，就是应用系统程序在检查授权（Authorization）时存在纰漏，使得恶意攻击者在获得低权限用户帐号权限后，可以利用一些方式绕过权限检查，访问或者操作到原本无权访问的权限功能。

越权漏洞包括以下两种类型：

（1）水平越权：攻击者尝试访问与他拥有相同权限的用户的资源。比如某系统中有个人资料这个功能，A账号和B账号都可以访问这个功能，但是A账号的个人信息和B账号的个人信息不同，可以理解为A账号和B账号个人资料这个功能上具备水平权限的划分。此时，A账号通过攻击手段访问了B账号的个人资料，就是水平越权漏洞。

（2）垂直越权：一个低权限用户尝试高权限用户的资源。比如说某个系统分为普通用户和管理员，管理员有系统管理功能，而普通用户没有，那我们就可以理解管理功能具备垂直权限划分。如果普通用户能利用某种攻击手段访问到管理功能，就是垂直越权漏洞。

2.4.2 测试验证方法

越权漏洞包括以下两种类型：

（1）水平越权验证

常见的水平越权高发功能点有：根据订单号查订单、根据用户ID查看帐户信息、修改/找回密码等。

测试时以普通用户A身份登录系统，找到一条只有A用户可以查看的数据链接，比如："http://host/orderDetail.php?id=46"，复制此链接。再以另一具有相同权限的普通用户B登录系统,在地址栏输入:"http://host/orderDetail.php?id=46"，如果可以查看到该条数据，则可以判定该点存在水平越权漏洞。

（2）垂直越权验证

常见的垂直越权高发功能点为只有高权限用户有权限可以操作的页面。

测试时以超级管理员admin（高权限用户）身份登录系统，找到一个只有超级管理员（高权限）才有的功能的链接，比如:"http://host/userManage/userList.php",显示出所有的用户，并复制此链接。再以普通用户登录系统,在地址栏输入:"http://host/userManage/userList.php"，如果可以查看到其所有的user，则可以判定该点存在垂直越权漏洞。

2.5 任意文件上传漏洞

2.5.1 漏洞分析

任意文件上传漏洞，就是恶意攻击者利用Web应用的文件上传功能上传任意文件，包括网站后门文件（webshell），进而获取服务器权限。其本质是应用系统程序代码没有严格限制和校验用户上传的文件后缀以及文件类型，导致被攻击者利用。

文件上传是web中最为常见的一种功能需求，关键是文件上传之后服务器端的处理、解释文件的过程是否安全。一般的情况有：

（1）上传文件WEB脚本语言，服务器的WEB容器解释并执行了用户上传的脚本，导致代码执行；

（2）上传文件FLASH策略文件crossdomain.xml，以此来控制Flash在该域下的行为；

（3）上传文件是病毒、木马文件，攻击者用以诱骗用户或管理员下载执行；

（4）上传文件是钓鱼图片或包含了脚本的图片，某些浏览器会作为脚本执行，可用于实施钓鱼或欺诈；

2.5.2 测试验证方法

找到Web应用中可以上传图片、文件的功能点，尝试上传跟该Web应用开发语言对应的后缀名文件（例如该Web应用是用PHP语言开发的，则可以上传一个test.php文件）。如果可以上传成功，则可以判定该点存在任意文件上传漏洞。要注意的是有一些Web应用可能会对上传的文件做校验，但是校验方法不够严谨，此时可以采取一些绕过方法来规避这些校验。

2.6 任意文件下载漏洞

2.6.1 漏洞分析

任意文件下载漏洞，就是对用户输入的文件名称的安全性验证不足而导致的一种安全漏洞。漏洞使得恶意攻击者通过输入一些特殊字符，可以绕过服务器的安全限制，获取服务器的配置文件及系统文件（web根目录以外的文件），甚至执行系统命令。其本质是应用系统程序在代码实现上没有充分过滤用户输入的../之类的目录跳转符，导致攻击者可以通过提交目录跳转来遍历服务器上的任意文件。

2.6.2 测试验证方法

通过判断的网站编程语言，并根据其url中部分提供的参数，构造相关的路径信息。例如，收集到网站中间件版本为apache，则想办法构造../../../WEB-INF/web.xml等，然后查看其是否可被下载下来。如果可以下载，则可以判定该点存在任意下载文件漏洞。注意应用系统程序代码可能已经对下载文件的后缀做了限制，即已经在代码固定了可以下载的文件后缀名，这时可以尝试使用截断符号%00对后缀名限制进行绕过，看是否还能下载任意文件。

2.7 文件包含漏洞

2.7.1 漏洞分析

文件包含漏洞，就是程序员出于灵活性考虑，使用文件包含函数包含公共代码文件，同时将被包含的文件设置为可控参数，用来进行动态调用。由于加载的可控参数没有经过检验或者严格定义，恶意攻击者可以修改可控参数，来实现调用恶意代码文件，从而获取服务器管理权限。其大多出现在PHP代码中，PHP中文件包含的函数包括：include（）、include_once（）、require（）、require_once（）。如果传入这些函数的参数可控则可能引发文件包含漏洞。

文件包含漏洞包含以下两种类型：（1）本地文件包含：只能包含当前服务器上的文件；（2）远程文件包含：可以包含本地和远程服务器上的文件，是否为远程文件包含取决于php.ini配置里的allow_url_fopen是否开启。

2.7.2 测试验证方法

通过观察参数特征猜测是否使用文件包含，看文件包含参数后面为具体文件名（如：http://host/test.php?filename=include.php）。再通过../目录跳转符尝试读取系统文件、服务器日志文件或者配置文件。如读取Linux的/etc/passwd文件:http://host/test.php?filename=../../../../etc/passwd。如果可以读取到文件内容，则可以判定该点存在文件包含漏洞。

3 单项测评与风险判定

3.1 单项测评

《测评要求》中针对第三级等级保护对象“应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求”要求项提出的测评实施要求包括以下两项：（1）应核查系统设计文档的内容是否包括数据有效性检验功能的内容或模块；（2）应测试验证是否对人机接口或通信接口输入的内容进行有效性检验。

单元判定为：如果1）-2）均为肯定，则符合本测评单元指标要求，否则不符合或部分符合本测评单元指标要求。

3.1.1“测评实施要求2）”实施分析

如果测试验证发现系统存在前面第三节所列出的常见安全漏洞或者其它可能导致系统被入侵的漏洞，则可以判定“测评实施要求2）”不符合要求。否则判定“测评实施要求2）”符合要求。

3.1.2 单项测评结论

“测评实施要求1）”测评方法比较简单，只需核查系统设计文档是否包括数据有效性检验功能的内容或模块，有则判定“测评实施要求1）”符合要求，无则判定不符合要求。再结合“测评实施要求2）”的符合性结论，可以得出以下四种可能的单项测评结论：

表2 单项测评结论判定

3.2 风险判定

要求项“应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求”的风险判定，主要通过测试验证，依据所发现的漏洞引发的后果严重程度来进行。

如果应用系统程序存在SQL注入、跨站脚本攻击、任意文件上传等可能导致敏感数据泄露、网页篡改、服务器被入侵等严重后果的漏洞，且未采取其他技术手段对漏洞进行防范的，可判定为高风险。存在后果不严重的漏洞或者系统设计文档的内容未包括数据有效性检验功能的内容或模块的可酌情判定为中低风险。

在进行整体测评时，如果发现存在以下两种补偿措施，可酌情降低风险等级：

（1）应用系统程序存在SQL注入、跨站脚本等高危漏洞，但系统部署了WAF、云盾等应用防护产品，在防护体系下无法成功利用，可酌情降低风险等级；

（2）不与互联网交互的内网系统，可根据系统重要程度、漏洞危害情况、内部网络的防护措施等情况，酌情判断风险等级。

4 结束语

本文仅介绍常见的因为缺少数据输入有效性校验而引申的安全性漏洞及其测试验证方法。在现场测评时，除了测试验证这些常见的漏洞以外，其它有可能被攻击者利用的漏洞也应一并测试验证。测试验证方法也不必完全拘泥于上述测试验证方法，可以配合漏洞扫描工具，结合漏洞特点进行深入挖掘，以便全面发现应用系统程序的安全问题。