软件测试10 渗透性测试及验收测试

渗透性测试及验收测试

知识回顾

Web UI自动化测试

引入自动化测试需要满足的条件
自动化测试流程简述
自动化测试的关键技术
Selenium页面元素定位方式

目标

了解安全测试的概念
了解常见的安全漏洞
了解安全测试流程及测试工具的使用
理解验收测试的概念
掌握Alpha测试和Beta测试方法

重点/难点

重点：常见的安全测试漏洞；Alpha测试和Beta测试方法
难点：常见安全漏洞的攻击原理；Alpha测试和Beta测试方法

安全测试概述

什么是安全测试？

安全测试是在IT软件产品的生命周期中，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。
安全测试贯穿于软件的整个生命周期。

安全测试与常规测试的区别

测试目标不同：普通测试以发现Bug为目标；安全测试以发现安全隐患为目标。
假设条件不同：普通测试假设数据是用户不小心造成的；安全测试假设数据是攻击者构造的。
思考域不同：普通测试关注系统功能；安全测试包括系统功能、机制、外部环境等。
问题发现模式不同：普通测试基于功能违反；安全测试基于权限与能力违反。

常见安全漏洞

SQL注入漏洞

SQL注入是Web层最高危的漏洞之一，由输入未过滤导致。
数据库注入漏洞，主要是开发人员在构建代码时，没有对输入边界进行过滤或者过滤不足，使得攻击者可以通过合法的输入点提交一些精心构造的语句来欺骗后台数据库执行，导致数据库信息泄露的一种漏洞。
应用程序的登录模块，程序需要获取前端所输入的账号和密码，拼接SQL语句在数据库中进行查询，登录查询代码如下：

当输入正确的用户名test和密码123456后，程序会构建一个包含SQL语句的字符串sql，代码如下：

在这里插入图片描述
最终提交给数据库服务器运行的SQL语句如下：

如果存在此用户并且密码正确，数据库将返回记录数≥1，则用户认证通过，登录成功。
如果使用一个如下所示的比较特殊的用户账号信息来登录，在输入用户名和密码后单击“登录”按钮，也可以正常登录
在这里插入图片描述

但是，数据库中只有test用户，根本没有haha’or 1=1–用户，那为什么这个非法用户可以登录成功呢？
当输入特殊用户名haha’or 1=1–时，最终构成的命令如下：

最终提交给数据库服务器运行的SQL语句如下：
select count(*) from users where name= ‘haha’ or 1=1 – 'and password = ‘123456’
SQL中–符号是注释符号，其后的内容均为注释，即命令中–符号后的’and password = '123456’均为注释，那么password的值在查询时也根本起不了任何作用。而where后的name= ‘haha’ or 1=1这条语句永远为真，所以最终执行的SQL语句相当于：
在这里插入图片描述

SQL注入漏洞会带来以下几种常见的后果：

信息泄漏
– 注入SECLECT语句。
篡改数据
– 注入INSERT语句。
– 注入UPDATE语句。
– 注入ALTER USER语句。
– 注入ALERT TABLE语句。
特权提升
– 注入EXEC语句。
破坏系统
– 注入DELETE语句。
– 注入DROP TABLE语句。
– 注入SHUTDOWN语句。

SQL注入漏洞攻击流程

寻找注入点
– 手工方式：手工构造SQL语句进行注入点发现。
– 自动方式：使用Web漏洞扫描工具，自动进行注入点发现。
信息获取
– 环境信息：数据库类型、版本、操作系统版本、用户信息等。
– 数据库信息：数据库名称、数据库表、表字段、字段内容等。
获取权限
– 获取操作系统权限：通过数据库执行shell，上传木马。

注入点类型

数字型注入：当输入的参数为整型时，如ID、年龄、页码等，如果存在注入漏洞则可以认为是数字型注入。数字型注入是最简单的一种注入。
字符型注入：当输入参数为字符串时，如果存在注入漏洞则称为字符型注入。字符串类型一般要使用单引号来闭合。例如：
字符型注入：select * from table where username=‘admin’
字符型注入最关键的是如何闭合SQL语句以及注释多余的代码。下面以select查询命令和update更新命令为例说明。

SQL注入的防范措施

数据库部分：不允许直接拼接SQL语句，使用参数化查询等。
– 不允许在代码中出现直接拼接SQL语句的情况。
– 存储过程中不允许出现：exec、exec sp_executesql。
– 使用参数化查询的方式来创建SQL语句。
– 对参数进行关键字过滤，如表所示。
– 对关键字进行转义。
前端页面部分：限定输入长度和类型。
在代码审查中查找SQL注入漏洞：代码审查时，注意查找程序代码中的SQL注入漏洞

XSS跨站脚本漏洞

XSS原理解析

JavaScript可用来获取用户Cookie、改变网页内容等。存在XSS漏洞的网站，就可能会被盗取用户Cookie,、黑掉页面、导航到恶意网站等，而攻击者需要做的仅仅是利用网页开发时留下的漏洞，通过巧妙的方法向Web页面中注入恶意JavaScript代码。

下面是一段简单的XSS漏洞实例，其代码功能是接收用户在Index.html页面中提交的数据，再将数据显示在PrintStr页面。
Index.html 页面代码如：

PrintStr页面代码如下：

当攻击者输入

XSS类型

