WEB安全测试分类及防范测试方法.docx

WEB安全测试分类及防范测试方法.docx

《WEB安全测试分类及防范测试方法.docx》由会员分享，可在线阅读，更多相关《WEB安全测试分类及防范测试方法.docx（16页珍藏版）》请在冰豆网上搜索。

WEB安全测试分类及防范测试方法

WEB安全测试分类及防范测试方法

1Web应用程序布署环境测试2

1.1HTTP请求引发漏洞的测试2

1.2操作系统目录安全性及Web应用程序布署环境目录遍历问题测试2

2应用程序测试3

2.1SQL注入漏洞测试3

2.1.1SQL注入漏洞攻击实现原理3

2.1.2SQL注入漏洞防范措施4

2.1.3SQL注入漏洞检测方法5

2.2表单漏洞测试6

2.2.1表单漏洞实现原理6

2.2.2表单漏洞防范措施6

2.2.3表单漏洞检测方法6

2.3Cookie欺骗漏洞测试8

2.3.1Cookie欺骗实现原理8

2.3.2Cookie欺骗防范措施8

2.3.3Cookie欺骗监测方法9

2.4用户身份验证测试9

2.4.1用户身份验证漏洞防范措施9

2.4.2用户身份验证检测方法9

2.5文件操作漏洞测试9

2.5.1文件操作漏洞实现原理9

2.5.2文件操作漏洞防范措施10

2.5.3文件操作漏洞检测方法10

2.6Session测试11

2.6.1客户端对服务器端的欺骗攻击11

2.6.2直接对服务器端的欺骗攻击11

2.6.3Session漏洞检测方法12

2.7跨网站脚本（XSS）漏洞测试13

2.7.1跨网站脚本（XSS）漏洞实现原理13

2.7.2跨网站脚本（XSS）漏洞防范措施13

2.7.3跨网站脚本（XSS）漏洞测试方法14

2.8命令注射漏洞测试14

2.9日志文件测试14

2.10访问控制策略测试14

2.10.1访问控制策略测试方法14

3数据库问题测试15

3.1数据库名称和存放位置安全检测15

3.2数据库本身的安全检测15

3.3数据使用时的一致性和完整性测试15

4容错测试15

4.1容错方案及方案一致性测试16

4.2接口容错测试16

4.3压力测试16

1Web应用程序布署环境测试

用来架构Web网站的UNIX、LINUX、WINDOWS等服务器端操作系统和服务器软件都可能存在漏洞（如前不久被发现的LINUX系统内核漏洞），这些漏洞都会对Web应用程序造成安全威胁。

因此，在布署Web应用程序前，应对Web应用程序的布署环境进行严格的测试，检查一切已知的漏洞，发现新的漏洞，将应用程序环境带来的安全威胁降底到最低程度。

1.1HTTP请求引发漏洞的测试

超长URL的HTTP请求，特殊格式字符的HTTP请求，某些不存在文件的HTTP请求，COMInternetServices（CIS）–RPCoverHTTP漏洞，从而引发拒绝服务，源代码显示，站点物理路径泄露，执行任意命令及命令注入等安全问题。

因此，对非常规URL的HTTP请求要做全面的测试，以发现这方面的漏洞。

测试工作以人工方式为主，并配以Tripwire和AIDE的完整性检查工具检查系统文件，对于发现的漏洞，可采取关闭所有不必要的服务和安装系统补丁加固系统。

另外要保持对最新补丁和安全公告的追踪，在实验环境进行测试后正式安装在布署Web应用程序的主机上。

1.2操作系统目录安全性及Web应用程序布署环境目录遍历问题测试

目录权限和目录安全性直接影响着Web的安全性。

测试中要检查Web应用程序布署环境的目录权限和安全性，不给恶意用户任何可用的权限。

目录遍历可能导致用户从客户端

看到或下载、删除Web服务器文件。

因此，要测试Web应用程序及布署环境是否存在目录遍历问题；若存在该漏洞，可通过在各级目录中存放默认文档或及时升级系统来避免。

1.3系统中危险组件的测试

系统中危险组件的存在，会给恶意用户留下非常危险的“后门”。

如恶意用户可利用Windows系统中存在的FileSystemObject组件篡改、下载或删除服务器中的任何文件。

因此，若系统中需要使用这些组件，可将这些组件更名；否则将其删除。

1.4TCP端口测试

开放非必要的端口，会给Web应用程序带来安全威胁。

