一、软件系统设计开发运行安全

1、注重OpenSource组件安全检查和版本更新（black duck）

现在很多云、云服务器都是由开源的组件去搭成的，对于OpenSource组件应该去做一些安全检查和版本更新，尤其是版本管理，定期对在运行以及已经设计出来的软件OpenSource组件去做检查。

2、注重安全扫描（Fortify、AppScan）

再就是注重安全扫描，动态扫描，可以用AppScan、WebInspect等工具，静态扫描，可以用Fortify等代码审计工具。这些工具都是全球知名的IT公司开发的，用这些工具可以解决知识储备不足的问题。如果没有安全从业人员，但是又想保证产品的安全，那就用工具来扫码就可以，工具里面集成了大公司里面安全专家总结出来的扫描知识库、编码的规则。在安全从业人员等级不够的情况下就可以用工具来替代。
同样，这些工具也是我们安全从业人员应该掌握的，第一掌握它的原理，第二掌握它的规则，为什么使用这些规则。

3、注重WAF和Firewall

还要注重WAF和Firewall，WAF全称是Web Application Firewall。应用防火墙是在过滤每一个访问的请求数据包里面有没有安全的风险，里面有没有SQL注入、XSS攻击、远程的攻击命令或者木马等，物理的防火墙是保证了只允许信任的主机或者信任的客户端去连接某一个端口。这两个一个是软件层面的防火墙，一个是硬件层面的防火墙。如果WAF没有做到有效拦截，就会导致木马进入到服务器里面，木马进入到服务器里面之后，就可能导致一些越权的执行命令，比如说拿到了一些特殊的文件。

举一个极端的例子，通过WAF入侵了一个服务器，将这个服务器作为一个跳板，可以向局域网中去散布木马和恶意软件，网络维护人员刚好中招这个木马，他的电脑中招之后，电脑上保存的连接每一个交换机、每一个防火墙的连接口令都会泄露，导致一连串的蝴蝶效应，硬件防火墙也就被破解掉了。

这时候从网络到服务器到数据库一直到最终外界，就变成像我们说的“犹入无人之境”一样。这是比较严重的，所以我们要更多的注重WAF，因为WAF是能够快速识别到这些访问数据的，而物理防火墙只识别IP地址。

4、注重端口扫描和异常记录

我们既然有了防火墙，主机上开放的端口肯定比防火墙上开放的端口多，主机上这些端口是不是应该开，是不是安全呢？每个端口通信记录是什么？有没有异常，这些都需要去监控或者审计，定期去分析，这是运维上保证安全的一种手段。

5、设计分层、环境迁移测试、模块隔离部署

之前有一次出差，在客户现场，是做银行系统的，他们的开发有一个安全信条，俗称八荣八耻，放置在大家最常去的地方，这个标语的内容就是：以开发安全的、可用的软件为荣，以在系统中留后门留彩蛋为耻。为什么会有这样的口号呢？因为银行系统但凡有一个彩蛋或者一个后门在的话，相当于是留了一个取款机。

我们设计分层主要是不要把服务器去混着用，小公司或者不成熟的开发公司可能会把所有东西都放到一个服务器上，不管是应用、数据库还是API接口，都在一个服务器上，就导致业务数据、运行数据、客户数据都在一起，这时候风险就很大，当任何一个层面出问题，都是不可控的。

6、环境迁移测试

再就是环境迁移测试，我们既然做了设计的分层，那就必须保证这些分层的模块去独立的运行，应该经得起环境迁移的测试，而不能是只能在某一种容器上跑而不能做迁移。

7、模块隔离部署

什么叫模块隔离？我们说数据和应用要分开来部署，应用里面的应用也要进行模块隔离。给财务部门的应用应该跟给信息化部门的应用分开、跟生产部门的分开。为什么呢，因为财务是大家都比较关心的，安全级别会高一些，生产比信息化要高一些，应用层面也要隔离，否则一个服务器上布了很多个应用，当一个应用出问题的时候，就会出现像我们一开始说的链珠的例子的情况，当一个珠子断掉的时候，所有的珠子都会断，这时候安全根本没有办法去做防御。

