目录
什么是安全测试
安全测试与常规测试的区别
SQL注入漏洞
SQL注入漏洞会带来以下几种常见的后果：
SQL注入漏洞攻击流程
注入点类型
SQL注入的防范措施
XSS跨站脚本漏洞
XSS原理解析
XSS类型
1、反射型XSS
2、存储型XSS
3、存储型XSS
查找XSS漏洞的过程：
渗透测试
渗透测试的流程
验收测试
验收测试的常用策略
验收测试的类别
正式验收测试
正式验收测试主要有两种方式：
验收测试的过程
Alpha测试与Beta测试
Beta测试的前提条件
什么是安全测试
安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。
安全测试贯穿于软件的整个生命周期。
安全测试与常规测试的区别
（1）测试目标不同
普通测试以发现Bug为目标；
安全测试以发现安全隐患为目标。
（2）假设条件不同
普通测试假设导致问题的数据是用户不小心造成的，接口一般只考虑用户界面；
安全测试假设导致问题的数据是攻击者处心积虑构造的，需要考虑所有可能的攻击途径。
（3）思考域不同
普通测试以系统所具有的功能为思考域；
安全测试的思考域不但包括系统的功能，还有系统的机制、外部环境、应用与数据自身安全风险与安全属性等。
（4）问题发现模式不同
普通测试以违反功能定义为判断依据；
安全测试以违反权限与能力的约束为判断依据。
SQL注入漏洞
SQL注入漏洞（SQL injection）是Web层最高危的漏洞之一。 数据库注入漏洞，主要是开发人员在构建代码时，没有对输入边界进行过滤或者过滤不足，使得攻击者可以通过合法的输入点提交一些精心构造的语句来欺骗后台数据库执行，导致数据库信息泄露的一种漏洞。
例子：
应用程序的登录模块，程序需要获取前端所输入的账号和密码，拼接SQL语句在数据库中进行查询，登录查询代码如下：
当输入正确的用户名test和密码123456后，程序会构建一个包含SQL语句的字符串sql，代码如下：
最终提交给数据库服务器运行的SQL语句如下：
如果存在此用户并且密码正确，数据库将返回记录数≥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注入漏洞会带来以下几种常见的后果：
1.信息泄漏
注入SECLECT语句。
2.篡改数据
- 注入INSERT语句。
- 注入UPDATE语句。
- 注入ALTER USER语句。
- 注入ALERT TABLE语句。
3.特权提升
注入EXEC语句。
4.破坏系统
- 注入DELETE语句。
- 注入DROP TABLE语句。
- 注入SHUTDOWN语句。
SQL注入漏洞攻击流程
可以通过下面的流程来对SQL注入漏洞进行攻击：
1.寻找注入点
手工方式：手工构造SQL语句进行注入点发现。
自动方式：使用Web漏洞扫描工具，自动进行注入点发现。
2.信息获取
环境信息：数据库类型、版本、操作系统版本、用户信息等。
数据库信息：数据库名称、数据库表、表字段、字段内容等。
3.获取权限
获取操作系统权限：通过数据库执行shell，上传木马。
注入点类型
1.数字型注入
当输入的参数为整型时，如ID、年龄、页码等，如果存在注入漏洞则可以认为是数字型注入。数字型注入是最简单的一种注入。
2.字符型注入
当输入参数为字符串时，如果存在注入漏洞则称为字符型注入。字符串类型一般要使用单引号来闭合。例如：
字符型注入：
select * from table where username='admin'字符型注入最关键的是如何闭合SQL语句以及注释多余的代码。下面以select查询命令和update更新命令为例说明。
SQL注入的防范措施
SQL注入攻击的风险最终落脚于用户可以控制输入，SQL注入、XSS、文件包含、命令执行等风险都可归于此。
1.前端页面部分
- 限定输入长度；
- 限定输入类型；
2.数据库部分
- 不允许在代码中出现直接拼接SQL语句的情况。
- 存储过程中不允许出现：exec、exec sp_executesql。
- 使用参数化查询的方式来创建SQL语句。
- 对参数进行关键字过滤，如表所示。
- 对关键字进行转义。
3.在代码审查中查找SQL注入漏洞
代码审查时，注意查找程序代码中的SQL注入漏洞
XSS跨站脚本漏洞
XSS原理解析
JavaScript可以用来获取用户的Cookie 、改变网页内容、URL调转等，存在XSS漏洞的网站，就可能会被盗取用户Cookie,、黑掉页面、导航到恶意网站等，而攻击者需要做的仅仅是利用网页开发时留下的漏洞，通过巧妙的方法向Web页面中注入恶意JavaScript代码。
下面是一段简单的XSS漏洞实例，其代码功能是接收用户在Index.html页面中提交的数据，再将数据显示在PrintStr页面。
Index.html 页面代码如：
PrintStr页面代码如下：
当攻击者输入<script>alert(xss/)</scrip>时，将触发XSS攻击。
XSS类型
XSS主要被分为三类，分别是：反射型、存储型和DOM型。
1、反射型XSS
反射型XSS也被称为非持久性XSS。当用户访问一个带有XSS代码的URL请求时,服务器端接收数据后处理，然后把带有XSS代码的数据发送到浏览器，浏览器解析这段带有XSS代码的数据后，最终造成XSS漏洞。这个过程就像一 次反射，故称为反射型XSS。
例子：
在这段代码中，程序先接收username值再将其输出，如果恶意用户输入username = <script>alert('xss')</script>，将会造成反射型XSS漏洞。
2、存储型XSS
存储型XSS又被称为持久性XSS，存储型XSS是最危险的一种跨站脚本。 允许用户存储数据的Web应用程序都可能会出现存储型XSS漏洞，当攻击者提交一段XSS代码后，被服务器端接收并存储。当攻击者再次访问某个页面时,这段XSS代码被程序读出来响应给浏览器，造成XSS跨站攻击，这种攻击就是存储型XSS。
示例：
在测试是否存在XSS时，首先要确定输入点与输出点，例如，若要在留言内容上测试XSS漏洞，首先就要去寻找留言内容输出（显示）的地方是在标签内还是在标签属性内，或者在其他什么地方，如果输出的数据在标签属性内，那么XSS代码是不会被执行的。如：
3、存储型XSS
JavaScript代码虽然成功地插入到了HTML中，但却无法执行，因为XSS代码出现在Value属性中，被当作值来处理，最终浏览器解析HTML时，将会把数据以文本的形式输出在网页中。
确定了输出点之后，就可以根据相应的标签构造HTML代码来闭合。插入下面的XSS代码到上面的代码中：
最终在HTML文档中代码变为：
查找XSS漏洞的过程：
（1）在目标站点上找到输入点，比如查询接口、留言板等。
（2）输入一个“唯一”字符，单击提交后，查看当前状态下的源码文件。
（3）通过搜索定位到唯一字符，结合唯一字符前后的语法构造script，并合理的对HTML标签进行闭合。
（4）提交构造的script，看是否可以成功执行，如果成功执行则说明存在XSS漏洞。
XSS跨站漏洞最终形成的原因是对输入与输出没有严格过滤、在页面执行JavaScript等客户端脚本，如果要防御XSS就意味着只要将敏感字符过滤,即可修补XSS跨站漏洞。
1.通用处理
（1）对存在跨站漏洞的页面参数的输入内容进行检查、过滤。例如对[ %!~@#$^*()=|{}\\<>/? ]等符号的输入进行检查过滤
（2）对页面输出进行编码
2.使用XSS防护框架
使用XSS防护框架，如：ESAPI、ANTIXSS。
渗透测试
渗透测试是利用模拟黑客攻击的方式，评估计算机网络系统安全性能的一种方法。这个过程是站在攻击者角度对系统的任何弱点、技术缺陷或漏洞的主动分析，并且有条件地主动利用安全漏洞。
渗透测试特点：
● 渗透测试是一个渐进的并且逐步深入的过程。
● 渗透测试是选择不影响业务系统正常运行的攻击方法进行的测试。
渗透测试的流程
验收测试
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试的常用策略
正式验收测试
Alpha测试(又称非正式验收测试)
Beta测试。
验收测试的类别
验收测试分为用户验收测试和操作验收测试。
- 用户验收测试的目标是确认被测应用能满足业务需求，并在将软件正式交付给最终用户之前，确保系统正常工作并可以使用。
- 操作验收测试的目标是确认被测应用满足其操作需求，并确保系统正式工作并可以使用。操作验收测试在测试组的协助下由一个或多个操作代表执行的。
- 用户验收测试与操作验收测试的不同之处在于，操作验收测试是用于验证被测应用在操作和管理方面的情况（例如更新后的被测应用的安装，对被测应用极其数据的备份、归档和恢复以及注册新用户并为其分配权限）。
正式验收测试
正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应当是系统测试中所执行测试用例的子集，并且不应当偏离所选择的测试用例方向。
正式验收测试主要有两种方式：
（1）在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。
（2）在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。
验收测试的过程
（1）软件需求分析：了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。
（2）编制《验收测试计划》和《项目验收准则》：根据软件需求和验收要求编制测试计划，制定所需测试的测试项，制定测试策略及验收通过准则，并由客户参与计划评审。
（3）测试设计和测试用例设计：根据《验收测试计划》和《项目验收准则》编写测试用例，并经过评审。
（4）测试环境搭建：建立测试的硬件环境、软件环境等。
（5）测试实施：测试并记录测试结果。
（6）测试结果分析：根据验收通过准则分析测试结果，给出验收是否通过和测试评价。
（7）测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客户。
Alpha测试与Beta测试
Alpha测试（非正式验收或 α 测试）是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。
经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。
Beta测试的前提条件
真正的β测试应具备三个条件。
- 目标市场：真正的β测试应该保证所有测试参与者都是目标市场的一部分，只有这样，才能对产品的质量、功能和设计进行客观地评价。
- 可使用的测试产品：在将产品分发给客户之前要进行产品可用性的评估。如果一个产品处于很难使用的状态，那么β测试除了证实该产品有问题外，就没有其他意义了。
- 要求测试结果:当公司把产品分发给客户时，就应该清楚客户会发表自己的意见和想法。公司必须要求获取这些信息。
=========================================================================
用到工具：
AppScan文章来源：https://www.toymoban.com/news/detail-463593.html
WebLinkValidator文章来源地址https://www.toymoban.com/news/detail-463593.html
到了这里，关于11、渗透性测试及验收测试的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
