安全测试

3.1 安全漏洞评估

1、评估方式

自动化扫描：系统层漏洞大部分情况下使用自动化扫描
手工评估：耗时、不全面、技术要求高

2、评估流程

3.2 安全配置评估

1、安全配置评估分类

评估	说明
基础安全配置评估	在了解现状和基本需求的情况下，定义业务系统的基础安全配置要求，配置要求内容和具体产品相关
业务安全配置评估	辨析不同业务系统的安全需求，在已形成的基础安全配置评估上进行增加，同时协调不同安全设备上的策略，以期望形成符合业务特点的安全方案

2、安全配置评估规范分类

评估	说明
账号管理	账号分配管理：避免共享账号。多余账号锁定：锁定无关账号远程登录等
口令配置	口令复杂度要求；口令生存期要求等
认证授权	用户缺省权限控制；关键目录权限控制等
日志配置	登录日志记录；系统事件记录等
设备管理	SSH安全登录；补丁、版本最低要求等
其他安全	登录超时退出；共享权限要求等

3.3 安全测试

1、部分专业术语

黑盒测试：在客户授权的情况下，模拟黑客攻击的方法和思维方式，来评估计算机网络系统可能存在的风险。黑盒测试不知道源代码。

白盒测试：相对于黑盒测试，白盒测试基本是从内部发起。白盒测试知道源代码。

渗透测试：出于保护系统的目的，更全面地找出服务器的安全隐患。

入侵：不择手段地（甚至是具有破坏性的）拿到系统权限。

IOT安全：物联网（Internet of things（IoT））安全。

APT安全：高级持续性威胁(Advanced Persistent Threat，APT)，威胁着企业的数据安全。APT是黑客以窃取核心资料为目的，针对客户所发动的网络攻击和侵袭行为，是一种蓄谋已久的“恶意商业间谍威胁”。

Payload：是包含在你用于一次漏洞利用中的ShellCode中的主要功能代码。

Shellcode：可提权代码。对于一个漏洞来说，ShellCode就是一个用于某个漏洞的二进制代码框架，有了这个框架你可以在这个ShellCode中包含你需要的Payload来做一些事。

Exp：漏洞利用，一般是个demo程序。即示例程序。

Poc：(Proof of Concept)漏洞证明。一般就是个用来证明和复现漏洞的样本。

vul：(Vulnerability) 漏洞。

2、渗透测试流程

步骤	说明
明确目标	确定范围；确定规则；确定需求。
信息收集	基础信息；系统信息；应用信息；版本信息；服务信息；人员信息；防护信息。
漏洞探测	系统漏洞；WebServer漏洞；Web应用漏洞；其他端口服务漏洞；通信安全。
明确目标	确定范围；确定规则；确定需求。
信息分析	精准打击；绕过防御机制；定制攻击路径；绕过监测机制；攻击代码。
获取所需	实施攻击；获取内部信息；进一步渗透；持续性存在；清理痕迹。
信息整理	整理渗透工具；整理收集信息；整理漏洞信息。
形成报告	按需整理；补充介绍；修补建议。

3.4 HTML5介绍

1、HTML5解释

狭义解释：HTML5简称H5，是W3C制定的标准，在兼容原有html4.01和xhtml1.0标准的基础上，增加和修改了一些元素。此时HTML5 ≈ HTML+CSS3+JavaScript+API

广义解释：HTML5是HTML、CSS和JavaScript在内的一套技术组合，其目标是减少浏览器对于插件的依赖，提供丰富的RIA（富客户端）应用。

HTML5是标准而非技术。通过其所支持的内容将互联网语义化，能更好地被人和机器阅读。

2、HTML5的优势

跨平台：跨越iOS、Android、PC等多个平台，基于浏览器或浏览器引擎，将网页应用转换成移动或桌面应用。

减少插件依赖：可以不使用第三方插件查看视频、音频、图像等内容。

HTML5安全性：Iframe沙箱、内容安全策略（CSP）、跨域资源共享（CORS）。

3、HTML5应用场景

Web APP：指采用Html5语言写出的App，不需要下载安装，以浏览器为入口。

Hybrid APP：指半原生半Web的混合类App，需要下载安装，具有Native和H5的优点，通过WebView展示丰富多彩的页面。

4、HTML5安全测试

常规移动客户端安全测试：客户端程序安全、通信安全、服务端安全。

常规Web应用安全测试：各种web漏洞。

本地存储测试：html5中的Web Storage包括了两种存储方式：sessionStorage和localStorage。

---

sessionStorage用于本地存储一个会话（session）中的数据，这些数据只有在同一个会话中的页面才能访问并且当会话结束后数据也随之销毁。因此sessionStorage不是一种持久化的本地存储，仅仅是会话级别的存储。该项不用测试。

localStorage用于持久化的本地存储，除非主动删除数据，否则数据永远不会过期。该项重点测试。

3.5 堡垒机

1、堡垒机介绍

堡垒机是一套部署在数据中心，能够统一管理工作人员和网络资源，能够进行集中身份认证、集中管控资源和权限分配、智能运维托管资产、操作全程审计的运维安全管理解决方案。堡垒机是防火墙体系的基本形态。
堡垒机的应用场景：VPN联动；云安全APP联动；征信系统审计。

