安全测试

原本：http://www.infoq.com/cn/articles/to-test-colleagues-let-us-do-a-safety-test

安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。

安全测试和普通测试的相似性

简单来说，安全测试其实就是一个发现软件安全漏洞的过程，旨在保护软件系统的数据与功能。它跟常规测试相似的地方至少有以下几点：

No.	Summary	Details
1	目标类似	预防、检测系统的缺陷（尽早、频繁反馈系统质量信息）
2	在软件生命周期中的工作过程类似（以敏捷团队为例）	－了解系统业务需求－针对业务与系统功能设计用例－与其他角色一起启动需求的开发－与其他角色一起在开发环境验收需求－在测试环境进行全面测试－分析并总结测试结果－反馈测试结果
3	测试用例有很多重合	面向用户的测试场景非常类似
4	都需要有探索的过程	对会对不同的业务场景有目的的进行探索
5	都要有测试人员必备的“怀疑态度”	对开发人员的代码保持友好而警惕的态度

1. 目标类似

不管是常规测试还是安全测试，都有一个原则：预防胜于检测。这个比较容易理解，不管是常规测试的缺陷也好，还是安全测试的漏洞也好，如果能预防使它不发生，就省了后期的修复与验证工作。如果不能成功的预防缺陷，能早一些发现的话，肯定比晚发现的修复的成本低。

2. 在软件生命周期中的过程类似

以敏捷开发团队为例，常规测试人员在各个阶段的事情，安全测试人员也要做：

了解业务的需求，以避免混乱的测试优先级；
针对业务与系统功能设计用例：常规测试需要关注系统功能，安全测试同样也不能脱离系统功能；
与其他角色一起启动需求的开发：沟通测试用例，避免因为沟通不足造成返工；
与其他角色一起在开发环境验收需求：尽早提供反馈，发现缺陷了开发可以马上修正
在测试环境进行全面测试：针对端到端的场景进行测试，尽可能把第三方系统（如果有的话）也包括进来；
分析并总结测试结果：整理问题清单，排列优先级；
反馈测试结果：把测试结果反馈给团队等干系人。

3. 测试用例很多重合

在面向终端用户的测试场景上，常规测试的用例与安全测试的用例是非常类似的。比如对于登录系统的功能，不管是常规测试还是安全测试，我们都会测试用户输入正确的用户名是否可以登录，输入错误的用户名或密码是否系统会如何反应。
比如我曾经工作的一个搜集报税人信息的系统，不管是常规测试还是安全测试，常规测试会测试系统的登录，系统信息的录入与编辑，文件的上传等等，安全测试也会测试这些业务场景。
因为在每一个终端用户可以操作的场景上，都可能会有安全漏洞存在。所以，有了常规测试的经验，我们就相当于有了不少安全测试用例的储备。

4. 都需要有探索的过程

测试是一个了解软件系统是否完成我们预期的过程，也是探索系统还有哪些我们没有预期的行为的过程。安全测试的过程需要把探索的目标转向安全漏洞。当我们这么做时，我们同样会得到很多探索的乐趣。

5. 都要有测试人员必备的“怀疑态度”

相信咱们测试人员都非常熟悉一个场景－－开发人员说：“我只做了一个很小的代码改动。”然后我们带着友好而警惕的态度，发现这个“很小的改动”引发了很大的问题。不管是在安全测试还是非安全测试，这个警惕性是我们都需要保持的良好传统。
那么，有了这么多类似的地方，还缺什么呢？如果想要做专家，还差很多。但是如果想马上安全测试上起步，我们可以先做下面的改变。

安全测试的三步曲

第一，转换视角

在我看来，不管是带着全栈的经验，还是只有部分技术知识，想要做好安全测试必须先转换我们观察软件的视角。举个例子，让我们看看下这幅画：

同样一幅画，有人一眼看过去看到的是两个人脸，而有人看到的是一个花瓶。这就是观察的视角不同造成的。
在我刚开始接触安全测试时就很深的体会到了这一点。当时我在测试一个Web应用的用户登录功能。当我输入错误的用户名来试着登陆时，浏览器上的提示信息为“该用户名不存在”。当我尝试正确的用户名而错误的密码时，提示信息变成“密码输入错误。”对于这个清晰的错误提示我非常满意。试想我若是一个真实的终端用户，这个信息有效的帮助我缩小我所要纠错的范围，提高效率，非常好。
可是，就在我身边坐着的安全测试人员马上跳了出来：“这个提示信息需要改！敏感信息暴露了！”看着我一脸茫然，这位安全测试人员告诉我，通过我们的提示信息，恶意的系统使用者可以推测出哪些用户名已经存在于系统中，然后利用这些用户名可以再进行密码的暴力破解，缩小破解的范围。所以，这个信息虽然为合法用户提供了便利，也为不怀好意的系统使用者提供了便利。而往往这种便利为恶意的系统使用者带来的好处远大于给合法用户带来的好处。
这个经历让我受震动的同时，也意识到以前可能很多安全漏洞已经摆在我的面前，我却没有看出来，因为我把它们过滤了。事实证明，在后来经历的不同项目中，而当我转换了视角，有些安全漏洞不需要我去找，而是自己跑到我眼前来的。真是得来全不费功夫。