因此，在布署Web应用程序前，要用端口扫描软件对布署环境进行TCP端口测试，禁止UDP，只开启必要的TCP端口。

另

外，在系统运行过程中要不断测试，在服务器端使用lsof工具（ForUnix）或者Inzider工具（Forwindows）扫描端口使用情况，必要时从远程使用Nmap工具进行异常端口占用检测。

如果发现有未知的进程占用端口，要关闭端口或杀掉进程。

2应用程序测试

应用程序中存在的漏洞是影响Web安全的主要方面，程序员编写的软件都可能有漏洞，有些漏洞可能要经过许多年后才会被发现。

特别是不断新加的功能，这些改动，都会带

来安全方面的问题。

因此，应用程序测试要伴随着系统开发、布署和运行的全过程。

2.1SQL注入漏洞测试

2.1.1SQL注入漏洞攻击实现原理

SQL（StructuredQueryLanguage）是一种用来和数据库交互的语言文本。

SQL注入的攻击原理就是攻击者通过Web应用程序利用SQL语句或字符串将非法的数据插入到服务器端数据库中，获取数据库的管理用户权限，然后将数据库管理用户权限提升至操作系统管理用户权限，控制服务器操作系统，获取重要信息及机密文件。

SQL注入利用的是正常的HTTP服务端口，表面上看来和正常的web访问没有区别，隐蔽性极强，不易被发现。

SQL注入过程

如上图所示，SQL注入攻击过程分为五个步骤：

第一步：

判断Web环境是否可以SQL注入。

如果URL仅是对网页的访问，不存在SQL注入问题，如：

就是普通的网页访问。

只有对数据库进行动态查询的业务才可能存在SQL注入，如：

＝39，其中?

id＝39表示数据库查询变量，这种语句会在数据库中执行，因此可能会给数据库带来威胁。

第二步：

寻找SQL注入点。

完成上一步的片断后，就要寻找可利用的注入漏洞，通过输入一些特殊语句，可以根据浏览器返回信息，判断数据库类型，从而构建数据库查询语句找到注入点。

第三步：

猜解用户名和密码。

数据库中存放的表名、字段名都是有规律可言的。

通过构建特殊数据库语句在数据库中依次查找表名、字段名、用户名和密码的长度，以及内容。

这个猜测过程可以通过网上大量注入工具快速实现，并借助破解网站轻易破译用户密码。

第四步：

寻找WEB管理后台入口。

通常WEB后台管理的界面不面向普通用户

开放，要寻找到后台的登陆路径，可以利用扫描工具快速搜索到可能的登陆地址，依次进行尝试，就可以试出管理台的入口地址。

第五步：

入侵和破坏。

成功登陆后台管理后，接下来就可以任意进行破坏行为，如篡改网页、上传木马、修改、泄漏用户信息等，并进一步入侵数据库服务器。

2.1.2SQL注入漏洞防范措施

SQL注入漏洞攻击的防范方法有很多种，现阶段总结起来有以下方法：

（1）数据有效性校验

如果一个输入框只可能包括数字，那么要通过校验确保用户输入的都是数字。

如果可以接受字母，那就要检查是不是存在不可接受的字符，最好的方法是增加字符复杂度自动验证功能。

确保应用程序要检查以下字符：

分号、等号、破折号、括号以及SQL关键字。

另外限制表单数据输入和查询字符串输入的长度也是一个好方法。

如果用户的登录名最多只有10个字符，那么不要认可表单中输入10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。

（2）封装数据信息

对客户端提交的数据进行封装，不要将数据直接存入cookie中，方法就是在编程的代码中，插入session、if、try、else，这样可以有效地防止攻击者获取cookie中的重要信息。

?

（3）去除代码中的敏感信息

将在代码中存在的用户名、口令信息等敏感字段删除，替换成输入框。

如：

SQL="selectfromuserswhereusername=’admin’andpassword=’1234567’"这样显然会暴露管理员的用户名、口令信息。

可以将其修改成SQL="select*fromuserswhereusername='"+Txtuser.Text+"'anduserpwd='"+Textpwd.Text+"'"，这样就安全了很多，入侵者也是不会轻易的就获取到用户名、口令信息。

（4）替换或删除单引号

使用双引号替换掉所有用户输入的单引号，这个简单的预防措施将在很大程度上预防SQL注入漏洞攻击，单引号时常会无法约束插入数据的Value，可能给予输入者不必要的权限。

用双引号替换掉单引号可以使大部分SQL注入漏洞攻击失败。

如：