8、整流、熔断、防DDoS攻击

这些如果部署在云上应该都会有，但是应用层面一定要考虑整流、熔断，建议大家可以用一些开源的组件。整流、熔断的隐患不属于安全的隐患，它属于性能的隐患，但是性能隐患最终会导致安全隐患，性能出了问题，服务器宕机之后，安全问题就会随之而来。

9、注重审计和日志记录、不留后门入口

这也是刚才举的例子里的，我们做软件开发、软件测试、软件设计，要保证没有人为的损害，因为人是最不可控的，程序是运行的逻辑，写的是if，就运行if，写的是else，就运行else，写的循环就运行循环，但是人确是不可控的，我们经常听到“删库跑路”的情况，这也就是为什么要留审计日志、审计不留后门，第一个是为了防止“删库跑路”，再者不把所有权限都开放给一个人。一定要注重账号权限，账号权限就是一把钥匙。

二、Web应用安全监测

1、静态代码扫描（Fortify SCA、Find Bugs）

这块主要提供给开发，安全问题不是测试出来的，是开发出来的，在开发的过程中就已经将这个雷埋进去了，测试的时候只能去一个个排雷。更多是我们在开发阶段就不要去埋雷。

如何不埋雷呢？可能很多时候我们都不知道自己埋了一个雷，因为开发经验和开发阅历不够，这时候还是回归到我们刚才的话题，我们可以利用工具，直接把Fortify SCA或Find Bugs工具集成到开发环境中。这些工具可以帮助我们去解决编码或知识储备不足这样的情况。

2、动态扫描分析

主要是有WebInspect、 AppScan这两款工具，也有一些开源的工具，但是开源的工具知识库维护的比较少，规则库也不太更新或更新的不及时。这块是我们安全测试人员必须要掌握的，不仅要掌握工具怎么用，更多的是，要将工具扫描出的结果解释给开发，这是怎么样的一个漏洞，怎么样可以修复，修复之后怎样去验证。

3、舆情监控（CVE）

这个每个公司都逃不过，要么用开源组件，要么用厂商的中间件，要么用小的中间件，要么用小的数据库。

4、账户安全策略（密码初始化、密码找回、账户过期、密码过期、账户休眠）

很多应用中都不会去考虑这些，顶多考虑一个密码找回。密码初始化是说我们后台新建的账户，当这个账户真正开始用的时候，必须初始化一下密码。账户过期指的是，我的账户如果输错了多少次密码，必须让它过期或者冻结一段时间，防暴力破解密码。密码过期指的是，密码只能使用一段时间，比如说银行里的密码，可能只能使用一天，第二天就必须换密码。

5、账户休眠

最后一个就是账户休眠，比如说给高层领导分配了一个很高权限的帐号，但是他几乎不上这个系统，开发人员知道这个密码后，他就可以拿这个账户当后门一样用，这都是风险，所以要关注休眠账户，有没有异常登录，有没有休眠策略。

接下来还有拦截各种SQL注入，XSS跨站、网站挂马、篡改、拖库等黑客攻击，并做到实时更新防护策略，第一时间防御各种0day漏洞。这种0day漏洞跟CVE一样，也要做日程监控，因为一般黑客拿到这个漏洞，他是不会去公布的，除非厂商自己知道才会对外公布。有一个时间差，在这个时间差里，很多人已经遭受攻击了。

应对0day漏洞就需要在公司内部培养一个安全团队，去挖掘出来产品里有没有0day漏洞，也就是一个安全实验室。但是大部分公司没有能力去建立一个安全实验室，就可以借助百度、腾讯、阿里、360这些对外输出的公司，去做这块防护。

防数据伪造及数据投毒，为什么一个web应用安全要防数据呢？数据指的是用户输的各种数据，用户有可能输的是业务数据，但是如果不是普通的用户，有可能输的是经过精心伪造的数据，它跟病毒是一样的，可以做到指哪打哪。

