应用系统安全通用技术要求(转发)

× 文章目录
  1. 1. 1 标识与鉴别
    1. 1.1. 1.1 身份标识
    2. 1.2. 1.2 基本身份鉴别
    3. 1.3. 1.3 重鉴别
    4. 1.4. 1.4 图形验证码
    5. 1.5. 1.5 防暴力猜测
    6. 1.6. 1.6 鉴别数据保护
    7. 1.7. 1.7 管理安全
    8. 1.8. 1.8 统一认证
  2. 2. 2 授权与访问控制
    1. 2.1. 2.1 访问控制
    2. 2.2. 2.2 权限最小化
    3. 2.3. 2.3 禁止默认账号
    4. 2.4. 2.4 统一授权
  3. 3. 3 会话管理
    1. 3.1. 3.1 会话超时
    2. 3.2. 3.2 并发控制
    3. 3.3. 3.3 防重放
    4. 3.4. 3.4 会话安全
  4. 4. 4 数据安全
    1. 4.1. 4.1 数据传输安全
    2. 4.2. 4.2 数据存储及展示安全
    3. 4.3. 4.3 参数保护
    4. 4.4. 4.4 密钥及加密算法安全要求
  5. 5. 5 软件容错和异常管理
    1. 5.1. 5.1 验证方式
    2. 5.2. 5.2 限制及验证内容
    3. 5.3. 5.3 异常管理
    4. 5.4. 5.4 第三方组件安全
  6. 6. 6 安全审计
    1. 6.1. 6.1 审计事件类型
    2. 6.2. 6.2 审计内容
    3. 6.3. 6.3 审计日志管理
    4. 6.4. 6.4 审计日志分析及告警
  7. 7. 7 应用安全禁止项
  8. 8. 8 移动APP安全
    1. 8.1. 8.1 Android客户端
    2. 8.2. 8.2 iOS客户端
    3. 8.3. 8.3 客户端数据安全
    4. 8.4. 8.4 通信安全
    5. 8.5. 8.5 密码策略安全
    6. 8.6. 8.6 APP服务端安全
  9. 9. 9 微信应用安全
  10. 10. 10 大数据系统安全

转发自 https://github.com/aka99/sdl/blob/master/appsecreq.md

1 标识与鉴别

1.1 身份标识

应用系统的管理员及普通用户应具有明确的身份标识(账号):

  • a) 身份标识应具有唯一性,保证应用系统中不存在重复身份标识;
  • b) 身份标识应不可预测,如递增的序列号等;
  • c) 将身份标识与审计记录关联;
  • d) 应支持角色定义,角色的权限管理,用户的角色管理等;
  • e) 授权管理员能够增加、修改、删除账号和角色;
  • f) 账号异常时(如登录过于频繁、长时间未登录等),应支持管理员后台锁定用户账号。

1.2 基本身份鉴别

应用系统应对管理员及普通用户的身份进行鉴别:

  • a) 应采用至少一种方式对管理员及用户身份进行鉴别:如用户名/密码、USBkey、证书、动态密码等;
  • b) 若通过用户名/密码进行鉴别,必须支持:
    • 1) 密码长度限制(至少8位);
    • 2) 复杂度限制(如包含字母、数字和特殊字符);
    • 3) 支持弱密码检查,不得使用常见的弱密码,如!QAZ2wsx、test1234等;
    • 4) 用户应能修改自身密码,管理员可修改自身密码,用户管理员可重置其它账号密码;
    • 支持密码长度及复杂度要求配置;
    • 6) 支持密码有效期检查,到达密码有效期后应提醒用户修改密码;
  • c) 若采用USBkey、动态密码令牌等进行身份鉴别,应具有PIN码保护;
  • d) 对互联网接入的重要系统应采用两种或两种以上的方式进行鉴别。

1.3 重鉴别

执行重要操作或者敏感信息修改时,需对用户进行重鉴别或结合其它途径进行鉴别:

  • a) 涉及交易功能、账号重要关联信息(密码、身份证件号、关联的手机号/邮箱等)修改时应对用户再次进行身份认证;
    • b) 若支持密码找回功能,需通过账号绑定的手机或邮箱发送随机证码方式进行二次鉴别。

1.4 图形验证码

