当你建立一个商业应用程序时，无论是内部使用还是客户的外部使用，你可能不会让每个用户执行每个功能。如果你这样做，你可能会受到访问控制失效的影响。

让我们来看看什么是破损的访问控制，为什么它如此危险，以及如何修复它。

了解破损的访问控制

当应用程序代码没有适当的安全或访问检查时，就会出现访问控制被破坏的情况。当应用程序在某种程度上配置错误，允许访问用户不应访问的功能或页面时，也可能发生这种情况。

如果你处理公司的财务，你可能有机会把钱存入某些账户或在公司的账户之间转账。但是，你不应该有权限从这些账户中提取现金或把钱转到其他账户。如果没有适当的访问检查，那么你的员工可能会执行超过必要的功能。

这些检查可以在代码中进行，也可以在配置文件中进行。例如，可能有XML配置文件告诉网络应用程序框架，哪些用户被允许访问哪些页面。这确保用户只能访问他们被授权使用的功能。

为什么破损的访问控制是危险的

考虑一下这个例子。一个攻击者已经意识到你的用户账户创建代码可以被操纵，允许攻击者用一个简单的帖子请求创建一个管理员用户。他们可以用用户名和密码发送请求，然后在途中改变它，在URL中作为参数包括管理员的角色，或者在请求的正文中。攻击者登录到应用程序，并立即获得管理员权限。

并不总是恶意攻击者在渗透系统。如果没有适当的访问控制，不应该在部门之间共享的敏感信息可能会泄露出去。想象一下，如果公司的任何员工都能看到人力资源的工资数据或财务数据。如果任何员工都能看到由于公司财务状况不佳而要进行裁员，会发生什么？这可能会对你的士气和公司的声誉造成损害。

客户的敏感信息也可能丢失。公司经常存储使用其服务的客户的个人信息。要注意不要因为缺乏访问控制而意外地暴露了这些信息。例如，如果你的系统让用户有能力申请他们的健康记录，他们是否也有能力申请和看到其他人的健康信息？如果URL包含一个客户ID号码，攻击者可以反复递增这个客户ID号码，直到找到一个与另一个客户相匹配的号码，从而暴露他们的个人数据。

打败破损的访问控制

基于角色的访问控制（RBAC）是一个非常有效的工具，可以实现完善的访问控制。那些使用活动目录的人可能对创建组并给予整个组而不是个人的某些项目的访问权的想法很熟悉。应用程序以同样的方式工作，使用角色来定义谁被允许看什么。

这有两个好处。首先，当某人离开管理员角色时，不需要改变功能。如果某人以前是管理员，现在不应该再是了，那么你只需把一个新的人放到管理员的角色中，并把以前的人从这个角色中删除。该代码检查用户是否有管理员角色，而不是检查每个用户是否有权限访问某个页面或功能。

第二个好处是避免了维护的恶梦。访问控制如果过于细化，以至于每个人都与每一个可能的功能或页面有关联，那么随着时间的推移，就不可能进行管理。角色使事情变得更容易，因为一个角色可以添加多个人员。一个角色可能包括整个公司，而另一个可能只有五个人。这使得管理角色的效率更高，因为要管理的角色会更少。一个有10,000人的公司可能只有100个角色，而不是你的应用程序中的10,000倍的功能。研究你所选择的应用程序框架，看看有哪些选项可以用于强大的访问控制。

使用功能级访问控制也很关键。通过要求用户通过某些访问控制检查来保护对所有功能的访问。使用最小特权原则，默认拒绝访问，只在需要的情况下开放访问。要记住对每个功能实施访问控制可能很困难。使用一个中央组件来管理和执行访问控制。

保护你的敏感功能

破损的访问控制会让你的数据和你的应用程序大受攻击和利用。没有得到适当保护的客户数据可能导致大规模的数据泄露，损害你的声誉和收入。

如果攻击者能够访问他们不应该访问的功能，破损的访问控制也可能导致账户被接管。使用适当的功能级别的访问控制，你就可以使你的应用程序免受恶意攻击者，甚至是意外的内部人员的影响。

你认为你对功能级别的门禁都很了解吗？你现在就可以挑战自己，修复破损的访问控制。 [从这里开始]

"唇亡齿寒"是二战期间在美国开始流行的一句话。在英国，你听到的是 "漫不经心的谈话要付出生命的代价"。这句话的主要意思是，不小心说出敏感信息可能被间谍听到，导致严重后果。

在构建网络应用程序时，同样的原则也是如此。当你的网络应用程序透露了太多的信息，就会使攻击者更容易侵入。

在这篇文章中，我们将介绍什么是信息暴露，为什么它是危险的，以及如何防止它。

