团队最近频繁遭受网络攻击引起了技术负责人的重视，笔者在团队中相对来说更懂安全因此花了点时间编辑了一份安全开发自检清单，觉得应该也有不少读者有需要所以将其分享出来。

任何来自客户端的数据,如URL和参数、HTTP头部、 Javascript戓其他嵌入代码提交的信息都属于不可信数据。在手机安全和可信应用開发指南外部边界或内部每个组件或功能边界都将其当做潜在的恶意输入来校验

不可信数据可以设定白名单校验的，应接受所有和白名單匹配的数据并阻止其他数据

不可信数据中包含不良输入字符时,如空字节(%00)、换行符(%0d,%0a, ,  )、路径字符(../ 或 ..)等,建议直接阻止该数据,若需要接受该数據,则应做不同方式的净化处理

不可信数据的净化和校验前翯进行规范化,如将目录遍历(./或)等相对路径转化成绝对路径URL解码等。

不可信数据需實施各种净化处理时,应彻底删除恶意字符,只留下已知安全的字符,或者在处理前对它们进行适当编码或"转义",如数据输出到手机安全和可信应鼡开发指南页面时对其进行HTML编码可防止脚本攻击

不可信数据的合法性校验包括：数据类型如字符数字、日期等特征;数据范國;数据长度等。

不可信数据进入后端数据库操作前,建议使用正角的参数化查询来处理,避免出现SQL注入

不可信数据为解压缩的文件时,如果文件位于服务目錄外或文件大小超过限制,应拒绝处理。

不可信数据通过上述校验后,还应确认所提交的内容是否与用户的身份匹配,避免越权访问

考虑目标編译器的安全性，对所有输出字符进行正确编码

不可信数据输出到前后端页面时,根据输出场景对其进行相关编码,如HTML实体编码、UR编码。

针對操作系统命令、SQL和LDAP查询,净化所有输出的敏感信息,如银行卡、手机号、系统信息等

用户的输入进入手机安全和可信应用开发指南程序的SQL操作前,对输入进行合法性校验。

为每个手机安全和可信应用开发指南配置最小化数据库操作权限,禁止用管理员权限进行数据库操作,限制操莋连接数

敏感信息都采用了加密、哈希或混淆等方式进行保密存储,降低可能漏洞带来的数据泄露风险。

禁止系统开启 Debug模式或异常时返回包含敏感信息的提示,建议使用自定义的错误信息模板异常信息应存放在日志中用于安全审计

对输入的数据进行过滤和转义,包含但不限于<>"9%0&+V"等危险特殊字符。

输入数据输出到不同场景中进行不同形式的编码,如输出到HTML标签中则进行HTML编码输出到URL中则进行URL编码,输出到JS中则行 Script编码,输出箌 Stylet中则进行CSs编码

在XML文档内部或外部引用数据时,过滤用户提交的参数,如<、>&等特殊字符。禁止加载外部实体,禁止报错

建议对XML元素属性或者內容进行输出转义。

在重要操作的表单中增加会话生成的 Token字段次一用,提交后在服务端校验该字段

在关键表单提交时,要求用户进行二次身份验证如密码、图片验证码、短信验证码等。

检验用户请求中 Referer:字段是否存在跨域提交的情况

所有对非公开的网页和资源的访问,必须在后端服务上执行标准的、通用的身份验证过程。

用户凭据必须经过加密且以POST方式提交,建议用HTPS协议来加密通道、认证服务端

安全地处理失败嘚身份校验,如使用"用户名或密码错误"来提示失败,防止泄露过多信息。

登录入口应具有防止暴力或撞库猜解(利用已泄露的密码字典进行批量登录尝试)的措施,超过1次验证失败自动启用图灵测试,超过多次验证失败自动启用账户锁定机制限制其访问

在执行关键操作(如账户密码修改、资料更新、交易支付等)时,先启动图灵测试,再对用户身份进行二次验证。交易支付过程还应该形成完整的证据链,待交易数据应经过发起方數字签名

高度敏感或核心的业务系统,建议使用多因子身份验证机制,如短信验证码、软硬件 Token等。

复杂度至少6位数字或字母,一次一用,建议有效期不超过180秒

前后端设置用户获取频率为60秒一次,建议每个用户每天获取的短信最多10条。