2、使用堡垒机将解决的问题

运维账号混用，粗放式权限管理

1、多个用户使用同一个账号，难定责。
2、一个用户使用多个账号，工作效率低，工作复杂度增加。
3、缺少统一的权限管理平台，无法基于最小权限分配原则的用户权限管理

审计日志粒度粗，易丢失，难定位

1、各系统自身审计日志分散、内容深浅不一，无法根据业务要求制定统一审计策略，容易被系统管理员删除，导致难以及时发现违规操作行为和追查取证。
2、旁路数据分析审计无法对已加密的应用层数据（SSH、SFTP等）进行细粒度分析，无法对图形运维操作（RDP，VNC等）过程进行完整还原，无法做到实时管控。
3、主机探针审计方式，占用系统资源，对系统稳定性埋下隐患。不能对网络方式运维操作过程完整还原展示，事后审计能力不足。

面临法规遵从的压力

政府、金融、运营商等陆续发布信息系统管理规范和要求，均要求采取信息系统风险内控与审计，但其自身却没有有效的技术手段。

运维工作繁重枯燥

数据备份工作量大、设备账号改密量多等问题常常导致运维操作失误，效率低等现象，这严重影响企业的经济运行效能，并对企业声誉造成重大影响。

虚拟云技术蓬勃发展

云环境下的信任问题日趋突出，多租户和用户下身份认证、权限控制，云主机系统运维和安全审计等种种问题都困扰着云服务厂商，也制约了云服务业务的发展。

3、堡垒机产品安全测试

大部分堡垒机登录均采用多因素认证，如令牌、短信验证码等。

按照常规Web应用安全测试方法测试，重点关注以下测试项：
1.账号枚举
2.多因素认证绕过
3.通信加密测试：明文传输，如使用HTTP协议传输，且关键信息未本地加密
4.越权测试：堡垒机有不同角色的账号，存在功能越权的漏洞

4、堡垒机环境下的web应用测试

测试堡垒机强控的系统时，一般是登录堡垒机后，远程登录到一台宿主机，在宿主机上访问目标测试站点，测试工具由客户上传到宿主机上。

结构图如下：

3.6 虚拟化

1、虚拟化介绍

虚拟化：是指通过虚拟化技术将一台计算机虚拟为多台逻辑计算机。每个逻辑计算机可运行不同的操作系统，并且应用程序都可以在相互独立的空间内运行而互不影响，从而显着提高计算机的工作效率。

虚拟化分类：操作系统虚拟化、桌面虚拟化、应用程序虚拟化、存储/网络虚拟化。
虚拟化应用场景：办公桌面。即瘦客户端不存储工作数据，数据在虚拟客户端(云)上。

2、虚拟桌面产品安全测试

按照常规Web应用安全测试方法测试，重点关注以下测试项：

登录功能测试：账号枚举、暴力破解、验证码绕过，如验证码未失效、验证码可置空等、二次认证绕过，如发送短信验证码手机号篡改、绕过校验等。

通信加密测试：明文传输，如使用HTTP协议传输，且关键信息未本地加密。

越权测试：与常规测试方法相同，重点关注功能菜单越权。

3、虚拟环境下的安全测试

1、测试目标部署在虚拟机中：该场景的安全测试和常规测试相同，可直接访问并测试目标。
2、在虚拟机中访问测试目标：远程登录虚拟机，将测试工具拷贝至虚拟机中，在虚拟机中实施安全测试。

3.7 云环境

1、云环境简介

云计算是一种按使用量付费的模式，这种模式提供可用的、便捷的、按需的网络访问，进入可配置的计算资源共享池(资源包括网络，服务器，存储，应用软件，服务)，这些资源能够被快速提供，只需投入很少的管理工作，或与服务供应商进行很少的交互。

云环境下的安全测试：和传统服务测试一样，多了沙箱等之类的云环境独有的安全方案。

2、云环境分类

1、基础设施即服务IaaS(Infrastructure-as-a-Service)
就是将CPU、存储、网络等硬件资源能力云化，作为服务提供给消费者。

2、平台即服务PaaS(Platform-as-a-Service)
就是运行软件的软件能力和开发软件的软件能力云化，作为服务提供给消费者，如阿里和腾讯的开发平台等。

3、软件即服务SaaS(Platform-as-a-Service)
将应用软件的能力云化，作为服务提供给消费者，如淘宝、京东等。

3、云环境的优势

1、云平台能够自行提供开发及测试环境，因此我们可以在无需对数据中心硬件及软件进行变动的前提下开始进行应用程序创建工作。

2、能够快速将应用程序投入生产层面并根据需求对应用进行扩展。

3、能够帮助我们与其它开发者、架构师以及设计师顺利协作，共同处理应用程序创建过程中的各项任务。

4、云环境应用场景

电子邮箱：云计算将电子邮件资源保存在云端，用户可以在任何地点、任何设备和任何时间访问自己的邮件，企业可以使用云技术让邮箱服务系统变得更加稳固。