了解信息暴露情况

信息暴露是指网络应用将内部信息暴露给不应该看到的人。它也可以指通过日志文件或用户界面暴露敏感的客户信息。无论哪种方式，攻击者都可以利用他们发现的信息来攻击你的系统或你的用户。

通常情况下，攻击者的第一步是试图在你的应用程序中创建一个错误。糟糕的错误处理和网络应用程序配置导致了错误信息的暴露。如果攻击者在你的应用程序中创建一个错误会发生什么？如果出现一个技术错误信息，包括技术细节，如堆栈跟踪，你已经暴露了太多的信息。这些细节可能包括你使用的数据库或你运行的应用服务器的哪个版本。

敏感信息的披露可以通过其他方式发生。表单上是否有保存敏感信息的隐藏字段？攻击者可以简单地查看页面的源头并看到这些值。

简而言之，当你的用户需要知道的信息太容易被获取时，信息就会暴露。

理解为什么信息暴露是危险的

攻击者可以利用应用程序所暴露的信息做什么？如果信息是敏感的，攻击者可以窃取身份或用户凭证。这可能导致经济损失、侵犯隐私和监管罚款。

如果攻击者使用错误信息来获得有关应用程序的信息，这些信息可能被用于未来的攻击。事实上，OWASP测试指南中有一整节是关于信息收集的。

OWASP测试指南》鼓励使用搜索引擎来发现你的网站的信息，你可能不打算这样做。例如，你的管理页面是否暴露给搜索引擎？使用 robots.txt 文件来告诉搜索引擎不要索引某些页面。同时，robots.txt文件也会泄露信息。敏感的URL有时会驻留在robots.txt文件上。攻击者把文件拉下来，开始了解网站的一些目录结构。

Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>

HTTP头、网站横幅、甚至HTML和JavaScript代码中的注释都可能有攻击者不应该看到的信息。HTTP头信息可以揭示应用服务器和版本号。攻击者可以利用这些信息来寻找针对这些特定版本的漏洞。请确保你了解攻击者可能找到你的信息的所有不同地方，以及如何适当地隐藏它。

打败信息暴露

信息泄露往往是网络应用程序配置的一个问题。许多应用服务器默认在错误信息中返回堆栈痕迹。请确保为生产应用改变这一设置，在记录错误的同时重定向到一个通用的错误页面，以便进行故障排除。详细的错误信息不应该返回给用户的浏览器。

如果你有任何包含敏感信息的应用程序所需的文件，请确保适当的访问控制，确保只有应用程序本身可以读取它。禁用服务器上的目录列表，并将这些文件移到网络根目录之外。这可以防止攻击者使用目录遍历攻击的方式使用浏览器导航到该文件。

当没有正确配置时，日志可以被用来收集信息。当错误发生时，不要记录敏感信息，如密码、会话令牌或个人身份信息（PII）。如果攻击者能够获得对日志文件的访问权，他们会发现一个可以窃取敏感信息的宝库。不要记录超过必要的信息，这通常是一个账户标识符，一个详细的错误信息，也许还有错误发生的方法或正在执行的操作。假设日志文件不是秘密，你就不会被诱惑在其中放置敏感信息。

不要让你的网络应用程序沉没

你真的会在与朋友交谈时泄露信息，直接导致一艘战舰在第二次世界大战中损失吗？也许不会。但为什么要冒这个险呢？这就是 "唇亡齿寒 "这句话的教训。

同样，没有理由将你的网络应用程序的内部运作暴露给外部世界。没有理由查看整个信用卡号码或密码。没有理由把PII数据放在日志文件中。所以不要这样做。请查看我们的学习资源，了解更多关于信息暴露的信息。

把你的应用程序的内部工作放在属于它们的地方。不要让你的网络应用下沉。

你认为你现在就能阻止信息暴露吗？站出来迎接挑战吧，勇士。[从这里开始]

什么是所有应用程序都有的东西？组件，也被称为依赖性或库。世界上很少有代码不在某个时间点上依赖其他代码的。你甚至从创建应用程序的时候就开始了依赖性的堆积!

由于所有的应用程序都使用组件，其中大部分是你没有写过的，所以你使用的组件中的漏洞会成为责任。让我们讨论一下使用有已知漏洞的组件意味着什么，它有多危险，以及如何解决它。

理解使用具有已知漏洞的组件

所有复杂的软件都有漏洞。这就是野兽的本质。所以你的组件永远不会是100%安全的。然而，当在组件中发现漏洞时，你知道它吗？你是否为它做好了准备？

