0x00 引言

一日接到电话，那头紧急通知我说，设备在线上有严重漏洞，需要进行紧急修复。于是，看了漏洞原理与成因，又是一番加班与奋战。如果设备有安全性问题，当其暴露在公网上时无异于裸奔，需要尽快修复可利用点。或许这样的场景并不陌生，开发和测试一起加班，大家抱怨这洞真坑爹，早做安全性测试就好了；还有人说，架构设计时早考虑到就好了，再这样抱怨下去，友谊的小船可是说翻就翻。。。有必要把安全性测试，尤其是网络安全设备的安全性测试提上日程。

0x01 别问我是谁，只管看过来

安全测试与软件开发相辅相成，英文为"security testing"。WIKI 百科上对安全性测试的定义是：安全性测试是一个旨在揭示信息系统缺陷的安全机制,保护数据和维护功能的过程。由于安全性测试的局限性，通过安全性测试并不表明不存在任何缺陷或系统充分满足安全需求。简单的说，就是有关验证应用程序的安全服务和识别潜在安全性缺陷的过程。安全测试的方向是查找系统脆弱点威胁建模，经过测试后能够知道系统存在哪些风险，而大多不会去关注漏洞的可利用性。如果仅仅认为抓到 webshell 的屏，获取了系统提权，或者拿到敏感文件就算安全测试，那和安全测试的本意就相差甚远了，了不起也就是做了渗透测试的一部分。具体关于渗透测试和安全性测试的区别，此处不赘述。
根据《2015-2016 年度全球质量报告》显示（见下图），目前 IT 领域中最需要关注的测试类型首先为安全性测试，那么如何加强安全性测试及合理并实时的将安全性测试贯穿到产品研发的整个生命周期尤为重要。如果在软件研发过程中不优先考虑安全性，毫无疑问，这些程序将会包含各种各样的漏洞及被恶意人员利用，程序本身的功能及业务价值也会岌岌可危。

也许有人说 Oh no， 我不 care 这些，把功能开发做完再考虑，我的 KPI 重点也不在这，殊不知在需求设计阶段如果缺少这一环，最后做出来的东西也就脆弱的如同一张纸，一捅就破，无任何可靠性可用性而言，前面的工作等于白费。
0x02 最佳介入时机
在软件生命周期中，首先需要分析软件的安全度量标准是什么，安全功能满足什么样的场景；然后拟定全局安全策略及安全测试重点范围；再选定安全测试方案及使用工具；根据数据接口、架构实现等准备测试环境及样本，最后出具各方面评估的安全测试报告及综合评价、改进建议。如下展示安全测试生命周期及分别需要考虑的事情。

都需要做哪些事情，什么时候做？

工具评估—选用什么样的工具，覆盖哪些范围
人工评估 --- 静态代码审计（此文暂不涉及）
应用评估 --- 需要考虑哪些场景，覆盖哪类应用
管理评估 --- 前后台输入校验
网络架构评估 --- 评估架构设计是否合理
渗透测试评估 --- 发现产品自身脆弱性及可靠性

0x03 测试类型

该选哪个别犹豫，拟定策略往前走
一般来说，安全测试包含两个维度，一是白测试、灰盒测试、黑盒测试，二是静态测试和动态测试。划分归类如下：

此文， 我们暂不考虑静态白盒测试即对比分析新增文件的代码是否有可被利用的可能；采用什么样的测试类型，取决于业务安全需求和场景覆盖。此处更多讨论黑盒测试范围内的动态测试以及灰盒测试等。

0x04 总有一款适合你

百家兵器，各有所长
安全测试工具非常多，范围和常用工具重点包括以下几种，根据软件实现的特点和常用类型归类如下：

艾玛， 介绍这么多，是不是一时眼花缭乱了？没关系，根据拟定的 checklist，我们再来选用合适的神器！同一类中，可以根据测试需要，选用最适合自己的一款或两款足够。

0x05 准备好 checklist