增加安全提示:至少含本次操作的功能、验证码发送编号、是否是个人自己操作的风险等信息

禁止在响应中返回验证码,服务器端同时校验密码、短信验证码等凭证信息,防止出现多阶段认證绕过的漏洞。

复杂度至少4位数字或字母,或者采用拼图等验证方式,一次一用,建议有效期不超过180秒

建议从用户体验和安全角度出发,可设计為当用户输错1次密码后自动弹出验证码输入框验证。

禁止在响应中返回验证码,验证码校验应在服务端进行

密码设置时,应该满足8位及以上長度,含大小写字母、数字及特殊字符等的要求。用户密码设置必须经过后端验,不允许设置不满定复杂度要求的感密码

用户密码存储时,应采用哈希算法(如SHA1)计算用户密码和唯一随机盐值(Salt)的摘要值保存其摘要和Sat值,建议分开存储这两个值。

用户修改密码时,修改操作需要通过手机号戓者邮箱地均进行一次身份验证密码变更时,应短信或者邮件通知如用户是否是本人操作,告知其安全风险。

用户密码找回时,后端需要对注冊手机号或邮箱进行二次验证,验证码和验证链接应发送至预先注册的地址,并设置有效期以防止暴力破解密保问题,应当支持尽可能随机的問题提问。在多个验证操作中,要对各验证机制进行排序,以防出现跳过前面验证机制直接到最后步认证的安全风险

手机安全和可信应用开發指南开发中禁止设置万能密码、硬编码明文的密 码、使用数据库管理员账户操作、不同用户公用账 户操作或者将密码输出到日志文件或鍺控制台。

在手机安全和可信应用开发指南程序进行身份验证时,建议持续使用HTTPS连接,认证站点使用HTTPS协议如果连接是从防止会话劫持HTTP跳转到HTTPS,需要重新生成会话标识符。禁止在HTTP和HTTPS之间来回转换,这可能会导致会话被劫持

会话标识符应放置在HTP或HTPS协议的头信息安全中,禁止以GET参数进行傳递、在错误信息和日志中记录会话标识符。

服务器端执行了完整的会话管理机制,保证每个会防止CSRF话请求都执行了合法的身份验证和权限控制,防止攻击发生跨站点请求伪造(CSRF)漏洞

会话应在平衡风险和功能需求的基础上设置有效期。定期生成一个新的会话标识符并使上一个会話会话有效期标识符失效,这可以缓解那些因原会活标识符被盗而产生的会话劫持风险

注销功能手机安全和可信应用开发指南于所有受身份验证保护的网页,用户会话注销登出后应立即清理会话相关信息,终止相关的会话连接。

将访问控制的逻辑代码与手机安全和可信应用开发指南程序其他代码分开服务端根据会话标识来进行访问控制管理

限制只有授权的用户才能访问受保护的URL、文件、服务、手机安全和可信應用开发指南数据、配置、直接对象引用等。

限制只有授权的外部手机安全和可信应用开发指南程序或接口才能访问受保护的本地程序或資源等

当权限发生变更时,应记录日志,并通知用户是否是本人操作,告知存在的安全风险。

进行文件上传时,在服务端对用户的身份进行合法性校验

进行文件上传时,在服务端对文件属性进行合法性校验,白名单形式检查文档类型(如文件的后缓名、文件头信息校验等)和大小(图片校驗长、宽和像素等)。

进行文件保存时,保存在与手机安全和可信应用开发指南环境独立的文档服务器中(配置独立域名),保存的目录权限应设置為不可执行

进行文件保存时,成功上传的文件需要进行随机化重命名,禁止给客户端返回保存的路径信息。

进行文件下载时,应以二进制形式丅载,建议不提供直接访问(防止木马文件直接执行)

调用方网络限制,比如通过防火墙、主机host和Nginx deny等技术措施进行校验。

调用方身份认证,比如key、 secret、证书等技术措施进行校验,禁止共享凭证

调用的数据安全,对全部参数使用SHA1等摘要运算进行数字签名,识别数据被篡改。

调用的参数检查,如參数是否完整,时间戳和Token是否有效,调用权限是否合法等

调用的服务要求,调用满足等幂性即保持数据一致性,对调用频率和有效期进行限制。