数据投毒是在数据里加入了一些可以帮助我debug，或者帮我调试内容，就可以在系统里面打出一个个的断点，通过系统的断点就可以判断系统走到哪一步，就可以绕过支付环节，或者绕过权限验证，绕过服务器之间的数据通信，直接到达另外一个节点。

三、移动APP的安全检测

我们现在遇到的app一般有三个平台，andriod、ios、windows，大多都是andriod或ios。首先要保证开发环境是安全的，这里给大家举了一个例子，XcodeGhost事件。

这个事件在网上影响是挺大的，为什么会有这样事件？就是因为我们在中国区开发的时候要下Xcode，这个安装包比较大，在苹果官网上下的比较慢，很多人就选择像装系统那样，别人有的，我直接Ghost回来在我的电脑上用，结果就因为Ghost事件拷贝了别人的环境，但是别人的环境是有木马的，就留了后门，你开发出来的每一个app里面都暗藏了一个后门，这就是XcodeGhost事件。

很多人可能买不起工具，就用破解，破解里面就可能有木马，就像一个录屏软件，你写一行代码，人家就将这个代码发给对方的服务器，你的软件著作权还没有申请完的时候，代码已经跑到别人的服务器上去了。

SDK安全，我们开发的时候经常要用一些SDK的包，或者说我们有的厂商就专门做SDK的工具，针对这块，国家也了一些规定，SDK包谁提供，谁就要提供它安全的保证，安全的服务，否则就不要发布。《 App 使用软件开发工具包（SDK）安全指引》 大家也可以去关注一下。

应用数据安全，数据需要加密。正常不root（越狱）的手机可以正常用，拿不到核心的数据，如果越狱之后，这些数据就像一张白纸，谁都可以拿到，就需要保证，越狱之后，即使拿到这些数据，这些数据也是加密的，需要做很多处理才可以看到原文。
给大家举个例子，2019年发布的《移动应用（App）数据安全与个人信息保护白皮书（2019年）》，一方面要保护数据安全，另一方面也要保证个人信息的收集使用安全。现在这块权责分明，谁收集，谁使用，谁保证安全，如果不能保证国家就会进行处罚。

反破解、反调试、反逆向，吾爱论坛上会有一些破解的方法，如：吾爱破解安卓逆向入门教程app逆向入门分析——破解某APP登录请求参数，这些都是入门级的，不能说你开发了一个软件，却连入门级的破解都防御不了。一定要保证软件的反破解、反调试、反逆向。

最后一点使用Fortify、 CodifiedSecurity在开发阶段尽早介入安全，保证代码的安全。

四、Android／iOS逆向&调试难度对比

下图是ios和android的逆向&调试难度的对比：

从表里看，每一项好像ios都比android要安全一些，但是话说回来，ios和android访问的是同一个系统，前台可能分了ios客户端和android客户端，但是对于后台来说，是同一个数据库，是同一个API服务器，如果能将android搞定的话，ios基本上也能如法炮制，虽然我不用ios的app，但是也可以通过效仿的方法，访问到ios可以访问的数据，这时候通过服务器就可以攻击到ios的设备上，这也是不安全的，所以需要双重的界定标准。一定要记住，虽然IOS安全，但是一旦出问题那将是雪崩式的问题。

五、Server安全检测

1、OS安全

端口安全、账户安全、漏洞扫描、入侵检测、最小服务集合、日志审计

这里面给大家说一下最小服务集合，我们经常会遇到windows服务器或者Linux服务器，它默认会带很多服务，比如说dhcp服务可能不需要，就不要把这些服务提起来。再就是日志审计，如果服务器受到入侵，黑客会想尽办法去抹除日志，让你查不到行踪，不知道他干了什么事情。所以日志审计一定要有，还要备份相应的时间，再就是审计日志不能删除。

2、软件安全

最小集合原则、阉割的系统更安全

