2015版-CISP0209软件安全开发_v3.0分析.ppt

  1. 1、本文档共83页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
2015版-CISP0209软件安全开发_v3.0分析

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * 程序内部安全 最小化反馈 避免给予不可靠用户过多的信息 成功或失败 作为跟踪检查的日志可以记录较为详细的信息 认证程序在认证前尽量少给信息(版本) 如果程序接受了密码,不要返回它 避免拒绝服务攻击 输入错误尽快返回 设置超时 延时服务 * 程序内部安全 避免竞争条件 访问共享资源时(文件/变量)没有被适当地控制 使用原子操作 使用锁操作——避免死锁 安全使用临时文件 很多安全漏洞发生在访问已知文件名或可猜测的临时文件时 * 安全调用其他组件 应用程序实际上几乎都不会是自包含的,它们通常都会调用其他组件 底层的操作系统 数据库 可重用的库 网络服务(WEB、DNS) * 安全调用其他组件 组件安全 检查组件文档,搜索相关说明 gets 随机数 使用经过认可的组件 尽可能不调用外部命令,如果不得已要调用,必须严格检查参数 system、open、exec、 * 安全调用其他组件 返回值安全 一定要检查返回值,调用是否成功 成功时检查 返回值,是否按照期望值处理 数据中可能含有 NUL 字符、无效字符或其他可能产生问题的东西 错误时检查 错误码 传递数据安全 视安全需求和安全环境 考虑传输加密,包括密码算法和安全协议 * 禁止使用不安全函数 编码中禁止使用的危险函数举例 禁止使用 strcpy, wcscpy, trcpy, strcpy, _tcscpy, _ftcscpy,_mbscpy strcat, wcscat, trcat, strcat, _tcscat, _ftcscat,_mbscat vsprintf, vswprintf, wvsprintf, wvnsprintf, _vstprintf sprintf, swprintf, wsprintf, wnsprintf, _stprintf gets, _getws, _getts * 安全编译 使用最新版本编译器与支持工具 使用编译器内置防御特性 gcc -Wall -Wpointer-arith -Wstrict-prototypes -O2 * 源代码审核 源代码审核就是检查源代码,检测并报告源代码中的可能导致安全弱点的薄弱之处。 人工审核 费时费力 容易遗漏 工具审核 速度快,自动 可升级知识库 * 源代码审核关注编码中的实现缺陷,通常通过静态分析工具进行,它们扫描源代码,能够发现大约50%的安全问题。 代码审核工具 商业工具 Coverity Fortify Ounce Labs SecureSoftware 免费/开源工具 BOON Cqual Xg++ FindBugs * “好”的源代码分析工具 安全性 安全审核,不要以功能为主 多层性 软件的多层架构、多层平台、多种语言 可扩展性 扩展规则、扩展技术 知识性 主用于分析,开发者也能“学到” 安全编程知识 集成性 支持与IDE集成,支持make、ant等工具 * 知识域:软件安全开发关键工作 知识子域:软件安全编码 理解通用安全编码准则:验证输入、避免缓冲区溢出、程序内部安全、安全调用组件、禁止使用不安全函数等 理解使用安全编译技术对提高编码安全水平的作用,了解常用安全编译技术 理解源代码审核的目的及方式,了解常见源代码静态审核工具 * 为什么要软件安全测试? 软件测试 按照特定规程,发现软件错误的过程。 检查软件是否满足规定的要求,或是清楚地了解预期结果与实际结果之间的差异 其目的在于发现软件中的错误 软件安全测试 有关验证软件安全等级和识别潜在安全缺陷的过程 查找软件自身程序设计中存在的安全隐患,并检查应用程序对非法侵入的防范能力 传统测试仅考虑软件出错时的处理,没有考虑对软件的故意攻击 * 安全测试 在应用投产前,应由独立的安全团队对应用的安全性进行综合评估 功能性安全测试 对抗性安全测试 传统测试方法 白盒测试 黑盒测试 灰盒测试 特定的安全测试手段 模糊测试 渗透测试 * 模糊测试 模糊测试(Fuzz测试) Baron Miller、Lars Fredriksen、Bryan So首次提出 是一种通过提供非预期的输入并监视异常结果来发现软件故障的方法 属于黑盒测试 不关心被测试目标的内部实现 设计输入,检测结果,发现安全漏洞 微软SDL包含了Fuzz测试 * 非常有效的漏洞挖掘技术,已知漏洞大部分都是通过这种技术发现的。 Fuzz测试 强制软件程序使用恶意/破坏性的数据并进行观察结果的一种测试方法 不够强壮的程序会崩溃 编码良好的程序正常运行 特性 方法学 随机值 大量测试用例 查找漏洞或可靠性错误 *

文档评论(0)

441113422 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档