安全开发生命周期

应用开发生命周期安全管理：
- 原理：
  - 结合应用开发的需求、设计、开发、测试、上线、运维和废弃等生命周期的各阶段，定义安全目标和控制措施，结合评审、测试、培训等手段，保证开发系统的安全性
- 原因：
  - 攻击内容发生了变化
    - 病毒蠕虫
    - 攻击OS、DB
    - APT攻击社会工程学
    - 攻击应用系统
  - 攻击对象发生了变化
  - 缺乏安全开发技能
  - 运维阶段无法解决开发问题
    - 应用程序代码问题（SQL注入、XSS）
    - 应用系统安全设计失效（验证码绕过）
    - 应用系统安全需求考虑不充分（密码保护）
    - 基础环境漏洞（Apache struts2 ssl）
    - 应用服务配置不当（IIS、nginx、Jboss）
- 安全开发管理带来的收益：
  - 减少漏洞数量、提高系统安全性
  - 降低上线压力，保证项目进度
  - 降低安全和运维人员压力
  - 规范应用开发各个环节，提高开发人员技能
  - 理顺业务、开发、安全部门之间关系
- 业界标准：
  - 微软（SDL）| 最广泛：
    - 培训、需求、设计、实施、测试、发布、响应
  - 思科（CSDL）：
    - 安全设计
      - 安全需求
      - 威胁建模
    - 安全开发
      - 安全开发流程
      - 安全开发工具
    - 渗透测试
      - 设计验证
  - NLST：
    - 开始——>获取和开发——>执行——>操作和维护——>发布阶段部署
  - OWASP：
