- 应用开发生命周期安全管理： - 原理： - 结合应用开发的需求、设计、开发、测试、上线、运维和废弃等生命周期的各阶段，定义安全目标和控制措施，结合评审、测试、培训等手段，保证开发系统的安全性- 原因： - 攻击内容发生了变化 - 病毒蠕虫- 攻击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://blog.csdn.net/qq_41755666/article/details/123450337
版权归原作者 赤赤三 所有， 如有侵权，请联系我们删除。
版权归原作者 赤赤三 所有， 如有侵权，请联系我们删除。