对于通过电脑自动操作可能会带来危害的页面,需采用验证码措施,防止电脑自动识别:

  • a) 至少以下页面需采用图形验证码:注册页面、短信及邮箱认证页面、限时抢购类等;
  • b) 图形验证码应采取一定的干扰措施且不可预测,如字体倾斜,加背景噪点、横线等;
  • c) 需由服务端生成并进行验证,不得在页面源文件返回;
  • d) 验证码应具有有效期,建议为5分钟。

1.5 防暴力猜测

应用系统应具备防止密码、验证码等的暴力猜测功能:

  • a)防密码暴力猜测:对采用密码进行鉴别的系统,因防止密码暴力猜测,连续失败登录后锁定账号。账号锁定后可以由系统管理员解锁,也可以在一段时间后自动解锁;
  • b)防验证码暴力猜测:若系统具备验证码功能,应具有防止验证码暴力猜测措施。如验证码连续错误一定的次数后,锁定该主机继续猜测或者锁定主机IP地址等。

1.6 鉴别数据保护

应用系统应具备鉴别数据保护功能,具体技术要求如下:

  • a) 鉴别数据加密存储;
    • 1) 尽可能不在客户端存储密码,若有必要,如cookie中暂存,应以加密方式存储;
    • 2) 服务器或数据库中以摘要值方式存储:使用Hash+Salt,使用SHA2及以上强度的Hash算法。
  • b) 鉴别数据加密传输:可采用加密的传输通道,或者对密码以摘要方式传输。

1.7 管理安全

应用系统应支持管理员设置可信管理主机的IP地址,仅通过可信主机能够登录应用系统进行管理; 后台管理界面不应向互联网暴露。


1.8 统一认证

**内部、外部人员应采取统一认证:

  • a) 内部人员使用的应用系统应采用独立集中认证(SSO);
  • b) 外部人员使用的应用系统应采用独立集中认证(SSO)。

2 授权与访问控制

2.1 访问控制

应用系统应提供基于主体(动作执行者,通常为账号、应用程序等)、客体(动作的受体,如接口、文件、数据、菜单功能等)及操作内容的访问控制功能:

  • a) 访问控制的覆盖范围应包括与资源访问相关的主体、客体及它们之间的操作:
    • 1) 主体:应支持用户、用户组,或者依据公司的组织架构;
    • 2) 客体:基于业务需求及菜单的各项子功能,如用户管理、权限管理、业务操作、审计管理、数据范围等;
    • 3) 操作:应支持可读、读写等。
  • b) 访问控制的细粒度应满足业务上最小授权的需求;
  • c) 权限控制策略严格有效,防止任何越权操作。任何操作执行前,应对操作主体、客体并依据访问控制规则进行检查。

2.2 权限最小化

应对用户/管理员、数据库连接等应采取最小权限原则:

  • a) 不应具有超级账号(同时具有操作、审计等应用系统的全部权限);
  • b) 至少支持将操作用户及审计用户权限分离;
  • c) 与数据库连接的账号应为数据库普通权限账号,只能访问允许的数据库和表;
  • d) 应用启动进程的权限尽可能小。应用使用的系统账号(运行环境中的)应该有尽可能低的权限。不使用“Administrator”、“root”、“sa”、“sysman”、“Supervisor”或其它所有的特权用户被用来运行应用程序或连接到网站服务器,或中间件。

2.3 禁止默认账号

应用系统不应具有默认账号(固化在应用系统中的账号,且不可修改)。

2.4 统一授权

应用系统应支持集中统一授权。


3 会话管理

3.1 会话超时

应用系统应具有会话超时机制:

  • a) 管理界面及业务界面应具有超时退出机制;
  • b) 超时时间管理员可配置,交易页面不超过5分钟。

3.2 并发控制

应用系统应对会话并发进行控制:

  • a) 应能对系统最大并发会话连接数进行限制;
  • b) 应能对单个账号的多重并发(同一账号同时在不同的终端上登录)进行限制,出现重复登录时,给出明确提示;
  • c) 应能对系统的连接频率进行限制。

3.3 防重放

应用系统应采取时间戳、序列号等措施防止重放攻击及重复提交:

  • a) 防鉴别信息重放:应具备防止通过重放抓取的鉴别数据报文或者cookie绕过身份验证过程;
  • b) 防止交易数据重复接收处理:应具备防止因网络因素或人为有意行为的交易数据重复接收处理。