为什么阉割的系统更安全？就像最小服务集合一样，我们把一些常用的，容易出漏洞的一些问题规避掉，比如说windows里面不放cmd、command这种命令，那你想入侵的时候就没有办法指定命令行，这时候就会相对安全一些。他猜得透系统的密码，但是猜不透系统里面有什么。

3、Web中间件安全

修改默认端口，提高入侵门槛，阻止低端扫描

默认端口大家都知道，只要经过一个Nmap的扫描，就能扫描到这台服务器开了一些什么端口，一打一个准。但是你把端口改了之后，他就需要去猜，这个端口到底是干什么的？比如说我就把数据库故意放到网络端，放到80，让他猜去吧。

4、DB安全

修改默认端口，补丁及时更新，定期日志审计、备份安全

DB安全里面备份安全很重要，sever安全检测层面上更要去强调备份，服务器是属于硬件，即使是云服务器，也很难说哪天会突然坏掉，坏了之后就需要把这些安全策略重新构建一遍，如果没有备份，这些安全策略就需要手工去加，特别繁琐，还容易遗漏。

5、缓存服务安全

性能监控，只开放服务端口，管理端口禁止开放

现在很多云服务器都被挂了一些叫“挖矿”的木马，原因就是开放了一些默认端口、管理端口之类的，把这些缓存服务管理端口禁止开放，只开放服务端口，加强性能监控，一旦服务器出现异常的性能问题，一般来说它可能出现安全问题。性能和安全是相伴出现的，批量扫描、批量攻击肯定会导致性能突然间就飙上去了。

6、云主机业务隔离、网络隔离、数据隔离

这个是很多大公司都在做的，用了几千台几万台云服务器，每个业务、每个数据、每个网络都需要去隔离的，否则就会出现服务器云安全级别的雪崩。

六、API服务安全检测

1、Swagger API接口说明屏蔽

· API接口列表保护

· 使用 API 网关

API接口最简单，也最容易被忽视。很多人写完接口后，忘记删除API接口列表，或者为了方便别人调用API接口，去写了一个说明文档，结果这个接口没加权限，导致黑客上去随便一扫，就可以发现这个API列表。

这个列表拿下来之后，攻击所有的API，尝试一遍，将所有不需要传参或者传参比较简单的API全部攻击一遍之后，就会导致数据泄露或者数据出问题。

API为什么容易被攻击？因为API直接连到数据库，API的访问是直接跟数据库进行交互。通过API访问的所有请求ip地址全部是服务器，导致你在监控层面很难去发现这出了什么问题，岂不知道黑客已经站在API服务器上去打数据库服务器了。所以API也是很关键的，一定要去保障它的安全。

2、API访问权限控制

· 增删改查API需要单独确权（Auth2.0 Token验证）

查询的就只能去查询，只能去get，而不能去post，需要修改的，可能有post权限，但一定没有delete权限。

· API访问审计（日志）

Token授权机制、时间戳超时机制<使用配额和限流>、API加密签名机制 。这里专门拿一张图来说明Token授权。

API没有办法去做登录验证，合理使用Token增加API安全的基础。

3、API版本安全

不同版本API直接兼容及信息保护。因为我们的API通常会开发1.0版本、1.1版本、2.0版本、2.2版本...每一个版本对应的客户端可能不同，比如说1.1版本对应的是app的1.0版本，到了2.0的时候对应的app的4.0、5.0，这个时候客户端的app可能有低有高，有不同的版本。导致API不能高版本一上线、低版本立即下线，这个时候兼容性以及信息保护就需要提到日程上。不能出现低版本的客户端可以访问高版本的数据、高版本的客户端可以访问更低版本客户端的数据，通过这种迂回的绕过，导致API中的数据暴露出来。

以上就是我们为大家介绍额软件安全测试的分类、安全测试方法、安全防护技术、安全测试流程的相关内容，如需 fortify、WebInspect、 AppScan等安全测试工具试用可私信我。

（谢绝转载，更多内容可查看我的主页）