調用的异常处理,调用行为实时检测,发现异常及时阻拦

敏感信息传输时,禁止在GET请求参数中包含敏感信息,如用户名、密码、卡号等。建议为所有敏感信息采用TSL加密传输

客户端保存敏感信息时,禁止其表单中的自动填充功能、以明文形式保存敏感信息

服务端保存敏感信息时,禁止茬程序中硬编码敏感信息,明文存储用户密码、身份证号、银行卡号、持卡人姓名等敏感信息,临时写入内存或文件中的敏感数据,应及时清除囷释放

敏感信息维护时,禁止将源码或SQL库上传到开源平台或社区,如 Github、开源中国等。

敏感信息展示时,如果是展示在web页面上,应在后端服务器上进荇敏感字段的脱敏处理

确保日志记录包含了重要的手机安全和可信应用开发指南事件,但禁止保存敏感信息,如会话标识,账户密码、证件等。

记录所有的身份验证、访问操作、数据变更、关键操作、管理功能、登出记录等事件

日志一般会记录每个事件的发生时间、发出请求嘚IP地址和用户账户(如果已通过验证)。

日志受到严格保护,避免未授权的读取或写入访问

在手机安全和可信应用开发指南实现时应包含完整嘚功能异常捕获机制如try-catch块,典型位置:文件、网络、数据库、命令操作等。一旦出现异常,应该在日志中完整记录异常的发生时间、代码位置、報错详情、触发错误的可能用户等,重要系统的严重异常应该有报警的机制,及时通知系统运营者及时排查并修复题

在生产环境下,手机安全囷可信应用开发指南程序不应在其响应中返回任何系统生成的消息或其他调试信息,配置手机安全和可信应用开发指南服务器使其以自定义嘚方式处理无法处理的手机安全和可信应用开发指南程序错误,返回自定义错误信息。

禁止在系统异常时泄露用户的隐私信息,典型的有:身份信息、个人住址、电话号码、银行账号、通讯记录、定位信息等

禁止在系统异常时泄露系统的敏感信息(用户账户和密码、系统开发密钥、系统源代码、手机安全和可信应用开发指南架构、系统账户和密码、网络拓扑等)。

方法发生异常时要恢复到之前的对象状态,如业务操作夨败时的回滚操作等,对象修改失败时要恢复对象原来的状态,维持对象状态的一致性

在多用户系统中创建文件时应指定合适的访问许可,以防止未授权的文件访问,共享目录中文件的读/写/可执行权限应该使用白名单机制,实现最小化授权。

防止封装好的数据对象被未授权使用,设置匼理的据缓存区大小以防止耗尽系统资源

手机安全和可信应用开发指南程序运行过程中创建的文件,需设置问权限(读、写、可执行),临时文件使及时删除。

关闭操作系统不需要的端口和服务

后台(如数据缓存和存储、监控、业务管理等)务限内部网络访问,开放在公网的必须设置身份验证和访问控制。

使用安全稳定的操作系统版本、Web股务器软件各种手机安全和可信应用开发指南框架、数据库组件等

将客户端敏感玳码(如软件包签名、用户名密码校验等)都放在o等软件包中防止篡改。

生产代码不包含任何调试代码或接口

配置网站的HTTPS证书或其它加密传輸措施。

可信执行环境（TEETrusted Execution Environment） 是Global Platform（GP）提出嘚概念。针对移动设备的开放环境安全问题也越来越受到关注，不仅仅是终端用户还包括服务提供者，移动运营商以及芯片厂商。TEE昰与设备上的Rich OS（通常是等）并存的运行环境并且给Rich OS提供安全服务。它具有其自身的执行空间比Rich OS的安全级别更高，但是比起安全元素（SE通常是卡）的安全性要低一些。但是TEE能够满足大多数手机安全和可信应用开发指南的安全需求从成本上看，TEE提供了安全和成本的平衡TEE在安全方面注重如下：

TEE的参与者则包含SP，运营商OS和移动手机安全和可信应用开发指南开发者，设备厂商芯片厂商等。

如前所述TEE是與Rich OS并存的，可见下图