“select*fromuserswhereusername='"+admin+"'anduserpwd='"+1234567+"'”显然会得到与“select*fromuserswhereusername='admin'andpassword='1234567'”相同的结果。

（5）指定错误返回页面

攻击者有时从客户端尝试提交有害代码和攻击字符串，根据WebService给出的错误提示信息来收集程序及服务器的信息，从而获取想得到的资料。

应在WebService中指定一个不包含任何信息的错误提示页面。

（6）限制SQL字符串连接的配置文件

使用SQL变量，因为变量不是可以执行的脚本，即在Web页面中将连接数据库的SQL字符串替换成指定的Value，然后将Web.config文件进行加密，拒绝访问。

?

（7）设置Web目录的访问权限

将虚拟站点的文件目录禁止游客用户（如：

Guest用户等）访问，将User用户权限修改成只读权限，切勿将管理权限的用户添加到访问列表。

（8）最小服务原则

Web服务器应以最小权限进行配置，只提供Web服务，这样可以有效地阻止系统的危险命令，如ftp、cmd、vbscript等。

?

（9）鉴别信息加密存储

将保存在数据库users表中的用户名、口令信息以密文形式保存，也可以对users表进行加密处理，这样可以大大增加对鉴别信息访问的安全级别。

（10）用户权限分离

应尽可能的禁止或删除数据库中sa权限用户的访问，对不同的数据库划分不同的用户权限，这样不同的用户只能对授权给自己的数据库执行查询、插入、更新、删除操作，就可以防止不同用户对非授权的数据库进行访问。

?

2.1.3SQL注入漏洞检测方法

SQL注入漏洞攻击检测分为入侵前的检测和入侵后的检测。

入侵前的检测，可以通过手工方式，也可以使用SQL注入漏洞扫描工具软件。

检测的目的是为预防SQL注入漏洞攻击，而对于SQL注入漏洞攻击后的检测，主要是针对审计日志的查看，SQL注入漏洞攻击成功后，会在WebService和数据库的审计日志中留下“痕迹”。

检测方法如下：

（1）动态SQL检查

动态的SQL语句是一个进行数据库查询的强大的工具，但把它和用户输入混合在一起就使SQL注入成为了可能。

将动态的SQL语句替换成预编译的SQL或者存储过程对大多数应用程序是可行的。

预编译的SQL或者存储过程可以将用户的输入作为参数而不是命令来执行，这样就限制了入侵者的行动。

当然，它不适用于存储过程中利用用户输入来生成SQL命令的情况。

在这种情况下，用户输入的SQL命令仍可能得到执行，数据库仍然存在SQL注入漏洞攻击的危险。

（2）有效性校验?

如果一个输入框只可能包括数字，那么要通过验证确保用户输入的都是数字。

如果可以接受字母，检查是不是存在不可接受的字符，那就需要设置字符串检查功能。

确保应用程序要检查以下字符：

分号、等号、破折号、括号以及SQL关键字。

（3）数据表检查?

使用SQL注入漏洞攻击工具软件进行SQL注入漏洞攻击后，都会在数据库中生成一些临时表。

通过查看数据库中最近新建的表的结构和内容，可以判断是否曾经发生过SQL注入漏洞攻击。

（4）审计日志检查

在Web服务器中如果启用了审计日志功能，则WebService审计日志会记录访问者的IP地址、访问时间、访问文件等信息，SQL注入漏洞攻击往往会大量访问某一个页面文件（存在SQL注入点的动态网页），审计日志文件会急剧增加，通过查看审计日志文件的大小以及审计日志文件中的内容，可以判断是否发生过SQL注入漏洞攻击事件；另外还可以通过查看数据库审计日志，查询某个时间段是否有非法的插入、修改、删除操作。

（5）其他?

SQL注入漏洞攻击成功后，入侵者往往会添加特权用户（如：

administrator、root、sa等）、开放非法的远程服务以及安装木马后门程序等，可以通过查看用户帐户列表、远程服务开启情况、系统最近日期产生的一些文件等信息来判断是否发生过入侵。

?

SQL注入攻击源于英文“SQLInjectionAttack”。

微软技术中心从两个方面对SQL注入攻击进行了描述：

一是脚本注入式的攻击；二是恶意用户输入用来影响被执行的SQL脚本。

StephenKost对这种攻击形式的描述是“从一个数据库获得XX的访问和直接检索”。

SQL注入就其本质而言，是利用SQL语法，对应用程序中的漏洞的攻击。

