从测试人员的角度思考应用的安全

1 写在前面的话

1.1 缘由

7 月 11 日,测试标准组会议中,大家认为安全测试应纳入平时的测试工作。由于安全测试对测试人员的要求较高,目前要推安全测试有一定难度。故想写一篇思考应用安全的文章,作为抛砖引玉之用。

1.2 目标对象

1、测试人员
2、产品人员
3、开发人员4、其他对应用安全有兴趣的人

1.3 内容

着重于从质量人员的角度对应用的安全进行思考。在测试中,或者作为质量的负责人员,对应用的安全我们需要关心那些问题。本文讨论的“应用的安全”主要包含:程序功能、数据库、日志和部署三个主题。不讨论具体的测试技术和方法,所以想通过本文就进行安全测试的读者会失望的。同时,由于水平和经验有限,难免有疏漏和错误,也请大家指正和补充。

接下来,将按各自主题,进行说明。

2 程序功能的安全

程序功能的安全主要包含代码漏洞、业务设计、业务实现三个方面。代码漏洞,就是代码本身的漏洞,比如常见的 sql 注入和跨站脚本,就是代码本身的问题造成的。业务设计,就是业务的逻辑设计问题,比如最常见的登录提示逻辑问题,造成猜测用户名,密码。业务实现,就是实现业务的代码有问题,但又不是代码有漏洞。比如会话管理,用户身份识别的漏洞,常常是业务实现的时候有问题。以下分场景来说明程序功能的安全问题。

2.1 执行 sql 语句
程序如何执行 sql 语句,是否使用 prepareStatement?是否对查

询条件的输入和查询结果的输出做了过滤。

2.2 用户界面

用户提交数据和返回到用户界面的数据是否有过滤和编码的处理。是否有统一的报错页面?系统错误时,是否会将错误或系统敏感信息直接抛到用户界面?访问的 URL 是否进行编码?

2.3 用户注册

密码是否符合要求?

密码是否容易被猜测?
密码是否加密存储?
是否有安全问题?
安全问题与答案是否加需要加密?
运营人员如何审核用户?

2.4 用户登录

用户名错误提示,密码错误提示是否合理?错误输入几次后,是否锁定用户?是否锁定 ip?是否短信通知用户?验证码是否随机?验证码的有效期?是否短信通知运营人员?是否记录异常,以供审计。判断登录时间是否异常?如何确定用户身份,如何标识用户,用户标识如何生成?

2.5 用户查询与下载

程序是否对以下操作进行监控和限制:查询或下载次数是否过于频繁?查询或下载的内容是否过于庞大?查询或下载了很久以前的数据。如何生成下载文件?下载文件的访问权限?文件何时被销毁?

2.6 用户交易

程序是否对以下内容进行监控和限制:

交易金额、交易频率、交易时间、产品类别是否能确定用户操作的合法性,如下发短信?下发次数控制?

2.7 用户找回密码如何确认用户身份?安全问题?注册邮箱?

如何生成找回密码的链接?链接有效期?发送次数控制?

2.8 用户退出如何标识用户退出、会话是否还有效?2.9 密钥

如何生成和商户交互的密钥?
如何变更密钥?
变更过程,如何认定商户的身份?

2.10 通信

如何与商户通信?
如何认定商户身份?
如何防止交易信息被窃取?
如何防止交易信息被篡改?
如何防止商户发送恶意数据?

2.11 权限

用户有哪些权限?
如何分配用户权限?
如何变更用户权限访问无权限的内容如何处理?是否有记录?是否通知商户?

2.12 应用请求

系统向其他系统发出过什么请求?请求什么资源?如何验证对方身份?处理结果如何?是否收到反馈?如何验证反馈方身份?是否需要以及如何验证反馈内容?是否有记录?其他系统是否我系统发出请求?请求什么资源?如何验证对方身份?处理结果如何?是否需要反馈?如何反馈?是否有记录?请求是否过于频繁?是否产生大量的回调?

2.13 缓存

系统使用了哪些缓存?
缓存存贮了哪些信息?
这些信息泄露有什么后果?
缓存部署在哪些机器上?
如何能够访问缓存?
缓存挂了怎么办?有何影响?
缓存是否有备份机?如何切换?切换有何影响?

2.14 第三方包或框架

需要关注第三方包和框架的安全问题,及时升级。应关注社区和官网发布的安全漏洞和解决方案。另外,程序中的加密算法,随着时间的推移,很多加密算法或加密算法的实现,都会发现漏洞,也应该关注这方面的信息。

3 数据库安全的问题

数据库安全问题,包含很多方面,这里主要是和应用相关的。

3.1 敏感信息

如何处理以下敏感信息:客户:用户账号、用户账户、登录密码、交易密码、银行卡号、银行卡密码、cvv、银行柜面手机号、验证手机号码、信用卡有效期、交易记录、安全问题、安全问题答案商户:商户账号、商户账户、商户登录密码、商户交易密码、商户银行卡号、交易记录、结算信息、结算记录、安全问题、安全问题答案、通知地址、验证手机号码、商户密钥、易宝对应的密钥。

3.2 权限

应用程序具有什么权限?
对哪些数据库有权限?
对哪些表有权限?
对哪些表没有权限?
如何变更权限?我们应用的数据是否被非法请求过?能否记录这种非法请求?

3.3 读与改

是否最近有大数据量读取操作?

是否有用户敏感信息被改动?
是否有异常的大量的查询?
是否有非授权的访问?

3.4 灾备

数据库如何备份?
备份机如何切换?
切换有何影响?

4 日志与部署

4.1 部署

部署方面,更多的是运维考虑的安全问题。对应用程序来说,更多的考虑是如何阻止非法请求或者非授权的访问。现在不让外网访问的资源,都部署在内网。但是要注意是否有人可以通过内网机器的回调来非法访问到这些资源。所以应用在处理回调地址时,格外需要注意,例如:localhost,127.0.0.1,内网 IP、某些特殊域名(yeepay)的处理。

4.2 日志

对于信息泄露,日志很容易让人忽略。对于应用程序的处理的信息,哪些可以打在日志中,哪些可以进行掩码处理打在日志中,哪些不可以出现在日志中,又不至于出现问题时,开发人员无法追查日志。日志记录下来了,那么是否有分析日志呢?经常是面对浩瀚的日志,无从分析,这也是问题只有等暴露了,才有人关心。缺乏日志分析,特别是自动化的分析和审计,是十分棘手的问题。不是因为难,而是米有人做。