当组件的使用超过其使用寿命或发现漏洞后，问题最常出现。大多数组件和库在漏洞公布的同时或之前就发布了安全漏洞的补丁。因此，当组件中的漏洞被发现和公布时，尽快更新组件是最重要的。不要在生产中留下有漏洞的软件。

组件可以来自几个来源。有时你会购买第三方供应商的产品，直接与你的自定义代码集成。这些组件成为你的代码的一部分，并在相同的权限水平上运行。另一个来源是托管在GitHub等网站上的开放源码项目。开放源码可能是危险的，因为不是所有的开放源码库都经过仔细的审查或审计，以发现漏洞。

攻击者利用组件漏洞信息对他们有利。由于这些漏洞是公开宣布的，攻击者在你知道的同时也知道了这些漏洞。攻击者还有一些技术可以用来找出你所使用的组件。一旦他们知道了这些信息，他们就会知道如果你的应用程序没有打上补丁，该如何攻击它。

了解为什么易受攻击的组件是危险的

如果你正在寻找证据，说明使用具有已知漏洞的组件有多危险，那么就请看看2017年的Equifax漏洞。

2017年7月，美国信用局Equifax发现了一个大规模的数据泄露，泄露了超过1.47亿人的个人身份信息。这次数据泄露的范围和影响是空前的。最近，关于Equifax安全做法不严的消息传出。

其中一个宽松的做法是补丁管理。Equifax没有良好的补丁管理做法，这意味着他们的组件会在相当长的一段时间内没有打补丁。这是导致漏洞的直接原因。

Equifax的网站使用了Apache Struts网络框架。在攻击者入侵网络的几个月前，Struts框架中发现了一个漏洞，即Apache Struts CVE-2017-5638。然而，Equifax并没有修补这个漏洞。攻击者利用这个漏洞进入了Equifax的网络。从那里，他们获得了一个个人信息的宝库。

许多网站是基于并非由公司编写的网络框架。这是标准的做法，因为从头开始建立所有必要的功能将是一个太大的工程。然而，对框架的强烈依赖可能会使你受到漏洞的影响。不要成为下一个Equifax。

如何保护易受攻击的组件

在防止使用易受攻击的组件方面，没有银弹。然而，你可以使用一些政策和控制措施来减轻易受攻击的组件被用来破坏你的系统的风险。

你需要知道你正在使用哪些组件以及每个组件的哪个版本来构建你的应用程序。OWASP的依赖性检查等依赖性管理工具可以帮助你掌握你正在使用的依赖性。依赖性检查也会告诉你这些组件中是否有公开披露的漏洞。

补丁管理方法也是必不可少的。当漏洞被发现时，要有一个系统来下载、测试和顺利地发布到生产中的补丁。保持你的软件的补丁可以防止几个月前的漏洞被攻击者利用。

最后，要有管理使用开放源码和第三方组件的政策。开发人员不喜欢有繁文缛节，这是可以理解的。然而，对于不是由你的组织编写的代码，必须有一个审查过程。它不一定是重量级的，但必须防止未知组件被使用。至少，必须保持最新的组件使用清单。

不要被 "第三方 "咬伤

组件会有漏洞。你的业务应用程序将使用组件，无论是来自供应商还是来自开放源码库。这并不意味着你的组织需要容易受到攻击。

即使攻击者在你知道的同时也知道存在什么漏洞，但补丁通常是在公开宣布的同时提供的。因此，一定要教育自己，了解你的应用程序在使用什么。知道什么是脆弱的。保持你的组件有补丁。

准备好发现（和击败）一些脆弱的组件了吗？前往竞技场参与战斗吧。 [从这里开始]

原文发表于 报道.

我曾经站在围栏的两边，非常了解在维护安全最佳实践方面，开发团队和AppSec专家之间可能出现的紧张关系。

这很难；在一天结束时，开发人员的主要任务是提供软件功能。它们必须美观、实用，并有助于展示应用程序的功能。如今，随着敏捷开发实践的开展，这些功能必须在严格的期限内完成......而在如此多的利害关系中，安全问题很少被放在首位。

安全被看作是AppSec团队的领域，他们的任务是扫描代码（或者更糟糕的是：手动逐行审查），并向开发团队报告他们的代码不安全或者完全无法使用。他们是泥巴里的棍子，把他们的好工作挑出来，阻止创新，一般来说，给开发者带来了头痛的问题。在一天结束时，许多安全问题是相当简单的修复 " 也许只是一行代码可以在几分钟内加强一个脆弱的后门。

但是，问题就在这里。由于 "安全 "是负面体验的代名词，开发人员根本就没有像他们应该做的那样密切关注安全问题。那些单行的修复措施并没有发生：毕竟，AppSec的人不断地遇到同样的问题。对他们来说，在我们第一次发现SQL注入缺陷（以及随后的修复）的20多年后，仍然指出这些缺陷，一定是很令人抓狂的。