- 详细流程：
  - 图示：
    - 过程：
      - 需求分析（安全需求工程）——>设计：设计安全——>实现：安全编码（输入过滤、输入编码、输出过滤、输出编码）——>测试：软件黑盒测试，渗透性测试，代码安全审计（XSS测试，可手工也可以结合自动工具）——>发布：补丁管理配置加固（IDS/IPS、web应用防火墙、客户端浏览器安全加固）
  - 需求分析 | 如果数据在传输过程中没有加密，就有可能被截获、篡改：
    - 注意：
      - 识别关键安全目标
      - 安全目标路线图
    - 分析：
      - 分析业务系统非功能性安全需求
      - 自查规范、分析依据、安全需求分析报告
      - 分析业务场景、描述安全需求、记录安全需求的具体要求
    - 安全需求：
      - 身份验证：启用身份认证功能、口令策略、账号锁定、验证码等功能
      - 会话管理：严格会话管理，确保会话的安全性、唯一性、完整性
      - 访问控制：程序设计时，需要限制对连接数、内存、文件等资源的访问
      - 权限管理：应用程序需具备账号管理功能，不同账号、不同角色具备不同权限
      - 数据保护：敏感信息、配置文件等重要信息的保存、通信
      - 安全审计：应用程序访问需支持记录程序启动、关闭事件、应用程序访问事件、程序出错事件等
      - 输入验证：对客户端提交的输入，后台程序进行严格的检查
      - 输出处理：应用程序需要限制输出的内容，特别是敏感信息、错误信息、用户输入的内容等
      - 白盒测试、黑盒测试：需要检查应用程序开发过程中，特意留下可绕过系统安全控制的功能或超级弱口令
      - 内存管理：程序需具有内存管理和控制的功能，限制恶意的使用
      - 异常处理：程序在出现异常时，应具有避免信息泄露的措施
  - 设计阶段 | 采用HTTPS对通信数据进行加密，以保障数据的保密性：
    - 注意：
      - 定义安全架构
      - 确定受攻击面
      - 识别威胁
      - 定义安全交付标准
    - 分析：
      - 确保设计方案覆盖所有安全需求、定义系统安全架构、识别威胁
      - 安全设计指南、系统（安全）架构设计说明书、安全设计评审报告
      - 描述系统安全架构、接口、数据规范等 | 威胁建模、识别威胁和消减措施
    - 设计安全：
      - 身份认证的设计：
        
        用户身份认证的强度设计
        
        对高价值和进入保护区域的用户需要进行重新认证
        
        认证失败后的处理方式设计
        
        使用强口令策略
        
        使用图片验证码
        
        敏感信息加密处理
      - 访问控制设计：
        
        限制普通用户对资源的访问
        
        应用软件启动权限最小化
        
        敏感功能IP地址控制
        
        尽量采用统一的访问控制机制
        
        资源请求数量限制
        
        在服务端实现访问控制
      - 会话管理设计：
        
        限制会话寿命
        
        确保会话的安全创建
        
        确保会话数据的存储安全
        
        确保会话的安全终止
        
        web页面应避免跨站请求伪造
        
        web系统确保会话凭证的安全
      - 数据存储与传输的设计
        
        尽量避免明文储机密信息
        
        避免在代码中存储机密信息
        
        web系统，不要永久性cookie中存储敏感信息
        
        web系统，不要使用HTTP-GET协议传递敏感数据
        
        避免在配置文件中明文存储数据库连接、口令或密钥
        
        确保通信通道的安全
        
        禁止自创加密算法
      - 日志设计：
        
        审核日志应包含时间、内容、来源等关键要素
        
        审核日志应禁止包含用户口令等隐私信息
        
        限制对日志数据的访问：应将有权操作日志数据的个人数量减到最下，只为高度信任的账号（如管理员）授予访问权限
        
        定期备份和日志数据的分析
        
        确保日志数据的安全：
        
        日志文件禁止存放在web网页目录下，防止客户端能够访问到日志
        
        根据业务平台的重要性，设定日志存储保留的时间
        
        防止业务日志欺骗
  - 实施开发 | 避免采用特定危险API如strcpy、sprintf避免缓冲区溢出漏洞：
    - 注意：
      - 应用编码规范
      - 使用安全测试工具
      - 使用代码分析工具
      - 代码安全人工审核
    - 开发安全：
      - 输入验证：
        
        对所有的输入进行安全验证：
        
        要对所有来源不在可信任范围内的输入进行验证，包括来自用户、服务、共享文件、用户和数据库的输入
        
        对web系统，需要验证HTTP请求消息的全部字段，例如：GET数据和POST数据，Cookie和Header数据等
        
        验证除数据内容外，需限定数据的大小或长度
        
        验证所有输出到客户端的内容，输出数据HTML编码
        
        尽量采用集中验证的方法：
        
        如条件允许，将输入验证策略作为应用程序设计的核心元素，并采用集中性验证方法，例如：可通过使用共享库中的公共验证模块。这可确保验证规则的一致性。此外还能减少开发的工作量，有助于后期的维护工作
        
        对于web应用，需要编写统一的对于客户端提交数据的验证接口，集中处理输入数据
        
        应采取严格的输入验证方法：
        
        验证数据类型，例如预期输入类型为证书，则需要禁止输入英文字符串
        
        验证数据类型长度是否在预期长度范围内
        
        验证数值类型是否在预期大小边界内
        
        对于web应用，检查数据是否包含特殊字符，如：<、>、"、'、%、(、)、&、+、\、\'、\"等
        
        尽量使用白名单进行输入检查。
        
        需在服务端进行验证
        客户端脚本可以篡改，如果为了顾全体检，部分数据一定要用服务器验证
        
        注意规范化问题
        
        确保没有绕过检查
      - 访问数据库：
        
        最小化数据库权限
        应用软件使用的数据库账号必须是普通权限账号，且只能访问允许的数据库
        
        严格控制对数据库查询等操作：
        应使用支持严格数据类型验证的参数化查询方式（如prepareStatment），使查询和数据分离。或者，对数据库sql语句中来自不可信任范围内的输入参数进行验证
        
        验证数据库返回的数据：
        要求对来自数据库的数据进行验证，确保其格式正确且能够安全的使用，不能盲目的信赖数据库
        
        确保释放数据库资源
      - 文件操作：
        
        限制文件上传
        
        尽量不向普通用户开放文件上传权限。如确实需要上传，应限制上传文件的大小、类型、路径，防止攻击者将恶意攻击程序上传到服务器中
        
        对B/S结构的web程序，使用文件上传功能，需限制上传目录的脚本执行权限
        
        限制文件下载：
        禁止下载应用系统本身的配置和数据
        
        避免泄露路径信息：
        禁止向客户端返回服务器端文件和目录的绝对路径信息
        
        防范路径遍历：
        在根据客户端输入访问服务器端的文件时，应防止通过真实的文件名来访问文件，应使用索引值来映射实际的文件路径。如确实需要在参数中出现文件名时，则应对文件名进行白名单检查。禁止在参数中出现../、..\等特殊字串及变形
        
        web应用程序中防范动态文件包含
        禁止在脚本的动态包含功能中直接使用用户提交的数据和文件。
      - 异常处理：
        
        web系统，对所有的异常构造统一的错误页面，包括HTTP错误和未经处理的异常。能够防止攻击者从应用程序的默认出错页面中得到系统信息
        
        发生错误异常时，应记录详细的日志信息，同时确保没有记录口令或其他敏感数据
        
        捕捉异常，这样做可以避免将应用程序置于不协调的状态，它有助于保护应用程序免受拒绝服务攻击
        
        程序发生异常时，应终止当前业务办理，并对当前交易进行回滚操作，保证业务的完整性和有效性；必要时可以注销当前用户会话。
      - 其他问题：
        
        变量应在使用前进行初始化，确定是全局、局部变量。
        
        留意字节大小差异、精度、符号数/非符号数的区别、舍位阶段问题、不同类型数据的转化、非数值运算、极值处理等问题，避免意外的变量使用和运算导致流程的改变
        
        函数、类调用时应检查返回值，避免异常发生。
        
        在使用随机数时，要选择合适的随机算法和设置合适的随机数，避免被猜解。
        
        对于和业务开发无关的第三方代码库或者库文件应严格限制使用，使用第三方代码或库文件时，需要进行安全性检查，避免由此导致的安全隐患
        
        web应用，需尽量避免使用HTTP-GET方式请求数据
  - 测试验证 | 通过动态构建SQL语句以证明对用户输入进行了严格过滤，避免了SQL注入攻击：
    - 注意：
      - 代码安全审核
      - 集中式安全测试
      - fuzzing测试
      - 基线检查
      - 渗透测试
    - 测试阶段：
      - 保证系统符合安全规范和要求，在上线前消除安全隐患
      - 测试用例、渗透测试、代码审计等安全测试报告
      - 应用系统安全测试、集成环境安全测试、修复后复测
    - 安全培训：
      - 开发测试类：
        
        web应用安全之安全测试
        
        web安全开发培训
        
        安全测试工具介绍
      - 安全意识类：
        
        信息安全形式和案例分析
        
        社会工程学和钓鱼攻击防范
      - 攻击防御类：
        
        web应用安全之常见威胁
        
        流行攻击与防御手段
        
        攻击路径分析
  - 发布阶段 | 入侵者通过JSP程序提交上传了页面文件，清除木马程序并提供整改建议：
    - 集成环境测试
    - 最终安全评审
  - 维护阶段：
    - 定期安全评估
    - 应急响应
    - 发布漏洞解决方案

文章来源地址https://uudwc.com/A/AAkZr