3.4 会话安全

应采取措施保证http(https)的会话安全:

  • a) 应保证cookie安全性:如启用HttpOnly属性,使用临时性Cookie取代永久性Cookie,不使用Cookie定制信息,敏感Cookie需加密保存,HTTPS协议下应启用Secure属性;
  • b) 用户注销会话后,不能通过使用浏览器的回退按钮来显示;
  • c) 用户登录后需要使用新的会话标识,并且会话标识的生成应具有随机性。

4 数据安全

4.1 数据传输安全

应采取措施保证服务器与客户端数据传输安全:

  • a) 对于互联网传输的敏感信息应采取加密方式传输;
  • b) 互联网传输的BS架构应用应采用VPN链路加密或HTTPS(应采用TLS加密);
    • c) 互联网传输的CS架构应用应采用加密方式传输;
    • d) 对涉及资金交易的传输内容应采取完整性保护措施;
  • e) 对涉及资金交易的传输内容应采取抗抵赖措施。

4.2 数据存储及展示安全

采取措施保证服务器及客户端存储的敏感信息的安全:

  • a) 服务端的敏感数据应保存在数据库中,特别敏感(如身份鉴别数据、客户隐私信息等)的内容应在数据库中加密存储;
  • b) 服务端及客户端保存敏感信息的非数据库文件应加密存储;
  • c) 非业务上的必要,敏感信息在终端上展示时应做模糊处理,如部分内容以方式传输及显示;
  • d) 日志审计记录中不能记录敏感信息,如鉴别信息、完整交易信息、银行卡相关信息等。

4.3 参数保护

应采取措施保证参数安全:

  • a) 不得在代码中对敏感信息进行硬编码,如数据库连接参数等;
  • b) 必要时需要配置Robots.txt,列出允许爬虫访问范围,防止访问敏感数据;
  • c) 使用HTTP POST方法代替GET方法来提交表单,禁止使用表单的隐藏字段来传递敏感信息;不依赖HTTP头信息,对客户端提交的HTTP头进行过滤;
  • d) BS应用页面源文件中不得包含敏感信息:如开发人员信息、内部地址及路径等;
  • e) 内容安全,如:对公开发布的内容、在论坛或留言时需要对关键字和敏感字进行过滤。

4.4 密钥及加密算法安全要求

应保证秘钥分发存储及加密算法的安全:

  • a) 应保证密钥的存储、传输安全;
  • b) 密钥保存在终端时应定期更换;
  • c) 系统所采用的各类加密算法(对称算法、非对称算法、摘要算法等)应使用安全的加密算法:
  • d) 不得使用自定义算法。

5 软件容错和异常管理

5.1 验证方式

应对客户端提交的表单、文件等进行验证:

  • a) 对来自系统之外的任何数据进行有效性验证,包括但不限于:客户端提交的任何数据(URL、表单、文件、HTTP协议头等标准协议的扩展内容等)、通过应用 接口接收的数据、通过文件共享/应用接口等主动获取的数据等;
  • b) 采用白名单方式进行验证,仅允许规则允许的内容,对无法识别的内容默认禁止;
  • c) 可采取客户端对通过人机接口输入的内容进行初步验证方式;
  • d) 对所有外部进入的数据均需由服务端进行有效性验证;
  • e) 应采用标准的、统一的筛选器对内容进行检查验证。

5.2 限制及验证内容

限制及验证内容应包括以下方面:

  • a) 数据的字符类型、长度、格式和范围,防止缓冲区溢出及其他不可预知的异常;
  • b) 文件的类型格式、大小等;
  • c) 已知的有害输入,如例如“’”,“–”,“&”,“<”,“>”,“/”,“=”,“#”,“\r\n”,“\n\n”,“;”等字符,防止常见的SQL注入、XSS、等攻击行为;
  • d) 对常见编码格式进行检查,防止通过转换编码逃避验证。

5.3 异常管理

当系统出现故障时,应避免敏感信息泄露及保存详细错误信息,出现故障时:

  • a) 向客户端及人机界面以最小原则反馈出错提示(如错误ID),避免泄露敏感信息;
  • b) 系统后台应保存详细的错误信息,足以支持运维人员及开发人员对故障进行分析定位。

5.4 第三方组件安全