迄今为止，我们所做的事情并没有像我们希望的那样有效。我们需要专注于修复开发者和AppSec专家之间的桥梁，努力建立一种积极的安全文化，让开发者获得工具和培训，在这个领域发挥真正的影响。

谁知道呢？他们甚至可能像我一样爱上它!

正面安全是提高应用安全的最快和最简单的方法

不，这不是一些关于无形的结果的胡言乱语。它是安全编码成功秘诀中的一个绝对重要成分。

开发人员从生产的一开始就掌握着提高安全性的关键，首先是编写安全的代码。通过创造一种积极的安全文化，让开发人员对应用程序的安全感到兴奋，常见的漏洞可以在AppSec土地上的扫描或人工代码审查之前就被消灭掉。

修复已经提交的代码中的漏洞的成本要高出30倍，因此，找到能够发挥开发人员的优势、保持兴趣并实际发挥作用的培训是未来降低识别和修复这些重复出现的漏洞的成本的一个巨大步骤。

积极的、以开发人员为中心的举措促进了正确的安全文化。

当每个人都与安全最佳实践保持一致时，积极的安全文化就是一个快乐的、重要的副产品。

积极的、可扩展的、以开发人员为中心的举措可以培养正确的安全文化。吸引开发人员解决问题的创造性思维是赢得他们的关键，同时也确保任何新招聘的人员能够快速掌握团队的安全期望。请联系我们，了解开发者安全关系的发展概况，以及在您的组织中成功推出安全意识计划的想法。

在这篇博客中，我们将讨论运行网站或允许员工远程访问计算机资源的组织所面临的最常见的问题之一--这几乎是所有人。是的，你可能猜到了，我们要谈的是认证。

如果黑客可以简单地以管理员的身份用有效的用户名和密码登录系统，那么就没有必要部署先进的技术来对抗网络防御。系统只是打开门，让攻击者进去。更糟糕的是，如果攻击者没有做什么太离谱的事情，他们的存在几乎不可能被发现，因为大多数防御系统会把他们看作是一个有效的用户或管理员在做他们的工作。

认证漏洞的类别相当大，但我们将讨论最常见的问题，这些问题往往被意外地植入用户的登录过程。通过加固这些漏洞，你可以从你的组织中消除绝大部分的认证问题。

在这一集里，我们将学习。

• 一些常见的认证漏洞是如何被利用的
• 为什么它们如此危险
• 可以使用什么政策和技术来消除认证漏洞。

攻击者是如何利用认证漏洞的？

有相当多的认证漏洞可能会潜入认证系统，所以黑客对每个漏洞的利用方式都有点不同。首先，让我们来看看最常见的漏洞，然后举例说明其中几个漏洞是如何被利用的。

最常见的认证漏洞包括。

• 拥有薄弱或不适当的密码政策。
• 允许无限制的登录尝试。
• 将登录失败的信息反馈给攻击者。
• 通过不安全的渠道发送凭证。
• 弱散列的密码。
• 而且有一个不安全的密码恢复过程。

拥有一个薄弱的密码政策可能是最常见的漏洞。如果允许用户在没有任何限制的情况下创建密码，那么太多的用户会使用容易猜到的密码。每年，各种计算机新闻机构都会发布一份使用最多的密码清单，"123456 "和 "密码 "总是排在前五位。还有其他的。管理员们喜欢用 "上帝"，这也是相当多的。诚然，这些都是幽默或容易记住的，但也非常容易被猜到。黑客知道什么是最常见的密码，并在试图入侵系统时首先尝试它们。如果你的组织中允许使用这类密码，你最终会被攻破。

一个不太明显但仍然危险的漏洞是向用户提供关于登录失败的信息。这很糟糕，因为如果你在用户名不存在时返回一条信息，而在用户名存在但密码不好时返回另一条信息，这就使攻击者可以摸清系统中的有效用户，并专注于猜测这些用户名的密码。如果这与允许无限制猜测密码的认证漏洞相结合，它将使攻击者能够对他们发现的任何有效用户进行字典式攻击，如果密码容易猜测，这可能会使他们相当快地进入系统。

为什么认证漏洞如此危险？

美国旧西部有一个经典的故事，说的是一个偏执的自耕农在他的前门上安装了三把锁，用木板封住了他的窗户，睡觉时有很多枪在手边。到了早上，他被发现死亡。他的攻击者之所以能找到他，是因为他忘记了锁上后门。认证漏洞就很像这样。如果一个攻击者可以使用有效的用户名和密码进入你的网络，那么你有什么样的监控工具或主动控制措施，或者你雇佣了多少专家分析师，这真的不重要。