当攻击者能够操纵数据，在应用程序中插入一些SQL语句时，SQL注入攻击就发生了。

理论上，这种攻击对于所有基于SQL语言标准的数据库软件都是有效的，包括MSSQLServer，Oracle，DB2，Sybase，MySQL等。

特别是现在一些AQL注入攻击工具的出现，使得Web应用更易遭到SQL注入攻击。

原始的手工测试不适用于大型Web应用程序，可使用N-Stealth、WebInspect、WiktoWebScarab、Nikto等工具进行扫描，测试系统是否存在SQL注入的安全漏洞。

为防止SQL注入，程序员编写代码时，要对客户端和服务端进行两级检查。

检查数据类型、数据长度和敏感字符的合法性。

客户端检查可减少网络流量，降低服务器负荷，将一般误操作、低等级攻击与高等级攻击行为区分开来。

对于绕开客户端检查的攻击，提交的数据被直接发往服务端，服务端检查到的提交异常基本可以认定为恶意攻击行为所致，就应中止提交信息的处理，进行攻击备案，并对客户端给出出错或警告提示。

另外，在构造查询时，应根据用户输入的内容设置参数值来创建参数化查询，从而避免SQL注入及由此带来的安全问题。

2.2表单漏洞测试

2.2.1表单漏洞实现原理

表单提交是当前Web应用中的重要内容，用户可以通过这种方式与服务器进行数据传递。

在通常情况下，会在提交表单之前在服务器上进行表单数据的验证，这样可以节省服务器资源，但同时也为服务器带来了安全漏洞。

表单提交的数据的验证和服务端数据接收的方法直接影响到Web的安全。

随着大量的支持参数的“模糊化”（“fuzzing”）、腐朽（corruption）、以及野蛮强制增长工具的出现，使用非校验输入进行攻击造成的安全问题越来越多。

因此，表单漏洞测试是Web安全所必需的。

2.2.2表单漏洞防范措施

为防止表单漏洞的攻击，编程时应有一个中心化的、强大的验证机制来对所有HTTP请求的输入进行验证，过滤可能危及后台数据库的特殊字符、脚本语言和命令。

为防止攻击者绕过客户端的安全机制，对这些字符的检测应在Web服务端实现，采用清除或者强制替换的方法避免服务器端的安全，并且使用MD5哈希（hash）函数或者时间戳数字签名技术对客户端敏感数据必须进行完整性保护。

解决这种漏洞的方法为在提交表单页面进行校验的同时，在接收表单的处理页面也进行校验，这样即使用户使用非法方式提交的非法数据通过了页面验证也无法通过服务器上的验证。

2.2.3表单漏洞检测方法

⑴表单数据提交测试。

●对表单数据提交的测试，主要检查程序中是否对表单所提交数据的完整性、正确性进行了验证（如果在页面部分进行验证的话），如：

查询条件输入一些特殊字符，比如“--”，“‘，，’”，““”等会使查询的SQL语句出错

●检查程序中是否屏蔽了表单提交的html语句、VBScript和Jscript等客户端脚本语句

●检查是否会出现“脚本利用”问题

●检查程序是否对表单域长度进行了真正的限制

●检查是否存在重复提交数据的问题

●检查这些验证是否在服务器端进行

对表单提交数据的测试，可以采用手工和编写可重复使用的脚本代码相结合的方法，进行边界值测试、等价类测试，以及异常类测试。

编写的脚本代码可以在测试、回归测试时运行。

若在测试中发现数据完整性、正确性验证只是在客户端进行，应在服务器端增加对表单提交数据的验证，防止出现本地提交表单的漏洞。

⑵本地提交表单的漏洞测试。

本地提交表单的漏洞容易受到参数篡改的攻击。

这类测试可用手工的方式进行。

对于如下用户注册页面：

1.?

21.

action="regist.php"?

method="POST">?

22.

type="text"?

name="userName"?

onblur="checkUser（）"/>?

23.

type="password"?

name="password"?

onblur="checkPsw（）"/>?

24.

type="submit"?

name="button"?

value="提交"/>?

25.

此页面中的JavaScript对表单中用户名和密码是否为空进行了判断，如果用户名或密码有一者为空时就会将"提交"按钮设置为不可用，这样可以阻止用户的提交。

但是这个页面的内容可以完全通过查看页面源代码的方式看到，用户可以通过查看源代码的方式将其中的JavaScript部分去掉，同时将表单action请求指向此页面原来的地址，然后将修改后的页面保存为一个静态HTML页面，这样就可以完成一个非法的数据提交。

