大规模的数据泄露和严重的安全漏洞让企业比以往任何时候都更重视安全问题。许多开发人员都熟悉OWASP前10 (https://owasp.org/www-project-top-ten/)，已经有许多关于这些漏洞的通用缓解的资源。相反，在本系列中，我将讨论特定于AEM的安全问题和缓解措施。今天的主题是拒绝服务漏洞。
以前的系列文章:
拒绝服务漏洞
曾经访问一个流行的新网站，却发现它已经崩溃或抛出错误吗?站点访问者可能通过超载服务器处理器或内存无意中导致拒绝服务问题。恶意行为者可以通过向服务器发送大量动作来故意引起相同的问题。
用户触发的JCR节点创建
DoS攻击防范从业务需求开始，通过技术设计进行强化。在设计任何创建新的JCR节点作为其行为一部分的服务(即使是经过验证的服务)时都要非常小心。恶意用户可以通过在JCR中大量写入节点来利用这种行为。更糟糕的是，他们可能能够通过上传新的JSP servlet文件、OSGI配置、OSGI包上传或持久的XSS来实现远程代码执行。因此，应用程序永远不应该在/apps路径下以编程方式创建新的JCR节点。这对于以后在AEM中作为云服务工作是一个很好的实践，其中/apps在部署后是完全不可变的。
如果在设计阶段没有考虑到所有这些，那么在以后可能需要进行大量的重构和数据访问重写。考虑这个例子。您的应用程序中有一个公共API，它在每次接收到请求时都向JCR写入。恶意用户可以快速命中该端点1000次，在系统中创建一个巨大的写队列。那么，如何解决呢?当你试图整理漏洞时，你会删除所有的公共访问吗?这可能会给合法用户带来令人沮丧的体验。相反，让我们来看看一些实际的预防措施。
- 对匿名用户在/content/usergenerated或其他路径上写访问的acl进行双重检查。考虑删除未经身份验证的访问以生成内容。
- 利用IP、用户和/或API键的速率限制。使用僵尸网络或VPN的恶意用户可以在一定程度上规避IP速率限制。而User和API Key速率限制并不会阻止对公共API的访问或页面加载。因此，实现它们的组合以实现全面覆盖是最理想的。
- 考虑为任何经过身份验证的操作实现审计日志记录和速率警报。这将允许您快速识别并撤销任何恶意用户的访问。
- 避免JCR写入和大量内存处理。设置用户可以上传内容的数量和类型的限制。
- 利用漏洞扫描工具，如SonarQube和Checkmarx。它们通常会捕捉用户可以向应用程序输入任意大小或未经验证的参数的漏洞。
- 为新服务执行负载测试——大量调用不应显著降低应用程序的其余部分。
重型加工服务/工作
存在许多在AEM环境中运行作业的用例。这些通常是通过管理内容页面、API端点、Sling调度程序、Sling调度作业或这四种作业的组合开始的。这些都是理想的开始异步通过Sling Jobs、AEM工作流或Adobe IO处理任务，而不是使用即时处理能力。如果使用Sling job和AEM工作流，可以限制实例只使用一定数量的处理器内核，从而减少服务器上的总潜在负载。默认配置设置为可用总内核数量的一半，因此在具有恒定异步处理的应用程序中，降低这个数量可能会很有用。另外，重要的是要注意Adobe推荐永远不要将配置增加到一半以上总内核数。
在任何情况下，我强烈建议使用身份验证+ acl来保护重处理，并且只能从作者环境中访问。然后，数据可以流出到公共数据存储或非云环境中，根据需要复制到发布者。但是现在，复制策略并不常见，因为大量的I/O写操作会导致处理器的混乱和JCR压缩的后期负债。
限制JCR写或谁有权访问服务通常是应该在早期解决方案和业务需求中开始的对话。不要等到技术实现时才进行讨论!利益相关者可能需要为共享数据存储预算额外的资金，或者完全重新考虑如何提供公共服务，从而导致项目延迟或失败。建立关键的利益相关方关系，并尽早针对攻击进行设计。记住，完美的实现本身并不能修复有缺陷的设计。
关于Perficient如何帮助您实现AEM安全目标和实现您的梦想数字体验的更多信息，我们期待您的来信。
接触Perficient开始你的旅程．