一旦进入，攻击者可以做的事情就很少有限制。只要他们在自己的用户权限范围内行动（如果他们入侵了管理员账户，那么权限就会相当广泛），他们被及时发现以防止出现严重问题的可能性就非常小。这使得认证类漏洞成为任何系统中最危险的漏洞之一。

消除认证漏洞

消除网络中的认证漏洞的最好方法之一是制定良好的、全球通用的密码策略。不仅应该限制用户，甚至是管理员，使用像 "password "这样的密码，而且应该强迫他们加入一定程度的复杂性，使攻击者应用字典或普通短语类型的攻击变得不可行。你可以根据被保护系统的重要性来制定自己的密码创建规则。这样做将使攻击者更难猜测或暴力破解密码。

你还应该限制登录失败的次数，这样，如果一个错误的密码被输入超过，比如三次，用户就会被锁定。锁定可以是暂时的，因为即使是几分钟的延迟也会阻止自动字典攻击的继续。或者它可以是永久性的，除非该账户被管理员解锁。无论哪种情况，只要发生这种锁定，就应该提醒安全人员，以便他们能够监控这种情况。

另一个防止攻击者收集信息的好方法是，每当输入一个错误的用户名或密码时，都要制作一个通用的信息。这两条信息应该是相同的，这样黑客就不会知道他们被拒绝是因为一个用户不存在还是因为密码错误。

认证漏洞是大多数系统中最常见和最危险的漏洞。但它们也相当容易发现和消除。

关于认证漏洞的更多信息

要进一步阅读，你可以看一下OWASP认证小抄。你也可以用Secure Code Warrior 平台的免费演示来测试你新发现的防御知识，该平台培训网络安全团队成为终极网络战士。要了解更多关于击败这个漏洞以及其他威胁的流氓画廊的信息，请访问Secure Code Warrior 博客。

站出来，直面Secure Code Warrior 平台中的认证漏洞。[从这里开始]

想象一下，走到一家老式地下酒吧或地下俱乐部的门口。门上的小洞被推开，一个粗壮的保镖问他密码。潜在的访客不知道密码，于是猜了一下。这是错的，所以保镖不让他们进去。

这就是通常会发生的事情。现在想象一下，猜错了密码的访客立即再试一次，结果错了，又被拒绝访问。然后想象一下，这个潜在的访问者打开字典，开始读单词，从像土豚这样的东西开始，继续尝试每一个可能的单词。

最有可能的是，保镖不会允许这种活动发生，但反自动化不足的网站和应用程序就是这样做的。他们允许用户不断尝试密码，甚至使用自动化技术，直到他们最终偶然发现适当的短语。

在这一集里，我们将学习。

• 攻击者如何利用不充分的反自动机
• 为什么反自动化不足的应用程序是危险的
• 可以修复这个漏洞的技术。

攻击者如何利用不充分的反自动化？

像我们想象中的酒馆访客那样采用自动化或字典式的攻击，在网络安全领域并不新鲜。事实上，这些暴力式攻击是有史以来最早部署的一些黑客技术。而随着计算机速度的提高，它们变得越来越高效。一台快速的计算机可以在短短几分钟内读完一整本单词词典，这取决于攻击计算机和目标系统之间的连接速度。

这些类型的自动化攻击是反自动化软件和技术被创造的原因。它使应用程序有能力确定用户正在采取的行动是否超出了典型人类行为的规范。

如果一个应用程序没有足够的反自动化检查，攻击者可以简单地不断猜测密码，直到他们找到一个匹配的密码。或者，他们可能使用自动化软件来做其他事情，如向网站论坛发送垃圾评论。

为什么不充分的反自动化是危险的？

允许恶意用户采用自动化手段来试图规避安全问题可能是很危险的。自动化类型的攻击之所以从计算机的早期一直持续到现在，是因为它们可以非常有效。如果你给一个自动化程序无限的时间来提交密码，而猜错了又没有任何后果，它最终会找到正确的密码。

当在像论坛这样的地方使用时，一波又一波明显的脚本评论可能会使有效的用户感到沮丧，甚至通过浪费系统资源而像一种拒绝服务的攻击。自动发帖也可能被用作网络钓鱼或其他攻击的工具，以便将诱饵暴露给尽可能多的人。

修复不充分的反自动化问题

为了解决反自动化不足的问题，所有的应用程序都必须有能力确定正在采取的行动是由人类还是自动化软件实施的。最流行和广泛使用的技术之一是完全自动公开图灵测试，以区分计算机和人类，或CAPTCHA。