修改之后的页面代码如下：

1.

action=?

method="POST">?

2.

type="text"?

name="userName"?

onblur="checkUser（）"/>?

3.

type="password"?

name="password"?

onblur="checkPsw（）"/>?

4.

type="submit"?

name="button"?

value="提交"/>?

5.?

如此一个页面，完全允许用户提交任何一种数据，包括空的用户名和密码。

2.3Cookie欺骗漏洞测试

2.3.1Cookie欺骗实现原理

Cookie最先是由Netscape（网景）公司提出的，Netscape官方文档中对Cookie的定义是这样的：

Cookie是在HTTP协议下，服务器或脚本可以维护客户工作站上信息的一种方式。

Cookie的用途非常广泛，在网络中经常可以见到Cookie的身影。

它通常被用来辨别用户身份、进行session跟踪，最典型的应用就是保存用户的账号和密码用来自动登录网站和电子商务网站中的“购物车”。

Cookie注入简单来说就是利用Cookie而发起的注入攻击。

从本质上来讲，Cookie注入与传统的SQL注入并无不同，两者都是针对数据库的注入，只是表现形式上略有不同罢了。

2.3.2Cookie欺骗防范措施

（1）删除Cookie记录

在IE浏览器【工具】✍【Internet选项】中删除Cookie，也可借助相应安全软件来实现。

（2）更改Cookie文件的保存位置

在【Internet选项】对话框中单击【设置】按钮，在设置页面单击【移动文件夹】出现如下图，在其中设置相应保存位置（如F:

\），即可成功更改Cookie文件的保存位置。

（3）添加防注入代码

2.3.3Cookie欺骗监测方法

如果系统使用了cookie，就要对cookie的使用情况进行检测。

检查Cookies在生存期内能否正常工作而且对这些信息是否加密，是否按预定的时间进行保存，是否存在cookie可被伪造提交的问题，刷新对Cookie有什么影响及过期处理等。

2.4用户身份验证测试

2.4.1用户身份验证漏洞防范措施

●限制用户名、密码最大字符数、字符类型

●限制登录次数，超出允许次数后给出友好提示

●限制用户权限

用户身份验证，客户端提交的密码需加密，服务端验证密码使用MD5，若在测试中发现问题，应及时修改代码，使用加密码算法对密码加密。

2.4.2用户身份验证检测方法

●测试有效和无效的用户名和密码，测试是否大小写敏感，是否有最大字符数的限制规则等。

●测试重试次数的限制，如果登录失败的次数超过允许值，应用程序将会做出何种反应（譬如拒绝此IP地址在短时间内的登录）。

●测试是否可以利用历史登录信息或以前的URL来绕开登录程序。

●测试执行添加、删除、修改等动作中是否需要登录操作，退出系统之后的操作是否仍可继续等。

●测试用户密码是否符合指定要求（字符、长度），如果不符合，对有什么影响，新用户自己修改密码后，创建时分配的密码是否会失效。

●测试用户账户过期后，是否完全、正确的删除其信息或使其失效。

●是否存在不验证而直接进入Web应用系统的问题，是否存在不登录就可查看非会员页面和权限问题。

用户身份验证测试一般使用手工和测试工具相结法的方法，若在测试中发现问题，应及时修改代码，使用加密码算法对密码加密，采用Session对象进行登录验证。

2.5文件操作漏洞测试

2.5.1文件操作漏洞实现原理

上存漏洞常见有，文件名检测漏洞，还有就是文件格式检查漏洞。

另外还有一个，就是保存文件存在漏洞。

这类漏洞，主要是可以读取用户传入路径名称，采用不正确的过滤方法，导致恶意用户，将文件上存到非预期的地方，带来安全隐患。

2.5.2文件操作漏洞防范措施

抓住几个地方即可，先来分析下，既然用户要上存文件，而且文件将是多种多样格式；可能有的文件内容与用户传入格式不一致，有的文件内容还夹杂木马代码。

那么，我们让用户上存文件，跟站点文件做一个分别授权，做隔离。

●让保存上存目录独立开来，目录权限只读不能执行

这一步从系统设计加以授权，无论你上次什么文件，都不可能执行到。

就算我不做任何检测，你的文件都上存到这里了，也不会对我系统构成安全。

（如果有用户上存一些反动言语的图片，那另外需要处理的）

●不直接使用服务器传入值，所有都要进行检测

这类跟我们做一切输入都是有害原则一样，对于客户端传入的：

type,name，都要进行判