c#可以开发ios应用吗
除了正确实施身份验证 , 访问控制和日志记录策略以及选择(并正确使用) 良好的框架外,还有更多保护设计和体系结构的安全。
您需要考虑并应对设计中许多不同点的安全威胁和风险。
Adam Shostack的新书《 威胁建模》详细探讨了如何做到这一点,并提供了许多练习和示例,介绍了如何寻找和填补软件设计中的安全漏洞以及如何考虑设计风险。
但是安全设计中的一些重要基本思想将带您进一步:
了解您的工具
在确定系统的语言和技术堆栈时,请确保您了解安全约束和选择所决定的风险。 如果您使用的是新语言,请花一些时间来学习如何正确安全地用该语言编写代码。 如果您使用Java,C或C ++或Perl进行编程,请查看CERT针对这些语言的安全编码指南 。 如果您是在iOS上编写代码,请阅读Apple的《 安全编码指南》 。 对于.NET,请查看OWASP的.NET安全项目。
查找静态分析工具如FindBugs的和PMD的Java, JSHint为Javascript, OCLint为C / C ++和Objective-C, 司闸员为Ruby, RIPS为PHP,微软的.NET静态分析工具 ,或者商业工具,这将有助于捕获常见编码或持续集成中的安全性错误和逻辑错误。
并确保您(或操作人员)了解如何锁定或强化操作系统,以及如何安全地配置容器和数据库(或NoSQL数据)管理器。
分层与信任
分层或分层以及对设计的信任紧密联系在一起。 您必须了解并验证体系结构各层之间以及系统之间以及设计中组件之间的信任假设,以便确定需要在这些边界上实施哪些安全控制:身份验证,访问控制,数据验证和编码,加密,记录。
了解数据或控件何时跨越信任边界 :与直接控制范围之外的代码之间的来往。 这可以是外部系统,也可以是浏览器,移动客户端或其他类型的客户端,或者体系结构的另一层或另一组件或服务。
与考虑威胁相比,考虑信任要简单得多,也要更加具体。 并且更容易测试和验证。 只需问一些简单的问题:
数据来自哪里? 您如何确定? 您可以信任这些数据吗?它经过验证并经过安全编码吗? 您可以信任另一侧的代码以保护传递给它的数据的完整性和机密性吗? 您知道发生异常或错误时会发生什么吗–您会丢失数据或数据完整性,还是会泄漏数据,代码打开失败还是关闭失败 ?
在对设计进行更改之前,请确保您了解这些假设并确保这些假设正确。
应用程序攻击面
最后,了解和管理系统的“ 攻击面”非常重要:攻击者可以通过所有方式进入系统或从系统中获取数据,以及暴露给攻击者的所有资源。 API,文件,套接字,表单,字段,URL,参数,cookie。 以及保护系统这些部分的安全管道。
您的目标应该是尝试使“攻击面”尽可能小 。 但这说起来容易做起来难:每个新功能和新集成点都可以扩展攻击面。 尝试了解您要引入的风险及其严重性。 您是在创建全新的面向网络的API还是在设计用于处理金钱或机密数据的新业务工作流程,或者正在更改访问控制模型,或者换出平台架构的重要部分? 或者,您只是要添加另一个CRUD管理表单,还是仅将一个字段添加到现有表单或文件中。 在每种情况下,您都需要更改“攻击面”,但是风险会大不相同,管理这些风险的方式也将大不相同。
对于小的,易于理解的更改,风险通常可以忽略不计–只需保持编码即可。 如果风险足够高,则需要进行一些滥用案例分析或威胁建模,或者花时间进行代码审查或笔测试。
当然,一旦不再需要功能,选项或界面,请将其删除并删除代码。 这将减少系统的攻击面,并简化维护和测试工作。
大功告成
开发人员可以确保应用安全的10件事 :考虑架构层次和技术选择的安全性 ,包括需求的安全性,仔细使用框架和库 , 利用他人的代码,确保您实现基本安全控制和类似的特征身份验证和访问控制得当, 保护数据隐私 , 登录考虑到安全问题,并处理输入数据,并停止注入攻击 ,特别是SQL注入 。
这不是一个详尽的清单。 但是,理解和处理应用程序安全性中的这些重要问题(包括当您考虑需求以及设计,编码和测试时的安全性,更多地了解您的工具并正确使用它们)是所有开发人员都可以做的工作,并且会花很长时间,使您的系统安全可靠。
c#可以开发ios应用吗