- 1、本文档共10页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
实用文档
文案大全
移动应用开发安全规范
1、数据保存规范
1.1、所有敏感信息不要保存到外部存储中
1.2、S1级别的敏感信息不能在客户端保存
1.3、S2级敏感数据必须加密保存
(1)、采取权威的主流加密算法(如DES、AES、RSA等)
(2)、选取秘钥的长度必须足够长,以便满足安全性要求。
(3)、加密算法的实现方法,必须采用操作系统官方提供的接口,或是各语言标准算法库提供的函数。
(4)、严禁自己设计、实现机密算法
注:敏感数据定义详见《10. 敏感数据定义安全规范》一节
2、网络传输规范
客户端与服务端之间通信的网络是不可信的,包括运营商网络和wifi无线网络。
2.1、认证授权相关网络传输安全规范
登录、注册、密码找回等属于认证授权环节的网络传输需要使用https协议传输。
2.3、敏感数据传输需要使用https协议
敏感数据定义详见《10. 敏感数据定义安全规范》一节
2.3、服务端的证书必须由权威的CA机关提供
服务端不能采用自签名的方式提供证书,客户端需要实现验证服务端证书合法性的功能。
2.4、采用其他加密算法进行传输加密的规范
不建议使用
对于无法采用https协议进行加密通信的场景,需要使用其他加密通信方案的必须按照以下规范实施:
(1)、采取权威的主流加密算法(如DES、AES、RSA等)
(2)、选取秘钥的长度必须足够长,以便满足安全性要求。
(3)、加密算法的实现方法,必须采用操作系统官方提供的实现,或是各语言标准算法库提供的实现。
(4)、客户端、服务端之间需要有验证双发合法性身份的机制
(5)、严禁自己设计、实现机密算法
2.5、自动升级的安全规范
(1)、为了能够及时修复已发布产品的安全漏洞,必须具备在线升级的功能。
(2)、在线升级功能的实现上必须对更新程序进行完整性检查,避免在升级程序在网络传输中被替换掉。
3、页面展示规范
3.1、S0级敏感信息不能在页面中直接显示
3.2、S1级敏感信息不能在页面中完全显示
可以采用*隐藏部分内容后再页面上显示。
3.3、S2级敏感信息规范
(1)、单个信息展示,可以全部内容展示。
(2)、同时展示5个以上该类信息的页面,需要对该类信息的内容做不完全展示(使用*隐藏部分内容)
如:用户列表的展示页面
4、日志安全规范
4.1、敏感数据不能保存在日志中
所有S1、S2、S3级别的敏感数据均不能在日志中出现,确实需要出现的,需要保存时隐去部分信息。
4.2、正式发布版本不能包含debug级以下日志
4.3、关键操作日志记录规范
(1)、登录、修改密码、付款等关键操作,需要在日志中进行记录。
(2)、关键操作日志的记录位置应该是服务器端。
5、身份认证、授权和会话管理规范
5.1、身份认证机制安全规范
(1)、需要设计有效的身份验证机制。
(2)、如果采取账号密码的认证机制,密码需要6位以上,字母数字混合
(3)、涉及交易,资金等核心业务,需要有二次认证机制。
5.2、身份认证应该绑定终端用户的身份
绑定的对象是用户的身份,而非用户的设备
5.3、会话管理安全规范
登录完成后的会话管理阶段的所有请求都需要对用户的合法身份进行鉴别(如token方式),鉴别通过后才能进行光管的操作。
?
5.4、使用第三方认证安全规范
(1)、使用OAuth2.0 协议作为第三方登录认证的协议。
(2)、严格按照第三方开放平台接入规范执行。
(3)、认证逻辑尽量放在服务器端完成,不要放在客户端。
6、服务端安全规范
需要按照《web服务安全规范》执行,重点关注以下几点:
6.1、有效防范常规的XSS、SQL注入、CSRF等web安全漏洞。
6.2、对水平权限、垂直权限等与业务场景关系紧密的安全漏洞有防范措施
6.3、有防范DDOS、CC攻击的安全方案。
保障后端 API 服务和平台的安全
7、针对使用第三方或开源的代码库、框架的安全规范
7.1、在同类产品中排名前三位的代码库或框架。
7.2、有团队在持续维护,最近两年内至少发不过一个新版本或更新过bug。
7.3、国外有Google、亚马逊、微软等或国内有百度、阿里、腾讯等厂商使用的代码库或框架优先考虑。
8、应用模块、接口安全规范
8.1、应用内模块组件间的验证
应用内各组件、模块间调用要进行验证。确保调用方和被调用方多有应用内的合法安全模块。没有被替换的风险。
8.2、对被调用的外部模块的验证
应用对调用的外部模块或组件,需要有完整的验证机制,确保被调用者的合法性。
8.3、对外部调用者合法性验证
应用对外提供服务、数据访问接口的功能,需要对调用者的合法性进行验证。
注:对于android系统重点关注Activity、BroadcastReceive、Service、
文档评论(0)