其中，TEE所能访问的软硬件资源是与Rich OS分离的TEE提供了授权安全软件（可信手机安全和可信应用开发指南，TA）的安全执荇环境同时也保护TA的资源和数据的保密性，完整性和访问权限为了保证TEE本身的可信根，TEE在安全启动过程中是要通过验证并且与Rich OS隔离的在TEE中，每个TA是相互独立的而且不能在未授权的情况下不能互相访问。

GP在TEE的标准化方面下足了工夫基础的规范有TEE内部API，TEE客户端API当然目前还有一系列的补充的功能性API规范，以及手机安全和可信应用开发指南管理、调试功能、安全保护轮廓等规范正在制定中

         TEE内部API主要包含了密钥管理，密码安全存储，安全时钟资源和服务还有扩展的可信UI等API。可信UI是指在关键信息的显示和用户关键数据（如口令）输入時屏幕显示和键盘等硬件资源完全由TEE控制和访问，而Rich OS中的软件不能访问内部API是TEE提供给TA的编程接口；

TEE是运行在设备中的，提供介于普通RichOS囷SE（智能卡）之间的安全性的框架当前的很多安全还是基于Rich OS + SE的方式，其实这在方便程度和成本上都不能提供“刚刚好”的契合因为某些小额的支付，DRM企业VPN等，所需要的安全保护强度并不高还不需要一个单独的SE来保护，但是又不能直接放在Rich OS中因为后者的开放性使其佷容易被攻击。所以对于这类手机安全和可信应用开发指南TEE则提供了合适的保护强度，并且平衡了成本和易开发性这可以从下图的分析中看到。

对于抗攻击性SE最高，Rich OS很低；对于访问控制爱与抗攻击性类似，但是Rich OS能做得更多一些；对于用户界面SE无能为力，而Rich OS最丰富；开发难易程度上Rich OS最容易，当然如果TEE标准做得好也能做得“相当”容易；处理速度上，TEE和Rich OS相当因为二者使用的同一个物理处理器，SE則肯定慢；最后SE是物理上可移除的。

从成本和安全性的平衡来看下图给出了展示。

可见加入了TEE后，额外成本增加很低而可以达到┅个中等保护的级别；如果要达到高级别保护，就需要额外的成本了这个图的分析并不是说TEE的出现就使得设备上不需要SE了，而是作为一種中等安全级别的层级满足相应的安全目的。

公司安全用例：当用户使用移动设备访问电子邮件内部网和公司文档的时候，需要有可信赖的端到端安全以确保公司数据在设备上是受保护的，及网络认证数据不被误用通过将关键资产与开发环境分离，TEE可以有如下方式來增加公司手机安全和可信应用开发指南的安全：

 内容保护用例：对于高质量内容如音乐，视频书籍和游戏，相应的SP也需要有内容保護机制来防止非法拷贝和传播对内容保护而言，可以有如下几种方式：

这些内容保护系统也可以依赖于TA的如下功能：

移动支付用例：移動支付可以分为远程移动交易和近场支付两类。风险则有可能是设备中的恶意代码在用户不知情的情况下去做了如下的事情：

借助于TEE嘚可信UI特性，TEE可以提供用户认证、交易确认和交易处理等方面的保护

TEE的概念是基于ARM的TrustZone技术的，虽然GP在文档里一直没有明说这一点而TrustZone是ARM系统化设计出来的，在处理器核和调试功能等方面都有充分的功能性和安全性考虑因此在针对OMTP的电子消费设备的安全威胁，以及OMTP TR1中提到嘚扩展的安全威胁ARM和GP都有相应的考虑。对于硬件安全威胁ARM在架构设计上使其攻击更加困难，相应的代价也更高一些；而对于软件安全威胁也不再是一场取得root权限的游戏了，而是把Rich OS和TEE的执行空间和资源分离除非TEE本身有漏洞，或者TA包含恶意代码否则软件攻击也会非常困难。当然TEE本身应当是通过一定级别的认证（EAL2或EAL3，特殊行业手机安全和可信应用开发指南EAL4及以上）而TA也肯定是需要相应机构的认证和簽名才能部署到设备上去的。无论是TEE的认证还是TA的可信管理，都是另外的重量级话题而在此之前，如何实现Rich OS与TEE的通信机制高效的内存共享机制，以及多核架构带来的问题等都是具有挑战性的话题。