作为开发人员,可以确保您的应用安全的10件事:#9从需求入手

要构建安全的系统,您应该从一开始就考虑安全性。

法律和合规约束

首先,确保团队中的每个人都了解系统的法律和合规性要求以及约束。

法规将推动系统中的许多安全控制,包括身份验证,访问控制,数据机密性和完整性(和加密),审计以及系统可用性和可靠性。


特别是敏捷团队, 不应仅依靠其产品负责人来理解和传达这些要求。 法规遵从性限制可能会施加重要的设计约束,这些约束从业务角度来看可能并不明确,以及保证要求将指示您如何构建和测试并交付系统,以及需要哪些证据来证明您已经完成了负责任的工作。

作为开发人员,您应该尽早了解所有这些对您意味着什么。 首先,Microsoft提供了一个有用而简单的指南(《 法规遵从性神秘化:开发人员合规性简介》 ),该指南解释了包括SOX,HIPAA和PCI-DSS在内的常见业务法规以及它们对开发人员的意义。

跟踪机密数据

大多数监管框架中的基本问题是控制和保护数据。
确保每个人都了解哪些数据是私有/机密/敏感的,因此需要受到保护。 在整个系统中识别并跟踪此数据。 谁拥有数据? 什么是保管链? 数据来自哪里? 来源可以信任吗? 数据要去哪里? 您可以信任目的地来保护数据吗? 数据在哪里存储或显示? 是否必须存储或显示? 谁有权创建,查看,更改它,是否需要跟踪和审查这些操作?

这些问题的答案将推动对系统中数据验证,数据完整性,访问控制,加密以及审核和日志记录控制的需求。

应用程序安全控制

考虑一下应用程序的基本功能安全控制: 身份验证访问控制审计 -我们在本系列文章的前面已经介绍了所有这些功能。 这些控件需要在哪里添加? 需要编写哪些安全故事? 如何测试这些控件?

可以滥用业务逻辑

还需要在业务逻辑中考虑安全性,特别是处理金钱或其他有价值的物品或处理私人或敏感信息或命令和控制功能的多步骤应用程序工作流。 诸如在线购物车,在线银行帐户交易,用户密码恢复,在线拍卖竞标或在线交易和root管理员功能之类的功能都是潜在的攻击目标

这些功能的用户案例或用例应包括异常和失败情况(如果某个步骤或检查失败或超时,或者用户尝试取消或重复或绕过某个步骤,会发生什么情况?)以及源自“ 滥用案例 ”的要求”或“ 滥用案例 ”。 滥用案例探讨了攻击者可能如何颠覆应用程序的检查和控件,或者如何发挥功能,查找常见的业务逻辑错误,包括检查时间/使用时间,其他竞争条件和时序问题,密钥或地址的熵不足信息泄漏 ,无法防止暴力破解 ,无法执行工作流程排序和批准,以及输入数据验证和错误/异常处理以及限制检查中的基本错误。

这不是防御黑暗技术的黑帽魔术,但弄错这些东西可能会极具破坏性。 有关一些有趣的例子,这些例子说明了坏人如何利用应用程序逻辑中的小错误(通常只是愚蠢的错误),请阅读耶利米·格罗斯曼(Jeremiah Grossman)的经典论文“ 使网站面临风险的七个业务逻辑缺陷 ”。

在编写故事或功能需求时,花点时间浏览重要的滥用案例,并确保仔细阅读此代码,并包括额外的手动测试(尤其是探索性测试 )以及对这些功能的笔式测试,以捕捉严重的业务逻辑问题。
我们离终点线很近。 本系列的最后一篇文章即将发布:Design and Architect Security In。

翻译自: https://www.javacodegeeks.com/2014/07/10-things-you-can-do-as-a-developer-to-make-your-app-secure-9-start-with-requirements.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值