反射型XSS：非持久性，服务器处理后反射回浏览器。当用户访问一个带有XSS代码的URL请求时,服务器端接收数据后处理，然后把带有XSS代码的数据发送到浏览器，浏览器解析这段带有XSS代码的数据后，最终造成XSS漏洞。
– 下面举例说明反射型XSS跨站漏洞。

在这段代码中，程序先接收username值再将其输出，如果恶意用户输入username = ，将会造成反射型XSS漏洞。

存储型XSS：持久性，XSS代码被服务器存储后响应给浏览器。允许用户存储数据的Web应用程序都可能会出现存储型XSS漏洞，当攻击者提交一段XSS代码后，被服务器端接收并存储。当攻击者再次访问某个页面时,这段XSS代码被程序读出来响应给浏览器，造成XSS跨站攻击，这种攻击就是存储型XSS。
– 在测试是否存在XSS时，首先要确定输入点与输出点，例如，若要在留言内容上测试XSS漏洞，首先就要去寻找留言内容输出（显示）的地方是在标签内还是在标签属性内，或者在其他什么地方，如果输出的数据在标签属性内，那么XSS代码是不会被执行的。如：

JavaScript代码虽然成功地插入到了HTML中，但却无法执行，因为XSS代码出现在Value属性中，被当作值来处理，最终浏览器解析HTML时，将会把数据以文本的形式输出在网页中。
确定了输出点之后，就可以根据相应的标签构造HTML代码来闭合。插入下面的XSS代码到上面的代码中：

最终在HTML文档中代码变为：

DOM型XSS：是一种跨站脚本攻击，它与反射型和存储型XSS不同，因为它的XSS代码不是由服务器发送给浏览器，而是浏览器自身在处理页面时，由于JavaScript代码的不当操作导致恶意脚本执行。

DOM型XSS的特点：

基于文档对象模型（DOM）：攻击者利用DOM结构中的漏洞，通过JavaScript动态修改页面内容。
不需要服务器参与：与反射型和存储型XSS不同，DOM型XSS的恶意脚本是在客户端浏览器执行，不需要服务器的参与。
攻击隐蔽性高：由于攻击代码是在客户端执行，因此很难被服务器端的安全措施检测到。

DOM型XSS的攻击流程：

寻找DOM操作点：攻击者寻找页面中通过JavaScript动态生成内容的地方。
构造恶意输入：攻击者构造特殊的输入，这些输入在页面的DOM处理过程中被错误地作为代码执行。
触发执行：当页面处理这些输入时，恶意的JavaScript代码被执行。

防范措施：

对输入进行严格的验证和过滤：确保所有用户输入都被当作不可信数据处理，进行适当的HTML编码或JavaScript转义。
使用HTTP头部内容策略：通过设置HTTP头部的Content-Security-Policy，限制可以执行的脚本源。
最小化DOM操作：减少直接操作DOM的JavaScript代码，使用更安全的框架或库来处理DOM。
使用安全的API：避免使用可能引起安全问题的API，如innerHTML，改用textContent或创建元素的方式。
对输出进行编码：在将数据插入到DOM之前，对数据进行HTML编码，防止脚本被执行。

查找XSS漏洞的过程

找到输入点。比如查询接口、留言板等。
输入“唯一”字符，定位源码。
结合语法构造script，闭合HTML标签。
提交script，验证执行情况。如果成功执行则说明存在XSS漏洞。

XSS过滤方法

XSS跨站漏洞最终形成的原因是对输入与输出没有严格过滤、在页面执行Java Script等客户端脚本，如果要防御XSS就意味着只要将敏感字符过滤，即可修补XSS跨站漏洞。
通用处理：检查过滤输入内容，对存在跨站漏洞的页面参数的输入内容进行检查、过滤。例如对 [ %!~@#$^*()=|{}\<>/? ]等符号的输入进行检查过滤，对输出进行编码。
使用XSS防护框架：如ESAPI、ANTIXSS。

渗透测试

原理

渗透测试是利用模拟黑客攻击的方式，评估计算机网络系统安全性能的一种方法。这个过程是站在攻击者角度对系统的任何弱点、技术缺陷或漏洞的主动分析，并且有条件地主动利用安全漏洞。

渗透测试特点

渐进深入的过程。
选择不影响业务系统的攻击方法。

渗透测试流程

在这里插入图片描述

验收测试

验收测试的概念

部署软件前最后一个测试操作，确保软件准备就绪。，并且可以让最终用户将其用于执行软件的既定功能和任务。

验收测试的常用策略

正式验收测试
Alpha测试（非正式验收测试）
Beta测试

验收测试的类别

用户验收测试：确认应用满足业务需求。，并在将软件正式交付给最终用户之前，确保系统正常工作并可以使用。
操作验收测试：确认应用满足操作需求。并确保系统正式工作并可以使用。操作验收测试在测试组的协助下由一个或多个操作代表执行的。
两者不同之处——操作验收测试是用于验证被测应用在操作和管理方面的情况（例如更新后的被测应用的安装，对被测应用极其数据的备份、归档和恢复以及注册新用户并为其分配权限）。

正式验收测试

管理严格的过程，系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应当是系统测试中所执行测试用例的子集，并且不应当偏离所选择的测试用例方向。
正式验收测试主要有两种方式：
（1）在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。
（2）在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。