c#可以开发ios应用吗
要构建安全的系统,您应该从一开始就考虑安全性。
法律和合规约束
首先,确保团队中的每个人都了解系统的法律和合规性要求以及约束。
法规将推动系统中的许多安全控制,包括身份验证,访问控制,数据机密性和完整性(和加密),审计以及系统可用性和可靠性。
敏捷团队尤其不应仅依靠其产品负责人来理解和传达这些要求。 法规遵从性限制可能会强加一些重要的设计约束,这些约束从业务角度来看可能并不清晰,以及保证要求将指示您如何构建和测试并交付系统,以及需要哪些证据来证明您已经完成了负责任的工作。
作为开发人员,您应该尽早了解所有这些对您意味着什么。 首先,Microsoft提供了一个有用而简单的指南(《 法规遵从性神秘化:开发人员的遵从性简介》 ),该指南解释了包括SOX,HIPAA和PCI-DSS在内的常见业务法规及其对开发人员的意义。
跟踪机密数据
大多数监管框架中的基本问题是控制和保护数据。
确保每个人都了解哪些数据是私有/机密/敏感的,因此需要受到保护。 在整个系统中识别并跟踪此数据。 谁拥有数据? 什么是保管链? 数据来自哪里? 来源可以信任吗? 数据要去哪里? 您可以信任目的地来保护数据吗? 数据在哪里存储或显示? 是否必须存储或显示? 谁有权创建,查看,更改它,并且是否需要跟踪和审查这些操作?
这些问题的答案将推动对系统中的数据验证,数据完整性,访问控制,加密以及审核和日志记录控制的需求。
应用程序安全控制
考虑一下应用程序的基本功能安全控制: 身份验证 , 访问控制 , 审计 -我们在本系列文章的前面已经介绍了所有这些。 这些控件需要在哪里添加? 需要编写哪些安全故事? 这些控件将如何测试?
可以滥用业务逻辑
还需要在业务逻辑中考虑安全性,特别是处理金钱或其他有价值的物品,或处理私人或敏感信息或命令和控制功能的多步骤应用程序工作流。 诸如在线购物车,在线银行帐户交易,用户密码恢复,在线拍卖竞标或在线交易和root管理员功能之类的功能都是潜在的攻击目标 。
这些功能的用户案例或用例应包括异常和失败情况(如果某个步骤或检查失败或超时,或者用户尝试取消或重复或绕过某个步骤,会发生什么情况?)和源自“ 滥用案例 ”的要求”或“ 滥用案例 ”。 滥用案例探讨了攻击者如何颠覆应用程序的检查和控件,或者如何发挥功能,查找常见的业务逻辑错误,包括检查时间/使用时间,其他竞争条件和时序问题,密钥或地址的熵不足 , 信息泄漏 ,无法防止暴力破解 ,无法执行工作流程排序和批准,以及输入数据验证和错误/异常处理以及限制检查中的基本错误。
这不是防御黑暗技术的黑帽魔术,但是弄错这些东西可能会造成极大破坏。 有关一些有趣的例子,这些例子说明了坏人如何利用应用程序逻辑中的小错误(通常只是愚蠢的错误),请阅读耶利米·格罗斯曼(Jeremiah Grossman)的经典论文“ 使网站面临风险的七个业务逻辑缺陷 ”。
在编写故事或功能需求时花一些时间来浏览重要的滥用案例,并确保仔细阅读此代码并包括额外的手动测试(尤其是探索性测试 )以及对这些功能的笔式测试,以捕捉严重的业务逻辑问题。
我们离终点线很近。 本系列的最后一篇文章即将发布:Design and Architect Security In。
c#可以开发ios应用吗