云原生应用安全
解决代码中的安全漏洞时，没有什么新鲜的东西。 尽管在服务器端应用程序的架构方面已发生了很大的变化，包括迁移到云中以及容器和微服务的使用增加，但可悲的现实是，代码中发现的最大安全漏洞是最主要的安全漏洞造成的。常见，众所周知和普遍的问题，即：
- SQL注入和其他插值攻击机会
- 使用过时的软件库
- 后端资源直接暴露给客户
- 过度宽松的安全性
- 纯文本密码等待被黑客入侵
SQL注入和其他插值攻击
SQL注入是黑客造成最大损失的最简单方法。
执行SQL注入很简单。 黑客只是将比DROP DATABASE或DELETE * FROM TABLE更复杂的内容写到在线表单中。 如果未对输入进行彻底的验证，并且应用程序允许将未经验证的输入嵌入到原本无害SQL语句中，则结果可能是灾难性的。 使用SQL注入漏洞，可能的结果是用户将能够读取私人或个人数据，使用错误信息更新现有数据，或者彻底删除数据，表甚至数据库。
正确的输入验证和检查某些转义字符或短语可以完全消除这种风险。 可悲的是，繁忙的项目经理经常将未经验证的代码推入生产环境，并且存在成功注入SQL注入攻击的机会。
使用过时的软件库
企业不会购买运行Windows XP的开发人员笔记本电脑。 而且，当使用的现代操作系统更新确实可用时，常规的软件治理策略要求一出现就立即应用给定的补丁程序或修订包。 但是软件开发人员多久检查一次其生产系统当前正在使用的软件库的状态？
软件项目启动时，将决定将使用哪些开源库和项目，以及将与应用程序一起部署这些项目的哪些版本。 但是一旦决定，项目很少会重新考虑这些决定。 但是有理由发布新版本的日志记录API或UI框架，而不仅仅是功能增强。 有时，一个旧的软件库将包含一个众所周知的错误，此错误在后续更新中得到解决。
每个组织都应采用一种软件治理策略，其中包括重新访问生产应用程序链接到的各种框架和库，否则，他们将面临潜在威胁存在于其运行时系统中的可能性，而他们只有通过以下方式才能了解到这一点：黑客首先发现该漏洞。
后端资源直接暴露给客户
在性能方面，分层是很糟糕的。 为了访问其所需的基础资源，请求-响应周期必须经过的圈越多，程序的速度就越慢。 但是，减少时钟周期的需求绝不能与保持后端资源安全的需求相抵触。
当针对RESTful API进行渗透测试时， 暴露的资源问题似乎是最常见的。 如此众多的RESTful API试图为客户提供访问后端数据的高效服务，因此，API本身通常仅仅是用于直接调用数据库，消息队列，用户注册表或软件容器的包装器。 在实现提供对后端资源的访问的RESTful API时，请确保REST调用仅访问和检索它们所需的特定数据，并且不提供后端资源本身的句柄。
过度宽松的安全性
从来没有人打算过以容易受到攻击的方式放下盾牌。 但是，在应用程序生命周期的管理中总有一点是，新功能或与新服务的连接在生产中无法像在生产前或测试环境中那样起作用。 考虑到问题可能与访问有关，因此安全许可将逐渐减少，直到生产中的代码起作用为止。 经过一场胜利之舞后，那些意向良好的DevOps人员暂时降下了防护罩，以使事情正常进行，但他们从不走动，也从来没有想过如何使事情保持在最初要求的安全级别。 接下来，您会发现，很多人正在入侵，私人数据正在泄露，而且系统受到破坏。
纯文本密码等待被黑客入侵
开发人员仍在将纯文本密码编码到其应用程序中。 有时，纯文本密码会出现在源代码中。 有时它们存储在属性文件或XML文档中。 但是，无论其格式如何，资源的用户名和密码都不应以纯文本形式出现在任何地方。
有人可能会认为纯文本密码问题被夸大为安全威胁。 毕竟，如果将其存储在服务器上，并且只有受信任的资源具有服务器访问权限，那么它就不会落入错误的人手中。 这种说法在一个完美的世界中可能是正确的，但是这个世界并不是完美的。 当发生另一种常见攻击（例如源代码暴露或目录遍历）并且持有纯文本密码的手不再受信任时，就会出现一个真正的问题。 在这种情况下，黑客已经获得了对相关后端资源的全部访问权限。
至少，密码可以在存储在文件系统中时进行加密，并在由应用程序访问时进行解密。 当然，大多数中间件软件平台都提供了诸如IBM WebSphere的凭证保险库之类的工具来安全地存储密码，这不仅简化了密码管理的技巧，而且还使开发人员免于承担任何公开了源代码或目录的责任。遍历将发生。
事实的真相是，生产代码中存在大量漏洞，并不是因为黑客想出了渗透系统的新方法，而是因为开发人员和DevOps人员根本不努力解决著名的安全漏洞。 如果遵循最佳实践，并且正确实施和维护软件安全性治理规则，则永远不会发生大量违反软件安全性的行为。
您可以在Twitter上关注Cameron McKenzie： @cameronmcnz
云原生应用安全
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