摩拳擦掌，就为这一刻！
网络安全性测试，在安全性方面关注的程度和覆盖度与终端产品有所不同，更多的是关注产品或架构设计上的缺陷和恶意攻击者可能利用到的网络行为给用户及在线网络带来的危害。部署在核心网或边界网关时，自身的安全属性无法保障，何谈保障网络安全？
对于安全测试来说，要在理解系统架构的基础上，需要建立合适的测试模型，研究新的测试方法，并借助新的测试工具来实现所要的 checklist 检查点。以下几方面是需要重点关注和覆盖的范围：
1. 系统安全性
Ⅰ加密方式
系统采用何种加密算法，如 AES，DES，MD5 加密等，是否在合适的场景中使用到。同时需要考虑攻击者是否能在算法强度范围内对系统进行破解。各组件之间是否采用加密通信。例如，当系统证书生成，设备端加密生成的内容。
Ⅱ 系统安全
① 是否存在文件上传漏洞等
比如，是否能上传 PHP 之类可以执行的脚本或者，通过开放的端口创建指定文件是否能够成功。
② 权限绕过漏洞
对于有权限限制的访问是否可以绕过而直接获取系统信息等。
③ 第三方开源软件的漏洞
大多时候，系统会使用很多第三方放开源软件，在确保服务功能的前提下，尽量使用最新或较新版本，避免因其漏洞带来的软件安全问题。
如下，查看一台服务器是否有 BIND 漏洞（BIND 是目前部署在域名服务器中应用广泛的开源软件之一，ISC BIND9.9.7-P2 之前及 9.10.2-P3 都会存在 ISCBIND named 拒绝服务漏洞，当被成功利用后，系统便会崩溃。）还好这台服务器版本较高，否则可能在公网环境中分分钟被搞挂。

Ⅲ 产品自身安全性：如何绕过认证机制、越权访问
普通管理员，如果能操作所有模块读写权限，越权了管理员下的任务报表及其他视图，一旦 web 请求拦截改个数据就行，如此系统的大门就都打开了。
Ⅳ 配置读写权限
举个功能模块的例子，当某模块加入 SNMP 协议配置读写时，对于 MIB2 节点树的读写权限应该考虑控制，用户是否能够通过 SNMP 模块获取到设备自身的全部配置。对于共有信息节点，如下信息节点获取，需要考虑读写属性，避免错误的给予了权限或是没有考虑此处的缺陷设置，而导致信息全部放开获取到系统私有配置信息及写权限带来的系统恶意损坏。
①system(1.3.6.1.2.1.1)：关于该设备或实体的描述，如设备类型、硬件特性、操作系统信息，访问模式为只读。
②interface(1.3.6.1.2.1.2)：本地系统中包含的网络接口数，访问模式为只读。
③ip(1.3.6.1.2.1.4 )：指出系统是否作为一个 IP 网关（路由器）或者仅作为一个不提供转发服务的主机，访问模式为读写。
Ⅴ WEB 前端校验
各种类型的数据（数字或文本，过滤常见的 Shell 转义符）及各种编程语言（PHP、ASP、JSP 等）提供相应的检查过滤函数，若没有则可能造成数据校验不完善给后台带来风险。
当来自 client 端的数据发现异常时，最好停止行为操作，返回一个不包含细节信息的错误消息，而不要尝试过滤后继续处理，因为过滤实现得不好极容易还会给攻击者提供可乘之机。
Ⅵ 验证是否存在信息泄露
① Banner 信息
使用命令 telnet dest-ip 22(or otherport)，检测系统开启的 banner 信息，为了不暴漏系统版本脆弱性，安全起见，应该隐藏。如下图信息未隐藏，可以明显看出系统使用的版本为 OpenSSL-5.3 版本。

② 获取 HTTP header 信息及状态码
使用命令 curl–I www.aaa.com，查看 server 返回内容，如果系统自身未对相关信息做处理，就会返回 server 相关信息，如 apache 或 nginx 版本等，此时，我们就可以分分钟找到系统可能的弱点了。如下图，可以看到某教育网站服务器是很老的系统，采用的服务技术也过时，在上面找到一些攻击者感兴趣的信息可以不费吹灰之力~~

③ 检查默认开放端口
Netstate 查看系统信息，除了系统必须的服务端口开启，其余端口从安全性角度来说，都应该默认关闭。
通过各种端口扫描工具，可以看开放的端口是否存在可能被攻击的情况。

2. WEB 安全性
Ⅰ安全信息保护
信息泄露，身份认证方式等。各种本地库保存，使用的加密算法是否能够被利用破解。通过前端的安全破解，本地认证信息以及设备自身信息很有可能就会被获取。
Ⅱ 弱口令
暴力猜测及弱口令，是否能在弱口令猜测条件下被破解，安全强度要求是否足够当被暴力猜测是，是否返回了详细信息导致更容易进行下一步操作
Ⅲ XSS 检测
例如，当设备开启某功能，访问站点" rel="nofollow" target="_blank">http://www.aaa.com/url 后面添加参数，重新访问 http://www.aaa.com/"lsdk>时，会出现页面跳转及重定向。此时如果在

helloworld

修改建议：
在模块提示页面中，只返回访问的域名部分，后面的参数部分不处理.
增加对特殊字符的过滤功能。
当某策略配置界面，没有对文件类型做校验，手动修改文件类型为"> ,提交后刷新界面，即会出现弹窗。所以此类问题后台需要增加校验判断，避免 XSS 注入。

