软件工程之美
宝玉
Groupon 资深工程师,微软最有价值专家
44272 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 55 讲
软件工程之美
15
15
1.0x
00:00/00:00
登录|注册

34 | 账号密码泄露成灾,应该怎样预防?

纵深防御
权限最小化
攻击面最小化
原因总结
漏洞分析
应急流程
服务器安全设置
安全部署
安全测试工具
安全性测试
自动化安全测试
代码审查
编码规范
安全设计原则
安全评审
安全设计目标
数据加密
用户身份验证
恶意输入预防
安全需求
风险监控
应对计划
风险量化
风险识别
服务器敏感信息
用户敏感信息
弱用户身份校验
XSS攻击
SQL注入
应对安全问题
避免安全问题
构建安全软件
应对安全问题
上线维护
测试阶段
开发阶段
设计阶段
需求阶段
风险管理策略
数据泄露
假冒身份
恶意输入
消极影响
不确定事件
提升安全性的经验
项目中的安全改进
总结
预防安全问题
安全问题来源
技术风险
课后思考
软件安全问题

该思维导图由 AI 生成,仅供参考

你好,我是宝玉。我们日常总能看到各种与黑客和网络安全相关的新闻,而这其中大部分安全问题都和软件程序有关系。比如说像 CSDN 数据库泄露事件、携程泄露用户银行卡信息事件、有些电商网站用户可以篡改支付购买金额等等。
在软件项目开发时,安全是一个很容易被忽略的问题,但又可能会造成严重损失。所以我们在软件开发时有必要对安全问题引起重视,防患未然,构建安全软件。
今天,我将带你了解一下软件开发中的安全问题,学习如何构建安全的软件,以及出现了安全问题之后该怎么办。

安全问题本质是技术风险

如果你还记得《15 | 风险管理:不能盲目乐观,凡事都应该有 B 计划》这篇文章中的内容,我在其中提到,风险是指不确定的事件,一旦发生,将会造成消极的影响。
安全问题,本质上也是一种技术风险,没发生问题的时候一切都好,一旦发生就会有严重的影响。在对安全问题的应对上,你也可以借鉴对风险管理的方法来改进软件的安全问题,也就是风险识别、风险量化、应对计划和风险监控。
在做风险管理时,首先要做的就是识别风险和对风险量化,对于安全问题,你也可以先思考一下:软件项目中安全问题的主要来源是什么?搞清楚安全问题的来源,以及造成的后果,你就可以对软件中导致安全问题的情况有一个基本的识别和量化。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了构建安全软件的重要性和方法。从需求、设计、开发、测试到上线维护等各个阶段,都提出了相应的安全考虑和解决方案。强调了在整个软件生命周期中重视安全问题的重要性,包括需求阶段的安全需求考虑,设计阶段的安全目标制定,开发阶段的安全编码规范遵循,测试阶段的安全性测试增加,以及上线维护阶段的严格安全设置。此外,还提到了应对真实安全问题的方法,包括设立应急流程、分析漏洞位置和总结原因。总的来说,本文通过深入浅出的方式介绍了软件安全问题的本质和解决方法,对软件开发人员和相关从业者具有一定的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《软件工程之美》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(8)

  • 最新
  • 精选
  • 老师问一个有关code review的问题,code review是指把代码放到大屏幕上大家一起看呢?还是类似github上的合并代码的时候发个pr,然后另一个人对需要合并代码进行检查呢?检查通过后才同意合并请求

    作者回复: 我觉得两种都算Code Review,只是形式不一样。 通常PR这种Code Review应该是贯穿到日常开发过程中的,每个人都可以去Review,有1-2个人Review通过就可以。合并的话不止是Code Review通过,还需要自动测试通过。 而大屏幕这种参与人多,成本高,属于偶尔针对特殊故障分析、学习研讨等目的才做的。

    2019-05-18
    7
  • J.M.Liu
    订单和支付系统的那个例子里,支付系统的结果是返回给客户端,然后由客户端自己校对结果和订单或者把返回结果传给订单服务器校对吗? 这样还是很不安全啊。为什么不是把支付结果返回给服务端呢?

    作者回复: 支付系统通过客户端返回订单系统,订单系统收到后需要再次根据订单跟支付系统确认,之前的漏洞就是出现在这个确认环节,只确认了是否收到,没有确认金额对不对。

    2019-05-22
    3
  • alva_xu
    据我所知,安全测试也分白盒测试和黑盒测试两种,黑盒测试可以用fortify或appscan 来查,白盒测试可以通过code review来完成。在代码方面,写许多规范,即使写得很全,如果用手工测试,也很难确定开发人员是否真的按规范来写代码。所以,一般使用code review的工具来做。老师有没有好的安全代码检查的工具推荐?

    作者回复: 我印象中Fortify也是可以做静态代码检查的。 除了Fortify和AppScan,我知道的还有Veracode、Checkmarx和CodeSecure。 但我没有实际用过,无法推荐哪个更合适。

    2019-05-20
    2
    3
  • 纯洁的憎恶
    与风险管理一样,安全管理也需要从整个工程建设过程中整体考量。站在业务管理者角度,提高系统安全性的措施,可以在业务需求方面尽量避免安全负责度高的方案,在参与技术选型时尽可能兼顾安全要求。

    作者回复: 👍谢谢总结分享

    2019-05-18
    3
  • rocedu
    结合安全开发生命周期(SDL)就更好了。

    作者回复: 👍谢谢娄老师补充。

    2019-05-23
    1
  • calvins
    现在支付都有签名检验,后台金额检验,超时检验,在加https安全很多。

    作者回复: 👍https现在很普及了

    2020-04-07
  • 小老鼠
    所有的Bug都是风险,属于技术风险范畴。

    作者回复: 👍

    2019-10-02
  • ifelse
    我们不能假设数据存储是安全的,而是要考虑到数据是有泄露的可能,提前做好预防措施,对敏感数据进行加密。-"记下来"
    2022-07-05
收起评论
显示
设置
留言
8
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部