数据存储：用户可以将所需要的文件、数据存储在互联网上的某个地方，以便随时随地访问。云服务商将会为用户提供广泛的产品选择和独有的安全保障。

商务合作：共享式的商务合作模式，使得企业可以无视消耗大量时间和金钱的系统设备和软件，只需接入云端的应用，便可以邀请伙伴展开相应业务。

虚拟办公：使用虚拟办公应用的主要好处是不会增加设备负载，它将企业的关注点集中在公司业务上，通过改进的可访问性，为轻量办公提供保证。

业务扩展：基于云的解决方案，可以使企业以较小的额外成本，获得计算能力的弹性提升。云服务商可以满足用户的定制化需求，低廉的成本使得企业无须对未来的扩张有所顾虑。

移动办公：针对移动办公的特点，多种手持终端可以实现无缝的随时随地接入，方便进行远程办公和业务流程处理，真正实现任何时候、任何设备、任何网络都可以访问应用的需求。现有IT系统无需改造，通过桌面云系统即可以实现网络的全集中管理，提高IT维护效率。

3.8 微服务

1、传统单块架构模式

传统的 Web 应用开发在逻辑上分为表示层、业务逻辑层和数据访问层三层的模式，开发团队对不同层的代码实现，经历编译、打包、部署后，最终运行在同一台机器的同一个进程中。对于这种功能集中、代码和数据中心化、一个发布包、部署后运行在同一个进程中的应用程序，称之为单块架构（monolithic architecture）。

传统单块架构由于所有的代码运行在同一主机的同一个进程中，不同功能与服务模块的线程共享进程空间，用户状态可以用全局变量实现共享。外部访问控制，认证授权与功能交互统一起来，所有功能通过内部的方法或函数调用来实现，不需要对外提供额外的 API 接口，使得程序的安全性较高。

2、微服务架构

为了打破单块架构模式所带来开发效率低、代码维护差、部署不灵活、拓展性差瓶颈，在微服务架构中对应用进行有效拆分，每个服务运行在独立的进程中，服务间采用轻量级的通信机制相互沟通。服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护，并且能够被独立的部署到生产环境、类生产环境等。

3、传统单体架构VS微服务架构

传统单块架构

同一主机同一进程内
      -开发团队对不同层代码进行编译、打包，部署到一个主机进程中

所有服务模块为本地调用
-全部服务皆可共享用户的逻辑状态
-应用服务器提高会话管理

构建部署时间充分
-在周期内将安全融入的到系统开发中，将安全漏洞早于部署前发现

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

微服务架构

不同容器或者主机不同进程
      -将微服务打包为Docker镜像
      -将每个服务实例部署为容器

各个服务间需要远程访问
- 服务之间独立无法共享用户状态
- 需要集中进行身份校验与授权
- 服务间需要互相通信并且进行控制

敏捷开发与自动化部署
- 业务优先原则，安全在更快的投付生产中显得疲奔命

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

4、微服务的特点

彼此独立：既然是一个独立的服务，那必然是一个完整的自治系统，不依赖外部的东西就能够提供服务。有自己一整套的完整的运行机制，有和外部通讯的标准化接口。

原子化：作为一个微服务，一定是一个原子化的服务。也就是说服务不能再划分成更小的服务了。如果一个服务还能划分成几个小的服务，那我们就不能称之为一个微服务，它其实可以通过几个微服务组合成的一个系统。

组合和重构：如果是最原子的服务，那一定是没有任何用处的。微服务之所以神奇，在于它能快速的组合和重构，彼此组合成一个系统。

5、微服务应用场景

Eureka	服务注册发现框架	Hystrix	服务容错组件
Zuul	服务网关	Archaius	服务配置组件
Karyon	服务端框架	Servo	Metrics组件
Ribbon	客户端框架	Blitz4j	日志组件

6、Docker容器介绍

Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。几乎没有性能开销，可以很容易地在机器和数据中心中运行。最重要的是，他们不依赖于任何语言、框架包括系统。

Docker是微服务的一个非常完美的运行环境。

7、微服务与微服务之间的安全

1、微服务模块自身安全

相当于传统服务端，那么传统服务端中涉及到的安全风险相对的都可能在微服务模块中存在，比如输入输出校验不严格、第三方框架带来的风险、引入新技术带来的风险。

2、服务注册与发现组件安全

该部分的风险直接影响着整体微服务架构的安全性。服务注册与发现组件用于实现分布式系统中服务的发现与配置，常用的有consul等。区别于常见风险，它所带来严重风险为信息泄露及导致整个架构不可用。

3、服务间通信安全

微服务架构中通信包括客户端与API网关通信、客户端与微服务端直接通信、服务间通信，其中客户端与API网关通信或者客户端与微服务端直接通信都属于边界安全问题。微服务间的通信属于内部通信，这是微服务架构相较于传统单块架构的独特之处。

在架构中必须保证所有微服务接口统一由API网关进行管理，否则一旦接口直接暴露与公网，会由于接口滥用带来很多风险，同时为了防止攻击单点突破，需要根据业务需求精确地指定哪些服务可以与其通信。