CAPTCHA基本上是一个图灵测试，由计算机科学家Alan Turing在1950年首次提出，据此，人类和计算机的行为可以被分离和识别。现代验证码提出了人类可以轻松解决的问题，但计算机却很难解决，或者根本无法解决。一个流行的验证码展示了一张由网格分隔的照片，要求用户识别所有带有特定项目的区域，如一朵花或一张脸。计算机无法理解所要求的是什么，因此甚至无法尝试扫描该图像。即使它能做到，图像识别也超出了大多数不是专门为其设计的程序。

CAPTCHA的其他例子包括显示模糊的文字，问一个简单的逻辑问题，甚至大声播放问题。在应用程序的关键点上实施验证码挑战，例如在提示密码时，可以阻止自动化程序的运行。

也可以通过简单地限制同一来源的错误猜测的数量来停止自动化程序。如果有太多的错误猜测被送进来，账户可以被暂时锁定，从而将自动化程序延迟到有用的程度，或者甚至可能需要一个人工管理员来解锁。做到这些，应该可以防止应用程序内的反自动化漏洞。

关于 "反自动化不足 "的更多信息

要进一步阅读，你可以看看OWASP对不充分的反自动化是怎么说的。你也可以用Secure Code Warrior 平台的免费演示来测试你新发现的防御知识，该平台培训网络安全团队成为终极网络战士。要了解更多关于击败这个漏洞以及其他威胁的流氓画廊的信息，请访问Secure Code Warrior 博客。

准备好现在就去寻找和修复不足的反自动装置了吗？在我们的游戏竞技场测试你的技能。[从这里开始]

与我们在本分享与学习系列中所涉及的大多数其他漏洞不同，业务逻辑问题与编码错误没有直接关联。虽然编码问题可能是问题的一部分，但业务逻辑错误最常见的原因是设计缺陷或首次创建应用程序时不正确的逻辑假设。

如果用户在使用一个应用程序时采取了意料之外的行动，就会发生业务逻辑问题。这几乎可以是任何事情--从意外地取消一个订单，应用一个优惠券代码太多次，或者只是跳过一个预期的步骤，采取一个应用程序不知道如何处理的行动。利用商业逻辑缺陷甚至不需要任何培训，只需要一个有好奇心的恶意用户愿意跳出盒子思考。

在这一集里，我们将学习。

• 攻击者如何利用商业逻辑中的缺陷
• 为什么存在业务逻辑缺陷的应用程序是危险的
• 可以防止业务逻辑错误的技术。

攻击者是如何利用商业逻辑问题的？

与大多数漏洞不同，我们无法指出可能导致这一漏洞的具体代码串。相反，它归结为用户采取了未曾预料到的行动，而程序不知道如何处理这些行动。举个例子，假设一个银行应用程序允许用户将钱转到其他账户。但是，一个恶意的用户没有汇款，而是试图向另一个账户发送一个负数。银行应用程序将如何反应？它会崩溃吗？它是否会拒绝转账？或者它可能真的把钱寄回给发起转账的用户，以平衡那个负数？

电子商务网站特别容易受到业务逻辑缺陷的影响，尽管不是唯一的，因为它们被设计成由许多用户进行交互，并且有许多组件。用户意外地取消了订单，试图多次应用单一的优惠券，甚至超载他们的购物车，都会给应用程序带来未曾预料的情况。真的没有办法知道一个程序在面对未知情况时将如何反应。最好的情况可能是生成一条错误信息，但不能保证一个应用程序不会采取更糟糕的行动，如免费提供商品。

为什么商业逻辑问题是危险的？

业务逻辑问题可能是非常危险的，因为它们可以被任何人利用，甚至是没有受过编程或黑客训练的人。这真的只需要实验和时间，点击一下，试图找到一个应用程序设计的响应方式的缺陷。而一旦一个恶意的用户发现了一个网站的商业逻辑的缺陷，你可以打赌他们会尽可能地利用它。

最大的危险通常是财务上的，让一个用户购买20台大屏幕电视而不付钱，或者类似的事情。但商业逻辑的缺陷也会引起其他问题。例如，如果保护网站的密码功能不知道在用户不断点击取消时该怎么做，它可能会让用户完全绕过登录过程。

真的没有办法预料一个商业逻辑问题会造成多大的损失。通常情况下，问题的第一个迹象是在用户利用它们之后很长时间才出现的。

修复业务逻辑问题

不幸的是，使用像漏洞扫描器这样的普通工具并不能帮助识别或修复业务逻辑问题，因为业务逻辑问题的测试不容易自动化。避免这些问题的最好方法是在开发应用程序时，对负面测试案例实施良好的规划、错误处理和测试。这首先需要一套明确定义的业务规则，其中包括应用程序被设计为采取的所有可能和期望的行动。