Ⅱ SQL 注入
大家都知道，简单的 SQL 注入点查找方法，比较简单，通过简单的几步渗透探测，就能找到弱点。
附加一个单引号 : http://www.xxx.com/xxx.html?id=11’，运行异常
附加 “and 1=1”http://www.xxx.com/xxx.html?id =11 and 1=1 ,运行正常
附加 “and 1=2” http:// www.xxx.com/xxx.html?id =11 and 1=2 ,运行异常
如果以上三步骤均满足，那么一定存在 SQL 注入漏洞。通过手工查找，手工定位可以接收字符串 URL 参数的动态网页，提交包含 SQL 语句的参数。但实际上， 更多的是用 SQL 注入工具及自动化工具进行验证。
对于系统级软件的注入点，最好使用自动化或半自动化工具进行，一是其包含的注入攻击语句范围比较全，可以利用各种盲注、偏移注入等查找漏洞。
① 穿山甲 Pangolin 是目前已有的 SQL 注入工具中最好的工具之一。从 PG 中自动发送出来的 URL 链接， 可以广泛的应用与各系统的注入检测。同时对 POST 和 GET 方式均可设置。

② Sqlmap，该工具用来检测注入点，但不是用来做漏洞发现。尝试找寻http://www.tyut.edu.cn/wuli/ooe/common.asp?id=5站点的注入点（此处仅供演示，站点确实存在注入点，请勿做它用）

由此可以看到，通过 get 方式找到注入点，此处可以看到是 Boolean 类型的盲注
① 后台数据库是 Microsoft Access
② web 服务操作系统: Windows 2003 or XP
③ web 应用程序技术: ASP.NET, Microsoft IIS 6.0, ASP

使用常用的数据库名进行验证：

通过常用的 table 表去撞库：

返回的数据库 tables

所以，系统呈现信息时应注意转义以及异常信息的返回尤为重要。

Ⅴ XSS 检测输入验证
利用其他帐号的用户权限，如审计员之类在账号管理的参数配置页面下 post 提交修改页面选项可以修改成功的话，说明存在输入校验弱点。

1. 系统功能安全性
   Ⅰ 安全配置
   系统各模块配置，包括参数配置，服务器配置等，是否被暴露在轻松易得的接口处。并能随时导入或导出获得到系统相关信息。通常，攻击者在访问系统时，都会进行配置的安全检测，查看软件在接口、配置文件处的相关信息，如获取到可利用的信息便可对系统进行下一步攻击。
   Ⅱ 接口安全性
   ①升级接口是否能被异常文件导入而造成的系统级损坏，策略导入时系统的校验和安全
   ②管理接口对于敏感资料的屏蔽处理

2. 数据传输安全性
   ① 通讯传输安全性：比如证书认证和加密传输方式，考虑加密存储用户名密码，程序猿们应该都知道将密码保存为一个纯文本 (无论是在文件、Windows 注册表或其他地方) 是一个很差的设计。然而，仍然会有人说 “哦，有什么问题吗?我已经将密钥加密嵌入到程序中了！应该不会有问题吧”——这只是给攻击者带来了攻击成本的提高，安全性方面是没有任何提高的。
   ② 数据编码验证：数据通常采用什么类型的编码，是否能按照安全要求做处理，加密强度是否足够
   ③ 数据独立性：不同类型的数据需要保持相对独立，避免高耦合带来的风险。采用加密方式时，也需要针对不同的数据类型采用不同的加密方式。
   ④ 数据灾备：存于本地系统磁盘的文件保存是否会有错误写入的可能，是否会被攻陷被取，是否有被明文保存或被逆向的可能
   ⑤ 物理安全：验证数据加密盘的效果，数据引导区的安全
   ⑥ 事件风暴：状态性测试中，大背景流量的数据处理上是否对数据处理存在压力及影响，应避免事件风暴带来的整个网络及系统不可用。比如系统集中上线，集中处理批量事务时。查看前后台的 LOG 日志是否能承受并且正常展示，数据库日志存储量级以及日志迁移合并问题，对前后端压力的影响都是需要考虑在内的。