应用系统若采用第三方组件(如Apache、tomcat等中间件,数据库,struct2、jQuery、ewebeditor、fckeditor等应用组件,.net、java运行环境等),应保证其安全:

  • a) 需从可信途径获取第三方组件的安装程序;
  • b) 采用不存在已知安全漏洞的第三方组件版本;
  • c) 对第三方组件进行安全加固配置:如删除非必要的默认页面、关闭调试模式、过滤详细的错误信息反馈等。

6 安全审计

6.1 审计事件类型

各应用系统分别进行用户管理过程的日志记录,包括用户的管理行为、登录行为等,确保系统操作行为可追溯,具体如:

  • a) 鉴别事件:通过人机界面及应用接口等所有的鉴别事件,包括成功和失败事件;
  • b) 用户非授权访问尝试操作;
  • c) 账号操作:包括增加、修改、删除等;
  • d) 客户数据批量导出操作;
  • e) 其它重要操作内容,如数据查询及导出、重要参数修改;
  • f) 系统运行事件:系统启动、重启、停止及运行过程中各种可能的异常情况。

6.2 审计内容

每个审计记录中至少记录如下信息:

  • a) 事件的主体:如用户、进程名等;
  • b) 事件的日期、时间;
  • c) 事件来源:如请求的IP地址,MAC地址;
  • d) 事件类型;
  • e) 事件内容;
  • f) 事件结果(可包含在事件内容中):成功或者失败。

6.3 审计日志管理

应用系统应具备安全审计功能,日志管理要求如下:

  • a) 只允许授权管理员访问日志;
  • b) 授权管理员支持对日志存档、删除和清空的权限;
  • c) 提供能查阅日志的工具,并且只允许授权管理员使用查阅工具;
  • d) 提供对审计事件一定的检索能力,检索条件包括时间、日期、主体ID、客体ID等;
  • e) 支持以标准格式(如Syslog、SNMP等)方式把日志数据外发到统一日志服务器。

6.4 审计日志分析及告警

涉及交易、支付类的关键应用系统应提供一定的日志分析及告警功能:

  • a) 应有一套规则对审计日志进行分析,发现可能存在的异常,如
    • 1) 登录异常:非业务时间登录、非可信地址范围内登录、连续登录失败、登录过于频繁等
      • 2) 用户行为异常:持续尝试访问非授权内容、业务数据批量导出等;
      • 3) 系统状态异常:功能模块异常、并发数异常、服务水平过低等。
  • b) 提供分析接口,管理员可自定义分析规则对审计日志进行分析;
  • c) 分析出潜在的危害行为应及时向管理员告警:页面告警、弹出对话框、email告警等;
  • d) 定期向审计管理员发送统计分析报表。

7 应用安全禁止项

系统页面不应存在以下常见安全漏洞:

  • a) 用户注册邮箱或手机短信认证存在被绕过的逻辑缺陷;
  • b) 密码找回功能存在被绕过的逻辑缺陷;
  • c) XSS及跨站请求伪造(CSRF)漏洞;
  • d) 各类注入漏洞(包括SQL注入等)。

8 移动APP安全

8.1 Android客户端

应采取措施保证Android客户端安全:

  • a) 反编译保护。在将源代码编译成apk时,应对其进行代码混淆操作,如采用Android sdk自带的proguard或商业混淆软件,以防止apk被反编译成易懂的源码。
  • b) 应用完整性检验。应对APP添加自身完整性检测功能,以防御其被第三方非法篡改。如对自身计算哈希值(md5/sha1/sha256)并进行校验。
  • c) Activity界面劫持。应对APP添加运行时顶层activity界面检测机制,以防御activity界面劫持攻击。
  • d) 内存保护。APP在运行过程中,不在内存中保存用户敏感信息(如卡号、密码等),或将敏感信息加密后保存,并在使用后及时清除。
  • e) 动态调试。APP应能够防动态调试,可选择自行开发反调试功能(如检测系统是否运行了常用的调试工具)。
  • f) 进程注入。APP应能够防进程注入,开发可选择自行开发防动态注入功能。
  • g) 组件安全。应合理设置APP组件的exported属性,防止APP自身不必要的组件暴露。
  • h) 软键盘安全。对敏感数据(如密码输入、卡号输入)输入的地方,应开发并调用自定义软键盘,以防御键盘劫持攻击。
  • i) 软键盘增强安全。对于使用的自定义软键盘,应使软键盘按键随机分布,且应取消其按键点击回显,或缩短其回显时间。(适用于支付等场景)
  • j) 手势密码认证。对于重要的APP,应根据业务需要,添加手势密码认证机制,以防御被非法访问。
  • k) 建议自研或采用第三方加壳技术进行保护。

