软件安全漏洞测试 告
现在,我们生活中最重要的方面,包括财务,身份和医疗保健,都取决于代码。 现在,软件安全不仅对于公司而且对于个人而言都是至关重要的方面。
任何使用现代软件产品和服务的人都希望了解基本的软件安全性概念,以保持生活的幸福。 对于致力于设计,创建或维护这些产品和服务的任何开发人员,必须全面了解安全漏洞和安全最佳做法,以避免可能导致安全损失甚至数百人,数千人甚至数百万人死亡的安全漏洞。
在大多数情况下,安全漏洞在我们看来并不陌生。 对我们来说,它们是潜在的问题,并非完全切实; 因此容易被忽视。 想象一下,一个实际的攻击者使用您从未假设过的过时的邮件服务器插件进入您的系统,而实际上您从未想过需要更新,或者黑客通过您公司刚刚带入办公室的智能鱼缸进入了您的系统; 直到您以面对面的方式体验它们。 处理我们严格的截止日期和对新功能的要求不断流,也无法帮助我们考虑软件安全性。
一种流行的软件安全方法。
为什么要写这篇文章/span>
我先说一下:我不是软件安全专业人员。
我对软件安全的了解可以追溯到我的童年时代,即使用一些随机获得的二手编程书籍来修改代码。 从那时起,我一直喜欢阅读有关黑客和加密技术的文章,但是我现在的主要工作领域是软件工程。
那一刻,我不确定。 我为服务器做了基本的加固,在数据库中进行了哈希和加盐处理,使用了TLS,基于令牌的身份验证,并使用了我所知道的所有最佳实践。 但是,如果我犯了一个错误或者留下了空缺怎么办很高兴知道攻击者将如何进入我们的系统。 如果我有一个针对开发人员的简单清单,也很不错,这样我可以确保自己没有犯明显的错误。
提示: 通过我的开发经验,我发现了解现实中的软件安全漏洞非常有帮助,因此,如果您阅读整篇文章,我将很高兴。 但是,即使由于迫在眉睫的外星人绑架而没有时间这样做,您也可以查看清单的最后一个快速的想法。 首先是第一件事,对此一点都不难。
计划
我将介绍的这些示例和类别绝不是详尽的列表,也不是详尽的类别列表。 如果深入探讨,漏洞数据库,文章,讨论媒介甚至您的服务器中还有很多其他发现。
众所周知的事实是,安全漏洞并非纯粹是技术问题。 它们通常是由于多个组件(包括技术问题,流程,管理和人为错误)相互作用的结果而产生的。 研究安全漏洞的真实示例对于了解这些组件如何相互作用以导致安全灾难非常有用。
应用程序漏洞
/ u / rowealdo37189正在使用您的密码。
实际上,很难猜测您刚刚添加到正在使用的产品中的功能是否可以使互联 上的任何人执行服务器上的任意代码作为附加功能。 在开发的热潮中,我们向代码中注入了许多可能会变成漏洞的错误,在实际看到它们起作用之前,我们可能永远不会将它们视为漏洞。 以下是一些实际的应用程序代码违规情形的示例:
潘纳拉面包事件
正如Dylan Houlihan于2017年8月 道的那样,他发送了一封电子邮件,通知Panera Bread信息安全总监其交付API中的漏洞,该漏洞使任何人都能获得全名,家庭住址,电子邮件地址,食物/饮食偏好,用户名,电话 码,生日以及登录帐户的任何Panera Bread客户的已保存信用卡的最后四位数字,只需增加URI中的索引即可。
访问控制漏洞非常普遍,它们可能会严重损害公司的声誉。 关于漏洞的有趣部分到此结束。 更有趣的是,据 道Panera Bread如何处理这种情况:
..Houlihan仅简短地提到了此漏洞,没有任何细节,并建议如果提供了导演提供的PGP密钥(可使Dylan Houlihan对其 告进行加密以便只能对其解密的公共密钥),则他可以发送 告,而没有任何其他实体窃听/阅读电子邮件并了解此漏洞。
显然,他遭到信息安全总监的拒绝,被指控将电子邮件作为“销售策略”发送,并指出“要求PGP密钥不是开始的好方法”和“任何拥有安全实践永远不会像他发送的请求那样响应该请求。”
PGP是由Phil Zimmermann于1991年首先开发的工具。它采用非对称加密,其中密钥可用于加密,但不能用于解密,因此称为非对称。 这允许一个人拥有一个“公钥”和一个“私钥”,该公钥只能用于加密数据,因此您可以自由分发它; 您可以将其放在您的 站上,或将其写在纸上并放在桌子上,这是完全安全的; 由于人们只能使用它来加密数据,因此只有拥有私钥的人才能解密和读取它们。 在这种情况下,他建议Panera Bread向他发送一个公钥(可以在不到一分钟的时间内为该对话生成一个全新的公钥,然后将其删除),以此作为一种安全措施,因此没有人会知道该公钥的详细信息。漏洞,并且Panera Bread将是安全的,直到问题得到Swift解决。 或那是他认为会发生的事情。
长话短说,Panera Bread似乎在随后的八个月中都没有修复此漏洞。 此后,一些不愿继续告知Panera Bread的安全专家决定将其公开。 该漏洞公开暴露后,Panera Bread宣布损害仅限于10.000个用户,他们正在纠正这种情况。 貌似,他们没有,直到必须这样做 。
Fiserv事件
据KrebsOnSecurity 道,2018年8月,安全顾问Kristian Erik Hermansen在Fiserv银行平台中发现了一个漏洞 。 该漏洞使用户可以查看其他用户的交易相关数据,包括他们的电子邮件地址,电话 码和完整的银行帐 。 只需增加一个称为“事件编 ”的参数即可获得数据。
根据该 告,Fiserv在收到通知后的24小时内开发了一个补丁程序,并在此后Swift部署。
Facebook事件
2018年9月 ,Facebook产品管理副总裁Guy Rosen发布了安全更新。 它解释了一个漏洞,该漏洞使用户能够为其他有权访问其帐户的用户生成访问令牌。 根据更新,该漏洞是由多个错误共同作用导致的。 一个视频上传工具显示在错误的页面上,并且该页面上的“查看方式”按钮通常可以使用户像其他用户一样查看其个人资料,并生成访问令牌,以授予该用户对其他用户帐户的权限。
USPS事件
根据该 告 ,关于API访问控制的另一个漏洞直到被发现超过一年后才得以修复,这使得任何已登录的用户只需向API发送查询即可显示其他用户的个人信息。
…其他
此外,还有许多其他方法可以在此处未提及但很重要的攻击应用程序的方式,例如跨站点请求伪造攻击,跨站点脚本攻击, 远程代码执行攻击以及通过不使用安全性而成为可能的攻击。最佳实践,例如密码的哈希和加盐,尽管存在现有的和众所周知的解决方案,但每种最佳实践都很普遍。
通过围绕身份验证和授权的良好体系结构设计,使用已知的安全最佳做法以及为缓解众所周知的攻击媒介进行设计,可以避免大多数应用程序漏洞。 其余的就像一个复杂的错误,它是由许多小错误(例如在Facebook实例中)相互作用导致的,而heisenbug在您寻找自己的方式时会消失,这给检测和修复带来了挑战。
注意:我知道尽管我正在写的主题是应用程序层安全性,但我没有提到注入攻击。 是的,我知道它们仍然存在。 他们并没有消失。 实际上,它们非常受欢迎,而且在发表的 告数量上也越来越差 。 今年,我建议,如果您的代码由于使用注入攻击而遭到破坏,那么您应该立即休假。 不要考虑项目的当前状态或截止日期。 休假,去一个多山的地方(独自一人),并深刻地反省自己,同时仅靠大自然为您生存。 返回时,您将返回一个新人。 老了你会死的。 或者,您可以考虑验证,清理和转义输入,并使用ORM解决方案。
框架,库和第三方服务漏洞
我们的框架,库和第三方服务提供商通常不是我们的强项。
Equifax事件
如果Content-Type是OGNL表达式,请转到小配件leg 。
Equifax泄露是2017年发生的重大数据泄露事件,大约1.48亿人的个人敏感信息受到了破坏。 根据 告,该违规行为有两个重要方面:
Apache Struts 2 2.3.32之前的2.3.x和2.5.10.1之前的2.5.x在其文件上传功能中存在一个漏洞,攻击者可以利用该漏洞在服务器上执行任意远程Shell命令 。 该漏洞于2017年3月被披露并记录为CVE-2017-5638。Equifax数据泄露已于2017年9月宣布。由于用于监视 络流量的设备已停用10个月以上,因此未检测到该数据泄露由于过期的安全证书 。
CVE-2017-5638是由标头值(内容类型)被评估为Apache OGNL表达式而引起的, OGNL本身是一种成熟的语言。 攻击者使用这种表达语言的灵活性来设计和注入一个表达式,该表达式将执行他们提供的任何shell脚本。
违规事件发生后,情况呈指数级恶化,导致管理层辞职,员工应受责备和整体上的不友好。
此后,一年中又出现了其他三个远程代码执行漏洞,即CVE-2017–9791 , CVE-2017–9805和CVE-2018–11776 , 最新宣布的 漏洞 也与OGNL表达式有关 。
根据2018年5月发布的《财富》文章,维护中央存储库的公司Sonatype检测到“多达10,801个组织-包括《 财富》全球100强中的 57%” 仍在下载Apache Struts的旧版本和易受攻击的版本。
玛卡特
Magecart是一个非常讨厌的黑客组织,由较小的独立组织组成,每个组织都打算通过您使用的在线交易平台/ 站获取您的信用卡信息,然后在线出售。 他们的工作非常成功 。
它们主要通过直接注入电子商务 站或通过这些 站使用的第三方服务的脚本进行操作。 他们注入的脚本小而有效:直接在浏览器中运行的前端代码中捕获敏感信息,然后将其发送到他们设置的服务器,这是一台非常不错的带有SSL证书的服务器。
英国航空公司的违规事件据 道有380,000名受害者,这就是他们的方法的一个例子,例如Ticketmaster违规行为 。 在这些之后,他们似乎决定攻击大约一千个其他平台。 当他们意识到自己势不可挡时,便开始互相打架, 修改彼此的脚本以给另一组伪造的信用卡 。
时至今日,他们仍在继续其活动,整个行业都在努力寻找适用于magecart漏洞检测的解决方案。
恶意第三方图书馆
我们的第三方依赖关系确实可以咬我们。 在过去的几年中, David Gilbertson和Jordan Scales已经发表了两篇关于我们的依赖关系如何危险的有趣而启发性的文章。 大卫·吉尔伯森(David Gilbertson)指出:“我们生活在一个人们安装npm软件包的时代,就像他们正在流行止痛药一样。” 这是事实,这是事实。 并不一定会没有后果。
最重要的是,我们引入任何第三方依赖关系而无需进行任何调查就可以对其进行调查(例如“我只需要一个加载栏,并在npm上进行搜索”)就有可能引入更多我们将赢得的依赖关系。不要阅读甚至是不知道的代码,这些依赖关系中的每一个也可能带来其他依赖关系。 所有这些混乱都在与信用卡付款对话框相同的范围内执行。
配置错误漏洞
有时,正在部署的应用程序没有安全的默认配置,实际上期望部署它的人员启用它的安全功能。 但这通常不会发生,因为无论如何,谁仍会阅读所有文档,除了那个角落里的怪异人总是要花更长的时间来完成任务,因为他/他检查了配置中的每个细节。
树液
2018年, Onapsis发布了一份 告,指出NetWeaver的默认配置的漏洞,该漏洞是SAP的关键组件,可为多个SAP部署提供操作和通信的平台。
原来,您应该通过定义ACL将其配置为访问控制,否则副作用可能包括 络上任何人都可以访问连接SAP服务器的主消息服务器,并使用它来控制整个 络。 SAP平台,如果您喜欢以未经授权的方式查看或修改任意商业秘密,那将是一个很好的选择。
根据该 告 ,最有趣的方面是,此配置要求自2005年以来已得到详细记录,并且在许多系统中仍然存在。
浮动MongoDB
MongoDB是一个出色的基于文档的NoSQL数据库,经常被误认为它是灵丹妙药,尤其是在其流行初期。 在版本2.6.0之前的版本中,如果在不进行配置的情况下进行部署,它将监听地址 。 而且,它无需配置服务器或服务器即可部署到世界各地的计算机上,这意味着没有身份验证密钥,没有防火墙和默认服务器端口。
Tim Kadlec 告说,已有超过28,000个部署遭到黑客入侵。
我刚刚部署了数据库。
操作系统漏洞
操作系统漏洞是通过系统更新, 络隔离和祈祷避免的漏洞。 由于它们位于较低的基础层,它们潜在地非常危险,难以发现和理解,并且需要付出更多的精力进行修复。我将尝试讨论两个最近的重要漏洞,以显示它们的外观和破坏性他们可以。 由于我不是系统开发人员,所以我主要只对安全更新感兴趣,而对漏洞或操作系统的确切细节不感兴趣。 也许这些示例可以激发您注意服务器更新。
想哭
在2016年,一个名为Shadow Brokers的组织将大量他们认为是NSA黑客工具的漏洞转移到了毫无戒心的互联 上。 这些漏洞利用有趣的名字看似与实际漏洞没有任何关联 (或其他任何东西)(我最喜欢EPICBANANA )。 回到主题,一个漏洞利用(ETERNALBLUE / CVE-2017-0144 )使用Microsoft Windows Server消息块(SMB)协议中的漏洞在服务器上执行任意代码。 此漏洞以后将使WannaCry得以开发并发布到野外。 释放之后, 医疗保健系统,政府系统和公司遭到破坏,要求赎金,并且在世界各地进行了虚拟斗争 。
WannaCry在野外徘徊 。
Windows TrueType字体漏洞和Duqu
事实证明Windows TrueType字体呈现系统具有一个虚拟机,并且该虚拟机在内核空间中运行 ,因为为什么不这样做。 这种情况导致了一系列漏洞,这些漏洞被包括Stuxnet的后继产品Duqu在内的一系列不愉快的病毒所利用。 有关更多详细信息,请参阅此处和此处 。 发现这些漏洞以及与这些漏洞相关的其他漏洞,以及稍后出现的漏洞。
总会有更多
就是这样,我试图为您编译一些更有趣的漏洞和违规行为,但是还有很多很多人可以阅读和学习,其中许多我也不知道,因此无法在一篇文章中介绍。
因此,让我们开始讨论实际上我们在所有这些事情上做的事情。 在阅读解决方案时,请牢记这些漏洞示例。
那么,我该怎么做才能使软件更安全/strong>
在构建要投入生产的产品时,如果它是关键软件,则通常每天都会问相同的问题。 我错过了什么我在那儿留下空缺了吗我应该怎么做才能使自己对代码更有信心还是不可能
如上所示,可以通过多种创造性和意想不到的方式来破坏我们的软件。 这似乎令人沮丧,就像我们从一开始就在输一场仗一样。 一个单一的错误或疏忽很容易使我们暴露。
但是,一切并没有丢失。 我们可以做很多事情来构建我们的系统,使其更安全并保持这种状态。 如这些示例所示,由于没有应用从软件行业吸取的经验教训,因此许多易受攻击的系统都很脆弱。
这是可用于您的系统和代码的安全措施的列表,以保护它们免受已知的安全漏洞的侵害。 在阅读时,您会发现其中许多与我们上面讨论的漏洞直接相关。
1.保持系统最新。
在记录了漏洞之后,操作系统,框架和库最终将得到修复。 留下漏洞的大多数是系统,在记录漏洞并发布补丁后的几周/几个月内仍未更新的系统,它们会沦为牺牲品。 对于知道该漏洞的任何人来说,这些都是简单的目标。 大概在那时,甚至概念验证漏洞代码也随处可见,任何人都可以阅读,修改和使用它来攻击您。 使系统保持最新状态是保护自己的一种相当便宜的方法,值得付出努力。
2.减少攻击面。
可以通过将应用程序暴露的风险降至最低,从而消除系统中许多容易实现的目标。 通过禁用不需要的任何功能,关闭不需要公开的终结点,删除不必要的插件/扩展以及根据最小特权原则减少权限来减少攻击面。
3.确保您的生产环境/ 络安全。
使 络的某些部分不必要地向外界开放,或者将 络设备与过时的/易受攻击的软件一起使用,可能会给您的系统带来风险。 生产环境中使用的 络应受到限制,以限制暴露于外界,以便仅可访问必需的端点。 根据环境中运行的应用程序/容器,它们可能的端点和交互,它们也可以分为多个隔离的 络。 应该部署监视解决方案来跟踪 络并在出现问题时生成警 。 整个系统应设计成尽可能清洁,简单和自动化,以便在紧急情况下易于采取措施。 可以使用渗透测试。
4.监视系统。
部署监视解决方案,并将其配置为针对任何可疑活动生成有效且可操作的警 。 要监视的事件可能包括数据库查询率峰值,数据流限制溢出,服务器故障或关闭,应用程序错误率峰值以及可疑的 络活动。
5.详细了解配置。
您使用的工具/服务器/数据库可能没有安全的默认配置。 这是一个经常学到的刻苦的教训。 它可能具有独特的开发配置,可让您在本地进行一段时间的评估,或者可能没有,可能它被配置为一种开发服务器,它侦听与您的公共IP的外部连接,并在被询问时做疯狂的事情。 您必须先阅读并理解配置并在配置文件中显式定义您的选择,然后才能知道。
6.尽可能自动执行。
人类会犯错,所以要自动化。 自动化您的构建,测试,部署和配置过程。 自动化可行的一切。 所有人都称赞机器人。
7.密切关注您的服务提供商。
我们使用的第三方服务(例如CMS,存储,SAAS和云提供商, 络服务提供商和其他软件服务)也可能会受到可能的攻击,因为对它们的成功攻击会使您的系统安全措施变得无用。 仅从安全角度评估这些服务后,才能使用这些服务。 还可以部署监视解决方案以检测所提供服务中的可疑更改。
8.手动选择并验证您的依赖项。
9.利用最佳实践。
以极其自信的态度重复众所周知的错误是开发人员中的一种流行娱乐方式。 另一方面,还有更好的选择! 如;
- 使用细粒度的访问控制。
- 使用散列和加盐的密码。
- 了解加密的基本知识,以及对称/不对称密码在基本级别上如何工作。
- 知道TLS / SSL是什么,为何重要,并将其用于与我们的服务之间/之间进行的所有通信。
- 了解 络基础知识和防火墙,并谨慎使用 络。
- 了解您特定领域中的知名空缺/攻击媒介(例如,针对前端开发人员的XSRF和针对后端的注入)。
- 禁用该默认错误页面。
- 禁用该默认错误页面。
注意:是的,我写了“禁用该默认错误页面。” 两次。
10.保持代码干净,并为建立良好的体系结构而努力。
11.编写应用程序代码时要牢记安全性。
从一开始就编写安全代码是实现应用程序安全性的最佳方法。 另一方面,定义用于编写安全代码的所有规则很难。 但是我们仍然应该有一些规则。 下面,通过分析流行的漏洞类型可以编译出一些规则,因此从一开始就可以在编写新应用程序时加以缓解。
尽管遵循规则可能会有例外,但事实证明它们是基础。 和往常一样,把它们和一粒盐一起吃; 但请考虑一下以下事实:过去不遵循它们会导致许多攻击。
始终进行验证,清洁和过滤。
在处理之前,您不能完全确认输入吗
外部输入应始终根据明确定义输入应包含什么内容的规则进行验证。 输入的长度,可能包含的字符/二进制符 ,数据的格式以及对字段可以具有的值的限制是可以验证的一些内容。 另外,如果输入的结构及其字段为文档形式(例如JSON,XML,YAML),则应进行验证。 在执行任何逻辑之前,应假定输入数据已经有效,因此应尽早验证输入数据。 对于许多不同的语言,可以找到许多用于此任务的库,例如Java的commons-validator和Python的voluptuous 。 如果要开发Web API,则还可以考虑使用API??标准(例如OpenAPI),该标准由许多用于Web API开发的库和平台支持。
不要使用评估器。 将查询作为输入参数并将其传递给数据库,而不是解析和验证每个查询参数并将它们分别传递给精心实现的存储库抽象,可能会很诱人。 或者可能很想通过使用脚本引擎评估输入来选择在运行时将调用哪种方法。 请不要做这些事。 始终努力编写明确,简单易懂的代码,除了设计目的之外,它没有其他目的。
自运行式餐巾纸。
不要使用扫描仪。 如果您认为您的代码应基于输入字符串中包含的数据在运行时使用代码扫描程序(例如Java的反射)来搜索要调用的方法,我会诱使您重新考虑。 简单的switch语句不会吗如果您实际上不需要它们,则扫描仪可以不在列表中。 即使您似乎确实需要它们,也可能会有其他选择。
注意错误情况。 考虑一下如何引发错误/异常,以及代码中的哪种组合以及产生的流程。 尝试通过代码使异常处理尽可能简单,一致和常规。 到处乱 错误消息是攻击者用来获取有关程序内部运行情况的信息的一种方法,异常/错误本身也可以用于漏洞利用。
注意响应中返回的内容。 确保响应未向外界提供有关软件内部状态或操作的任何信息。 对于任何错误消息也是如此。 将返回的数据限制为仅客户端恢复过程所需的数据。
添加详细,有意义的日志记录。 如果出现错误的方式,只会是您本人和您的日志。 设计日志,以便您可以从头到尾跟踪故事/事务/过程/其他内容。 添加太多细节,您的日志数据库将淹没其中。 加的太少,您甚至都不知道发生了什么或是否发生了。 不好玩。
12.制定救援计划。
如果您的所有系统都受到威胁,从代码存储库和从头开始的冷备份全部还原需要多长时间如果仅其中一部分被破坏怎么办从头到尾,您的详细行动计划是什么如果发生事件,尽早制定这些计划可能会非常有帮助,并且充其量也可以帮助您发现您以前从未意识到的系统缺陷。
13.密切关注新闻。
密切关注有关安全性的博客和文章,以及诸如CVE和NIST之类的漏洞数据库可以帮助您了解系统/软件是否存在已知漏洞,以便您可以在检测/利用系统之前对其进行补丁/更新。 漏洞监视解决方案可随时用于自动执行此任务。
14.解决您所看到的问题。
推迟解决安全问题的风险极大,其成本可能远远超过其提供的任何收益。 然而,这是经常犯的错误。 因此,一旦检测到安全漏洞,则应立即永久修复,然后再添加新功能。 推迟修复,并希望没人能找到该漏洞是关于软件安全性的非常重要且常见的错误,其后果是严重的。
结论
软件安全漏洞是真正的威胁,而确保系统安全是一项艰巨的任务。 但是从好的方面来说,可以通过迫使攻击者找到一种全新的未知的攻击方式来保护系统的安全。 我们可以通过不重复以前犯的错误来做到这一点。
This is possible through following security best practices on all layers of our system, and importantly, allocating necessary resources for maintaining software security in our project and doing the right prioritization.
After recognizing these threats, one might think that as the next logical step, to be on the safe side, we should not change existing infrastructure, systems or frameworks, or we should not develop new ones; just to avoid security risks.
I think, on the contrary, new tools can be more secure, simple and elegant than before, and they should be developed. The important thing is while we create them, we should not forget the lessons learned from the past, and make our decisions in an informed, rational way.
感谢您的阅读。 Hope you enjoyed my article,
Special thanks to Emre Rencberoglu.
翻译自: https://hackernoon.com/how-software-security-vulnerabilities-work-and-what-you-can-do-to-stay-safe-c9596d993581
软件安全漏洞测试 告
文章知识点与官方知识档案匹配,可进一步学习相关知识Java技能树首页概览91469 人正在系统学习中 相关资源:LibraryO:图书图书馆软件。-开源_图书馆开源项目-其它代码类资源…
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!