3. 网络和通信安全性
   Ⅰ密钥管理，证书管理
   系统采用何种加密算法，系统文件是否在磁盘或存储卡中能被获取到。
   系统使用软密钥加密或硬件密钥管理；
   采用的是明文传输还是密文传输。若采用 B/S 架构方式的产品，大多会采用 SSL 或 TLS 1.1 和 1.2 版本的加密方式。若仍在用 HTTP 等方式安全性就会有很大隐患。
   Ⅱ业务协议类
   首要需要考虑协议一致性，一般在线网络设备对数据包的协议处理，需要有良好的自适应及网络转发，能够对 2-7 层网络数据包进行协议解码及处理，是否会导致协议异常引起的 crash。
   例如，对于标准的 HTTP GET 请求为：GET /index.html HTTP/1.1
   异常请求可能会包括如下，当收到如下数据包时，网络设备不能出现异常，需要针对非标准数据进行异常判断处理。
   AAAAAA...AAAAAAAA /index.html HTTP/1.1
   GET ///////////index.html HTTP/1.1
   GET %n%n%n%n%n%n.html HTTP/1.1
   GET /AAAAAAAAAAAAAAAA.html HTTP/1.1
   GET /index.html HTTTTTTTTTTTTTP/1.1
   GET /index.html HTTP/1.1.1.1.1.1.1.1.1.1.1.1

如某次的 HTTP Fuzzing 结果显示，对 HTTP 部分包信息处理都会出现异常，需要排查在协议解码中对协议的异常判断。

安全设备协议处理的协议的各字段，需要考虑如下，一般主要的 4 种网络协议是最需要优先考虑的，包括 HTTP，SMTP，POP3，FTP，设计开发过程中，需要对如下信息考虑处理。
Code.协议编码代号
Length. 协议长度字段
Data. 数据部分，此部分为变长
随机数据 random data：各种随机字符串 OPTION， HEADER ,VALUES 等
空字符串：将各种值以空信息代替
认证信息：该信息长度包含了用户使用的认证信息存储
字符串格式 ，是否超长或格式不匹配
无效值和异常值
溢出 overflows : 使用一个超出常规长度的随机字符串添加、插入或替换使数据填充超长
重复数据
压缩值
字符编码校验如 UTF-8 等格式，
使用协议 Fuzzing 测试仪表时，思博伦的协议安全测试自带很多协议套件，根据需要选取网络设备所能处理的协议即可。对常见的协议，因为 Fuzzing 种类会非常多，所以如 HTTP 等协议时，会跑比较久的时间。

通过仪表能够很快打出各类型的协议数据包，如下，可以看到 icmpv4 的一个异常包，对于正常报文来说，Fuzzing 增加了 OPTIONS 字段并用 NOP 填充，能够校验出网络设备对这种情况是否能够判断处理。

1. 抗攻击测试类 在线设备一般会起一些常见的服务，如 WEB 服务或 DNS 服务，当网络流量中存在一些攻击类流量时，设备自身是否能经受住考验就刻不容缓了。 常见的两款测试工具包括： ① 在 slowhttptest 的 http dos 慢速攻击下， 测试设备自身 WEB 服务是否会受影响无法打开 根据不同的参数，尝试验证对 header,body 等响应的影响，如使用如下命令： slowhttptest -c 1000 -X -g -o -slow_read_stats -r 200 -w512 -y 1024 -n 5 -z 32 -k 3 -u victim_url -p 3 当服务器一开始 service 是可用的，等到攻击结束时，显示服务不可用，即资源被耗尽了； ② 使用 slowsloris 工具发包，检测软件系统对抗 DDos 的能力。比如，在考虑是否要使用此工具覆盖时注意了解和获取系统信息，对可能受影响的系统进行检测，Apache 1.x,Apache 2.x, dhttpd, GoAhead WebServer,应该不受影响的包括：IIS6.0, IIS7.0, lighttpd, nginx, Cherokee, Squid。攻击执行截图：

0x06 如何做评估，最终看结果

所有测试做完，需给出安全性评估结果，包括对被测系统的矩阵打分及雷达图系数评分， 能让开发人员或用户明确知道在开发和使用中产品哪方面存在安全缺陷。比如下图，明显看出在 HTTP 访问安全及访问控制方面存在较严重缺陷，需要提升安全控制。关于安全性测试报告如何写，内容覆盖比较广，需要针对测试项及测试内容进行问题描述及结果分析，同时提出修复改进建议。

0x07 开始做吧

如同许多工具一样，不管是何种测试类型都不一定能够做到绝对的安全发现。如果什么问题都没找到，也不代表就不存在安全问题。安全是隐形的，安全测试是门技术，更是门艺术，有时候甚至需要一些所谓 “猥琐” 的思路和方法。安全测试人员通过各种手段，同时需要进行代价利益分析，评估软件产品是否有高危漏洞，是否有必要及时更新，不要等到遭到安全攻击后才想起安全测试。
好了，小伙伴们，说了这么多，看看我们自己开发的应用软件中，到底会有哪些安全性没有考虑到，跟着我左手右手一个慢动作，安全测试走起~~

reference：
World Quality Report 2015-16
https://www.capgemini.com/thought-leadership/world-quality-report-2015-16
http://www.testandverification.com/solutions/security/building-security-into-your-application/
https://en.wikipedia.org/wiki/Security_testing