第二，改变测试中模拟的对象

为了能以不同的视角来观察软件，我们必须改变我们所模拟的对象。这也是一个让我们刻意练习转换视角的有效方法。
我们在做非安全测试的时候通常把自己想象成一个合法用户，然后开始验证系统是否能完成预设的目标。比如对于一个网上商城，我们会验证系统是否能让用户完成商品的浏览与购买，我们也会测试一些异常的行为，比如购买的商品数量不是数字而是一串无意义的字母时，目的是看系统是否能比较优雅的做出回应。我们这么测试的目的往往是为了确保用户误操作以后还能够继续他们的购买，或者说不要给系统造成什么严重的伤害。
如果要做安全测试，我们则必须去模拟系统的另一类使用者－恶意用户。他们的目的是为了寻找系统中可钻的漏洞。比如同样是一个网上商城，恶意用户的目标之一就是要想办法以较少的钱，甚至不付钱就能拿到商品。所以，如果恶意用户进行了“误操作”，他们不会停留在“误操作”，而是通过“误操作”来看系统是否给自己提供更多的线索。
所以，我们转换我们测试时所模拟的对象，把思维从一个合法用户的视角中拉出来，转换成一个恶意用户。这需要一点时间，就如同之前看到的画，如果我们一开始看到的是人脸，要想下一次第一眼看到的是花瓶，我们需要时间来刻意练习。

第三，使用专用的测试工具