有了业务规则计划，防止业务逻辑缺陷的最好方法之一是创建一个流程图，显示数据和事务在应用程序中流动的所有可能方式。这包括为用户能够做出选择或输入数据的每个实例建立行为模型。不断地检查以确保流程图中可能的行动与业务规则计划中的功能相匹配。

最后，在设计、实施和测试阶段，使用威胁建模来帮助识别业务逻辑的缺陷。作为一个失败保护措施，创建一个程序在遇到任何没有特别预期的情况时应该采取的行动。这可以是简单的拒绝行动并提醒管理员遇到的问题。

关于商业逻辑问题的更多信息

要进一步阅读，你可以看一下OWASP关于商业逻辑问题的网页。你还可以用Secure Code Warrior 平台的免费演示来测试你新发现的防御知识，该平台可以培训网络安全团队成为最终的网络战士。要了解更多关于击败这个漏洞以及其他威胁的流氓画廊，请访问Secure Code Warrior 博客。

准备好现在就去寻找并摧毁商业逻辑漏洞了吗？前往平台，测试你的技能。[从这里开始]

如今，网站和应用程序允许用户通过应用程序使用电子邮件发送反馈、约会提醒和其他各种信息，这很常见。通常情况下，这个过程是相当良性的，大多数人甚至不会考虑到它的潜在安全风险。

然而，像任何其他允许用户输入的设计元素一样，如果配置不当，这些看似无关紧要的功能可以被恶意用户操纵，以达到邪恶的目的。只需让用户有能力在输入栏中输入代码，然后由服务器错误地进行处理。突然间，一个电子邮件应用程序可以变成武器。

在这一集里，我们将学习。

• 攻击者如何触发邮件头的注入
• 为什么电子邮件标题注入是危险的
• 可以修复这个漏洞的技术。

攻击者如何触发邮件头注入？

虽然它不常被认为是可编程的，但大多数电子邮件联系应用程序或放入网站或应用程序的功能可以接受改变查询性质的输入。只是通常在用户将他们的信息，如他们的电子邮件地址，输入合同栏后，由服务器自动完成。然后，该程序会配置信息，添加适当的收件人，并使用其默认的电子邮件服务器将信息发送出去。

一个典型的电子邮件POST请求可能看起来像这样。

POST /contact.php HTTP/1.1
Host: www.example.com

并在用户输入信息后生成这样的代码。

name=RealName&replyTo=RealName@ValidServer.com&message=YourAppointmentReminder

当黑客开始向过程中注入代码而不仅仅是他们的联系信息时，麻烦就出现了。这与SQL注入型攻击并无不同，但却是针对电子邮件应用程序的。一个被操纵的查询的例子是这样的，它将从你的应用程序向目标用户发送垃圾邮件。

name=FakeName\nbcc: SpammedVictim@TargetAddress.com&replyTo= FakeName@ValidServer.com&message=Spammed 消息

为什么电子邮件标题注入是危险的？

根据恶意用户的技能和他们的意图，电子邮件标题注入攻击的严重程度可以从简单的烦人到高度危险。在严重程度的低端，他们可能会把自己的联系信息插入到发送到贵公司内部一个秘密或不公开的邮箱的外发信息的密送字段中，从而将其暴露给黑客。

更令人担忧的是，它可能允许他们完全控制你的电子邮件服务器，从你的组织发送垃圾邮件、网络钓鱼或其他攻击邮件。他们将不需要尝试和伪造电子邮件来自你的内部服务器的事实，因为它实际上是源自那里。如果你没有监测到这一活动，他们甚至可以将这一过程自动化，利用你的组织的服务器发送数百或数千封电子邮件，并以这样一种方式使其看起来像是你在实际煽动这一活动。

消除电子邮件标题注入问题

与 SQL注入和其他此类性质的攻击一样，消除恶意用户利用电子邮件头漏洞的可能性的关键是永远不要相信用户的输入。如果一个用户能够输入信息，即使它看起来是一个微不足道的过程，如输入他们的电子邮件地址，你必须假设最坏的情况。或者至少要假设最坏的情况是可能的。

应该对所有参数进行输入验证，这包括在向应用程序或网站添加电子邮件联系能力时。白名单可以用来专门启用你认为有效的流程和字段，而拒绝其他一切。事实上，大多数框架都有可用的库，可以用来帮助锁定那些需要的功能。这样做将防止恶意用户输入的任何代码或命令被你的服务器识别和处理。

关于邮件标题注入的更多信息