8.2 iOS客户端

应采取措施保证iOS客户端安全:

  • a) 应用完整性检验。应对APP添加自身完整性检测功能,以防御其可被第三方非法修改;或者检测iOS设备是否越狱,以进行风险提醒。
  • b) 动态调试和注入。APP应能够防动态调试,可选择自行开发反调试功能(如检测系统是否运行了常用的调试工具),或者检测iOS设备是否越狱,以进行风险提 醒。(适用于交易类APP)
  • c) 内存保护。APP在运行过程中,不在内存中保存用户敏感信息(如卡号、密码等),或将敏感信息加密后保存,并在使用后及时清除。或者检测iOS设备是否越 狱,以进行风险提醒。(适用于交易类APP)
  • d) 软键盘增强安全。对于使用的自定义软键盘,应使软键盘按键随机分布,且应取消其按键点击回显,或明显缩短其回显时间。(适用于支付场景)
  • e) 手势密码认证。对于重要的APP,应根据业务需要,添加手势密码认证机制,

8.3 客户端数据安全

应采取措施保证客户端数据安全:

  • a) 数据文件安全。应当不在APP客户端本地文件保存用户敏感数据(如密码、卡号、证件号等),或者采用安全加密算法(如AES/SHA256等)加密后再保存;
  • b) 数据库安全。应对数据库添加访问口令,防御其他APP的直接访问;
  • c) 应用日志安全。在APP编译打包成正式安装包时,应删除或注释掉源代码里的日志打印语句,以防止不必要的日志信息泄露。

8.4 通信安全

应采取措施保证App通信全:

  • a) 通信加密。应使用加密通信通道(HTTPS)进行用户敏感信息(如登录密码、交易密码等)的传输。
  • b) 关键字段单独加密(增强要求)。对于需要传输的敏感或重要的字段信息(如登录密码、交易密码、卡号等),应进行加密(如AES、 SHA256等)后再进行传输。
  • c) 数据包完整性校验(增强要求)。对重要通信数据包(如转账、交易等),应对数据包进行完整性签名,并在服务端进行校验,以防止传输过程中被篡改。
  • d) 证书合法性校验。当APP采用HTTPS协议进行数据传输时,APP应对接收到的TLS证书进行合法性校验(适用于转账、交易等场景)

8.5 密码策略安全

应采取措施保证密码策略安全:

  • a) 密码复杂度测试。 应根据业务需要,在服务端后台添加密码复杂度检测机制,如限制密码长度、大小写、特殊字符等。
  • b) 帐号锁定策略。应根据业务需要,在服务端后台添加账号登录失败锁定机制(如连续登录失败5次即锁定),或在登录页面处添加图形验证码机制,以防御暴力破解攻击。
  • c) 帐号登录限制。应根据业务需要,在服务端后台添加账号登录检测机制,限制同一账号的多终端同时登录。

8.6 APP服务端安全

服务端安全参照5.1~5.7要求。


9 微信应用安全

对于微信应用,应严格检查提交的请求及接口的安全:

  • a) 接口安全:应保证接口安全,防止非授权对象调用;
  • b) 以白名单方式对来自接口的任何请求数据,禁止任何不能识别的内容。

服务端安全参照5.1~5.7要求。


10 大数据系统安全

大数据系统,应采取以下措施保证其安全:

  • a) 可扩展性:系统设计上应具有良好的扩展性,可根据业务需要增加节点,业务数据能够自动迁移;
  • b) 冗余部署:业务数据应冗余存储,单节点故障不影响系统的正常运行,且不会导致数据丢失;
  • c) 数据筛选:对进入系统的数据依据相应的规则进行检查,去除无用数据;
  • d) 去隐私化:对非业务上必要的隐私数据,如身份证、客户详细信息等,应采取一定的去隐私化处理;
  • e) 监控平台:应相应部署大数据库监控平台,对系统的运行状态等进行实施监测。

服务端安全参照5.1~5.7要求