有了思维的转换，我们可以加入新的测试想法。但是，在具体做安全测试的时候我们会发现并不是那么容易去模拟恶意用户的行为。毕竟系统的前端会给我们很多的屏障。而且恶意用户可不总都是从系统前门进去的。这时候，使用一些工具，比如OWASP Zap(https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project)、Burp(https://portswigger.net/burp/)等是非常有帮助的。我们可以在系统界面上执行功能测试的用例，用这些工具来获取http请求，篡改后发送给后台服务器。有了这些实用又比较容易上手的工具，我们就可以执行很多恶意用户的操作场景了。
能做到这三点，起步就基本够用了。

举个例子吧

下面让我们以网上商城的买家在商品评价中上传图片这个功能来讲讲如何实践这“三板斧”。假设我们从项目初期就加入了，那么我们大致有七件事情要做：

识别系统中有价值的数据；
在需求分析阶段加入恶意用户需求；
针对恶意用户需求设计测试用例；
参与启动恶意需求的开发；
在开发环境验收恶意需求的实现；
在测试环境中进行安全测试；
向团队反馈所发现的安全漏洞。

不要担心，这不是7个全新的事情。这只是在每个需要测试人员出现的地方增加了安全的工作而已。

1. 识别系统中有价值的数据

很多人认为执行测试才是测试，而我们的安全测试从这里就开始了。
了解了业务以后，我们需要考虑系统中会有什么有价值的数据。这是为下一步加入恶意用户需求做准备。对于一个网上商城，有价值的数据可以包括产品信息、订单信息、用户信息、支付，等等。
这个环节对我们测试人员来说并没有太多额外的工作，毕竟我们做非安全测试的时候也是需要了解业务。不过要注意了，我们要测试的“图片上传功能”是一个涉及有价值数据的功能。我们需要提高警惕了。

2. 在需求阶段加入恶意用户需求

恶意用户需求是用来记录恶意用户想要在系统中达到的目的。与普通用户需求的区别是，我们不是要去实现它，而是使用它帮来助我们远离对系统使用者“不恰当的信任”。通常我们需要针对每一个合法用户需求来增加一个或多个相对应的恶意用户需求。
举个例子，如果我们这个“图片上传功能”的合法用户需求为：
作为一个买家，我想在对商品进行评价的时候上传图片作为买家秀，以便于参加返现营销活动。
那么对应的恶意用户需求可以是：
作为一个恶意用户，我想破坏买家秀返现活动，以便破坏商城的营销活动。
“破坏买家秀返现活动”是一个大的目标。为了设计用例方便，它可以被细分为一系列小目标。比如：

让用户无法上传图片
让页面无法正确显示图片
等等

有了恶意用户需求的主干信息，我们就可以开始下一步设计安全测试用例了。

3. 针对“恶意用户需求”设计测试用例

现在我们需要做的是努力把自己限制在“恶意用户”的角度做头脑风暴：“到底有什么方法可以使买家无法上传图片信息呢？”， “让页面无法正确显示买家秀图片又怎么做到？”嗯，也许最直接的办法就是让服务器所在的机房断电、断网之类的。这是些不错的想法，虽然执行难度有点大。没关系，记录下来。除此之外，我们还可以有其他测试用例，比如：

使存储图片的磁盘空间被占满而无法接受新的图片；
使处理上传图片的进程繁忙而无法接受新的上传任务；
上传特别大的图片使用户的客户端需要很长时间才能下载完
上传伪装成图片的恶意代码，进一步获取服务器权限，删除所有的买家秀图片；
等等

如果这个时候想到新的测试用例也同样记录下来，比如“我想不购买也上传买家秀图片以获得返现”之类的。
不用太担心这个阶段的测试用例过于“疯狂”或者不够完整，毕竟我们对于系统的实现还不是很了解。我们会在接下来的环节中完善具体的步骤。

4. 参与启动恶意需求的开发（evil story kickoff）

在开发人员开始开发合法用户需求之前，我们需要跟业务分析人员、开发人员一起沟通需求的内容。在敏捷软件开发项目中我们叫它story kickoff，即用户故事启动。当有了对应的恶意用户需求时，我们必然也要把它也加到启动的范围里。目的是把我们头脑风暴出来的测试用例跟所有的角色来沟通。预防胜于检测。

5. 在开发环境验收恶意需求的实现

100%预防软件的缺陷与漏洞是不太可能的，所以这个环节的存在是为了提早反馈。
我曾经经历过一个项目，都快上线了才决定做安全测试，结果测出来的问题之一是用户会话（user session）不能正确过期的问题，经过一番研究，发现需要对系统设计的架构进行比较大的修改，只能做个临时的修复让系统先上线，然后再把系统的架构给改了，重写这部分功能，重新测试。代价非常高。所以不管是安全测试还是非安全测试，”在开发环境验收恶意需求的实现“这个步骤都不能缺少。
而这个环节存在的第二个目的是让我们可以从开发人员那里得到支持－具体实施的细节，帮助我们完善具体的测试用例。比如在这个时间点我们若从开发人员那里得知系统的后台没有对图片上传者做身份验证，我们就可以至少增加一个测试的用例：“恶意用户以其他用户的身份上传一个风马牛不相及的图片”。有时候错误的图片比没有图片更具有杀伤力。

6. 在测试环境中进行安全测试

终于到了运行测试的阶段。可能这个时候我们之前想到的测试用例已经被开发人员给解决。如果是这样那就太好了。但是，事实并非有这么美好。第一，可能这些用例只是在开发环境上成功通过了，但是在理想的测试环境里，也就是类产品环境里，这些用例可能并不能完全通过；第二，肯定还有其他需要探索的地方。这时我们就可以用OWASP Zap、Burp这样的工具来辅助我们把之前的安全测试用例执行一次，同时还再可以对系统的安全性做一下探索测试。

7. 向团队反馈所发现的安全漏洞

都测得差不多的时候，我们就可以向团队以及相关干系人汇报安全测试的结果了。跟非安全测试不同的地方是，当我们反馈安全漏洞的时候，要考虑是否不同漏洞结合起来会增加系统的安全风险。举个例子：如果有两个安全漏洞，一个是系统没有很强的用户账户密码规规则，另一个是系统没有对上传图片的大小做限制，那么恶意

用户把这两个漏洞一结合起来，事情就比原来风险大很多。那么我们就必须建议提高这两个漏洞中任意一个的优先级。

当我们用“三板斧”走完这七步以后，我们已经可以把很多安全漏洞都挖出来了。是不是没有想象中的难？所以，测试同仁们，让我们做安全测试吧！

第二部分

作者：Twosecurity
链接：https://www.zhihu.com/question/21606800/answer/219614097
来源：知乎
著作权归作者所有，转载请联系作者获得授权。

早期的互联网非常的单调，一般只有静态页面，现在，随着技术的发展，web上大多数站点实际上是web应用程序，在服务器和浏览器之间进行双向的信息传递。他们支持注册登录，金融交易，搜索及用户创作的内容。用户只需要拥有一个浏览器，就能实现各种功能。

Web 是指一个网站的前端页面到后端服务，比如我们常见的 Javascript、PHP、Python、Mysql、jQuery、Docker 等，包括开发、运维这些服务。

所以在我看来 Web 安全也就是从安全的角度探索 Web 的一种方式。

为了能够更简单的理解一些常见漏洞，我们首先来看一下这份试卷：

试卷 考生姓名：__________
考生学号：__________

一、诗歌补写
床前没月光，___________。
春眠不觉晓，___________。

二、数学运算（在括号内填入数字）
3 500 +400 * 3 / 2 + 1 = （）
4 ( 1 + 2) / 3 * 400 +500 = （）

考生姓名：__________

考生学号：__________

首先我们来看这个，试卷的名字和编号填写，这个部分有“漏洞”吗？有

学生的姓名和编号都写在这儿，没有做任何保护措施，因此，你只要偷看了某人的试卷上的这部分内容，然后把你的试卷的上的姓名和考生编码写成和他一样的即可伪装出他的身份。

漏洞攻击成功

一、诗歌补写
床前没月光，___________。
春眠不觉晓，___________。

这道题有漏洞吗？有

这道题的答案本来应该是“疑似地上霜”和“处处闻啼鸟”

But，问题中，并没有规定答案里不能添加标点符号，所以，我完全可以把“疑是地上霜，举头望明月，低头思故乡”以及“处处闻啼鸟，夜来风雨声，花落知多少”当做答案写进去。

漏洞再次进攻成功：P

二、数学运算（在括号内填入数字）

3 500 +400 * 3 / 2 + 1 = （）

4 ( 1 + 2) / 3 * 400 +500 = （）

这个问题有漏洞吗？有

出题者规定了只能填入数字，但却没有说是什么数字，也没有规定多少位，那么我的答案可以是
中文数字「壹佰壹拾圆」、罗马数字「MCI」或「0000000000001101」。

漏洞第三次进攻成功 XXD

这份试卷简单的模拟了Web漏洞的攻击思想，在实际中，我们打开一个网页提交登录或者是搜索都会经过服务器做的一系列处理又回到浏览器，在这个过程中我们提交的数据会被带入到一系列的填空题中，有的是我们能猜到的，有的则是意想不到的，有的会经过SQL查询进行填空，有的会被带入到命令行中进行执行，最后又把结果返回给浏览器进行填空，也就是最后我们看到的结果。

在数据的传输中，我们可以把 web 简单的分为几个层次：

浏览器：浏览器即客户端，提供客户端和服务器端的数据信息交互。
http：客户端与web服务器进行交互时就存在web请求，这种请求都基于统一的应用层协议——HTTP协议来交互数据。http属于轻量级协议，无需连接，提供了对通信错误的容错性。
中间件：中间件是位于平台（硬件和操作系统）和应用之间的通用服务
Server容器：Server容器负责解析用户请求和脚本语言，类似的有Tomcat，JBoss等。我们访问网页看到是web容器处理后的内容。
数据库：动态页面可提供交互式的信息查询服务，主要依赖于web数据库的实现，对外提供包含表单的Web页面作为访问接口，查询结果也以包含数据列表的Web页面形式返回给用户。

当然除了这些数据也有可能流向不些不可见的第三方服务商。

下图就展示了数据的传输流程，以及不同阶段经常出现的漏洞及其原因:

我们常见的Web漏洞类型主要有SQL注入、XSS、远程命令执行以及越权等。以下我们分别用举例的形式为大家介绍这几种漏洞。

（SQL注入）

所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

select * from username = ____ and password=_____
select * from username "test" or ""="" and password="123456"

（XSS）

XSS则是攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。

<p style='color:red'>你好啊，尊敬的______<p>
<p style='color:red'>你好啊，尊敬的 xxx<script>alert(1)</script><p>

(远程命令执行)

而远程命令执行，是用户通过浏览器提交执行命令，由于服务器端没有针对执行函数做过滤，导致执行命令。

ping _______
ping www.baidu.com & wget xxxxxxxxxxx

（越权）

越权漏洞是比较常见的漏洞类型，越权漏洞可以理解为，一个正常的用户A通常只能够对自己的一些信息进行增删改查，但是由于程序员的一时疏忽，对信息进行增删改查的时候没有进行一个判断，判断所需要操作的信息是否属于对应的用户，可以导致用户A可以操作其他人的信息。

Cookie: uid=11426;
Cookie: uid=1;

关于越权，就像我们刚刚试卷体中的姓名部分。

再展示一个数据的传输流程图，以便直观清晰的看到，数据在各层中是怎样运作的，以及可能发生的漏洞：

了解了这几个漏洞之后我们可以看到原理都有些类似，也很简单，当然我们只要不再局限于概念名词就会发现 web 安全的大部分漏洞都很简单。更多时候，发现一个复杂的漏洞需要是只是耐心。

概念，不是一个神圣的东西，概念很多时候只是bullshit。很多概念的产生是因为需要认识和概括某种存在着的现象而不得已产生的，概念也许是必须的但并不是必然如此的。

换句话说，概念仅可以被看做是一种努力尝试描述后的结果之一。或者也可以说概念是提出这个概念的人自嗨的产物，跟其他人关系不大。甚至，有些概念是‘别有用心’的发明来合理化某种其实不必合理化但是存在的现象。

所以不要把自己拘泥于一个这样的概念中来思考所面临问题的实质。把概念忘了，你才可能看清楚你和事物本身的关系。

完全没有基础我该从哪下手？

完全没有基础学习 Web 安全是件比较难的事情，所以我给出的最小的方案和最少的建议。

工具

先用 AWVS 扫几个测试网站大体了解一下

把扫到的漏洞复现，了解怎么利用，主要了解：

XSS
SQL 注入
远程代码执行

开发

书籍

《细说 PHP》

实践

使用 PHP 写一个列目录的脚本，可以通过参数列出任意目录的列表
使用 PHP 抓取一个网页的内容并输出
使用 PHP 抓取一个网页的内容并写入到Mysql数据库再输出

安全

实践

手工找 http://testphp.vulnweb.com/ 的漏洞，对比 AWVS 的结果

书籍

《黑客攻防---web安全实战详解》
《安全之路：Web渗透技术及实战案例解析（第2版）》
还是看不懂就找自己能看得进的 Web 安全的书

探索资源，我在研究和学习的过程中更加好的资源和工具来帮助我们成长和解决问题？

平时我们安装一个mysql，要先到处找安装包，再一步步配置，运行，还不知道装哪了。开机就自动启动了，用了 docker 后再也没这个烦恼拉，一行命令，或者是在Kitematic界面上点一下就运行拉。

Github https://www.github.com

搜索 awesome-xxx

找到大牛的 github 看 stars，也就是收藏的项目

https://github.com/flankerhqd?tab=stars 移动安全
https://github.com/orangetw?tab=stars WEB 安全、CTF
https://github.com/EtherDream?tab=stars 前端安全
https://github.com/l3m0n?tab=stars 渗透测试、内网安全
https://github.com/ring04h?tab=stars 安全开发

探索频道 https://github.com/explore

主要是一些有趣的新潮的项目
当然也有安全相关的啦 https://github.com/showcases/security

趋势 https://github.com/trending/developers
善用收藏

Docker hub https://hub.docker.com/ ，用于查找已经封装好的环境，减少装环境带来的麻烦

举例：

数据库 Mysql https://hub.docker.com/_/mysql/
一句话安装运行：docker run -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:latest
XSS攻击平台BeeF https://hub.docker.com/r/janes/beef/ 一句话安装运行：docker run --rm -p 3000:3000 janes/beef
Kali 渗透测试 Linux 系统 https://hub.docker.com/r/kalilinux/kali-linux-docker/
漏洞靶场 https://hub.docker.com/r/citizenstig/dvwa/ 一句话安装运行：docker run -d -p 80:80 citizenstig/dvwa
Nmap https://hub.docker.com/r/uzyexe/nmap/
一句话安装运行：docker run --rm uzyexe/nmap -p 80 http://example.com
搜索通用漏洞靶场，关键字：cve-
安全相关的 Paper

挖漏洞应该是一件快乐的事情，当你把挖漏洞的目的从单纯的挣钱和声望再丰富一些，你会发现收益的重要性可能远小于心情愉快。慢慢的变成一种良性循环，让你走的更远。

第三部分

https://www.cnblogs.com/qmfsun/p/3724406.html

相关阅读:
ThreadSafety with the AutoResetEvent, ManualResetEvent Class(Synchronization of .net)
使用Python SMTP发送邮件
 flask项目中设置logo
如何解决Bootstrap中分页不能居中的问题
 pip install mysql_python报错解决办法
 git上拉项目
 AttributeError: 'str' object has no attribute 'decode'
pycharm设置SDK
为git创建远程仓库
 开发过程中git的使用
原文地址：https://www.cnblogs.com/jiaoyang77/p/8028804.html