要进一步阅读，你可以看看OWASP对邮件头注入的看法。你还可以用Secure Code Warrior 平台的免费演示来测试你新发现的防御知识，该平台可以培训网络安全团队成为最终的网络战士。要了解更多关于击败这一漏洞以及其他威胁的流氓画廊，请访问Secure Code Warrior 博客。

你认为你现在已经准备好寻找和修复一个电子邮件注入？请到平台上测试你的技能。[从这里开始]

URL是浏览我们所知道和喜爱的所有网站和网络应用程序的关键。它们的基本功能是识别资源的位置以及如何检索它们。虽然URL对于万维网的运行是必要的，但如果不适当地保护，它们也会构成安全风险。

在这篇文章中，我们将学习。

• 什么是IDOR以及攻击者如何使用IDOR
• 为什么IDOR是危险的
• 可以修复这一漏洞的技术

了解IDOR

直接对象引用是指在一个应用程序中引用一个特定的记录（"对象"）。它通常采用唯一标识符的形式，并可能出现在一个URL中。

例如，你可能会注意到在一个URL的末尾有类似"?id=12345 "的东西。这个数字，12345，是对一个特定记录的参考。当个别记录的访问控制不存在时，安全漏洞就会悄然出现。这允许用户访问他们不应该看到的记录和数据。这是一种需要较低技术水平的攻击。

在这个例子中，我们假设攻击者将URL中的ID改为12344。在一个容易受到IDOR影响的应用程序中，攻击者将能够看到与该记录有关的数据。

这种类型的漏洞到底能造成多大的损害？

知道为什么IDOR是危险的

当开发人员不小心时，他们可以设计一个系统，在不同的地方显示和泄露应用记录。这种程度的漏洞可能是重大的，特别是涉及敏感数据或PII时。

澳大利亚税务局建立了一个网站 ，以帮助企业征收新税。不幸的是，它被包装成一个IDOR漏洞的不受欢迎的功能。一个好奇的用户意识到，网站内的URL包含了他的澳大利亚商业号码，或ABN。碰巧的是，这是一个任何注册企业都容易发现的号码。这位用户决定将其他公司的号码放入URL。他得到了他们的银行账户信息和个人详细资料！这是他的天赋。

苹果最近成为一个IDOR漏洞的受害者。当iPad首次发布时，11.4万个客户的电子邮件地址被泄露。公平地说，这更像是AT&T方面的一个错误）。

你看，AT&T建立了一项服务，支持iPad的3G连接。iPad向AT&T的服务发送存储在SIM卡上的标识符。该服务随后返回用户的电子邮件地址。

不幸的是，这些标识符只是连续的整数，因此很容易被猜到。攻击者通过标识符进行迭代并窃取电子邮件地址。

另一个错误是，AT&T的服务试图 "保护 "服务，只在请求的user-agent头显示来自iPad时才返回电子邮件地址。用户代理只是一个字符串值，可以很容易地被操纵。

IDOR漏洞可能是微妙的、偷偷摸摸的。让我们来讨论如何战胜它们。

打败IDOR

访问控制是解决IDOR的关键。当一个用户请求一个特定的记录时，要确保他们被授权查看所请求的记录。

使用集中的授权模块是最好的方法。像Spring Security这样的工具为应用程序提供了强大的、可定制的认证和授权。

一句话：有一个模块，所有其他代码都依赖它来执行授权检查。

另一个常见的缓解措施是使用代用参考。与其在你的URL中使用实际的数据库记录标识符，你可以创建随机数字来映射到实际记录。

使用代理引用可以确保攻击者不能仅仅通过猜测下一个有效的标识符来获得一条记录。

最后，不要依赖用户可以操作的任何东西来提供授权。AT&T试图使用用户代理头来授权他们的服务。不要依赖HTTP头、cookies、或GET和POST参数。

随着这些缓解措施的到位，IDOR将成为过去。

确保你的推荐人

不安全的直接对象引用是最容易被利用的漏洞之一。不要让它们在你最不期望的时候悄悄出现在你面前。总是检查用户是否被授权。不要使用真实的数据库标识符。不要依赖用户控制的数据进行授权。

通过查看我们的学习资源来建立你的掌握能力。通过练习如何在你选择的语言中减轻IDOR漏洞，你将在你的生产代码库中找到并修复这个问题。你还可以通过Secure Code Warrior 平台的免费演示来检验你新发现的防御知识，该平台可以培训网络安全团队成为最终的网络战士。要了解更多关于击败这个漏洞以及其他威胁的流氓画廊，请访问Secure Code Warrior 博客。

准备好现在就抵御IDOR的攻击了吗？前往平台，免费挑战自己。[从这里开始]