web应用程序体系结构_安全应用程序体系结构的基础-分离，配置和访问

web应用程序体系结构

为忙碌的开发人员构建安全应用程序体系结构的起点

鼓励当今的软件开发人员专注于构建，这是一件了不起的事情。 我们受益于制造商的文化，“永远出货”的态度，开放源代码的协作以及各种各样的应用程序，这些应用程序可以帮助我们以最高的效率确定优先级并执行。 我们处于不断创造的环境中，团队和独资企业家都可以最大限度地提高生产力。

有时，这种惊人的速度生产率显示出其缺点。

当我了解有关安全性最佳做法的更多信息时，我不禁会看到越来越多的毫无头绪的应用程序。 缺乏安全意识似乎导致对那些不直接支持将产品发布的任务的优先级缺乏。 市场似乎使得发布可用产品比购买安全产品更为重要。 普遍的态度似乎是“我们以后可以做一些安全工作”。

将更多基于权宜之计而不是长久性的基础拼凑在一起是构建应用程序的坏方法，也是构建安全债务的好方法。 通过制定（通常是仓促的）决策，积累了技术债务等安全债务，这些决策可能会使以后更难保护应用程序。

如果您熟悉“向左推”的概念（或者阅读了有关敏感数据公开的文章 ），那么您会知道，在安全性方面，有时没有“后推”的版本还不算太晚。 真可惜，特别是因为在开发过程的早期就遵循一些具有高收益的基本安全实践不会比不遵循它们花费更多的时间。 通常，归结为拥有一些基本但重要的知识，使您能够做出更安全的决策。

尽管应用程序体系结构差异很大，但通常可以应用一些基本原理。 本文将提供有关这些领域的高级概述，我希望这些领域可以帮助开发人员指明正确的方向。

我们将其称为应用程序“架构”肯定是有原因的，我想认为这是因为软件的架构在某些基本方式上与建筑物的架构相似。 （或者至少，以我的绝对零建筑创建专业知识，我如何想象一个相当实用的建筑。）这就是我喜欢总结构建安全应用程序体系结构的三个基本点的方法：

1. 分开存放
2. 定制配置
3. 受控访问和用户范围

这只是一个起点，旨在使我们从右脚开始。 完整实现的应用程序的安全状态的完整图片包括本文范围之外的领域，包括身份验证，日志记录和监视，集成，有时还包括合规性。

1.分开存放

从安全的角度来看，分离的概念是指在不同位置存储服务于不同目的的文件。 当我们建造建筑物并确定所有房间的去向时，我们同样在底楼创建了大厅，并在更高的楼层（可能不在主要路径上）放置了行政办公室。 虽然两者都是房间，但我们了解它们的用途不同，功能需求不同，并且可能对安全性的要求也非常不同。

如果我们考虑一个简单的文件结构，那么对于我们的文件而言，好处也许是最容易理解的：

application/
 ├───html/
 │   └───index.html
 ├───assets/
 │   ├───images/
 │   │   ├───rainbows .jpg
 │   │   └───unicorns .jpg
 │   └───style .css
 └───super-secret-configurations/
     └───master-keys.txt

在我们的简化示例中，假设我们所有应用程序的图像都存储在application / assets / images /目录中。 当我们的一个用户创建配置文件并将其上传到个人资料时，该图片也存储在此文件夹中。 有道理吧？ 这是一幅图像，这就是图像的来源。 怎么了

如果您熟悉在终端中导航文件结构，则可能在以下位置看到过这种语法： ../../ 。 这两个点是一种方便的说法，即“进入一个目录”。 如果我们在上述简单文件结构的images/目录中执行命令cd ../../ ，我们将进入assets/ ，然后再次进入根目录application/ 。 这是一个问题，因为很少有被称为路径遍历的漏洞。

尽管点语法为我们节省了一些输入时间，但它还引入了有趣的优点，即实际上不需要知道要转到父目录的名称。 考虑一个攻击有效载荷脚本，该脚本传递到我们不安全的应用程序的images /文件夹中，该脚本使用cd ../进入一个目录，然后将找到的所有内容重复发送给攻击者。 最终，它将到达根应用程序目录并访问super-secret-configurations /文件夹。 不好。

当然应该采取其他措施来防止路径穿越和相关的用户上载漏洞，但到目前为止，最简单的预防措施是隔离存储。 核心应用程序文件和资产不应与其他数据结合，尤其不能与用户输入结合 。 最好将用户上传的文件以及活动日志（可能包含多汁的数据，并且容易受到注入攻击）与主应用程序分开。

可以通过几种方式来实现分离，例如通过使用不同的服务器，不同的实例，单独的IP范围或单独的域。

2.定制配置

在某些情况下，快速开发可能会花很多时间在定制上，而我们肯定要定制的一个领域是配置设置。 OWASP Top 10中列出了安全性错误配置 ，因为发生了许多安全事件，因为服务器，防火墙或管理帐户正在生产中运行且正在使用默认设置。 希望在我们的新大楼开放后，我们将更加小心以确保没有在锁中留下任何钥匙。

通常，与默认设置有关的攻击的受害者并不是专门针对的。 相反，它们是通过自动扫描工具发现的，攻击者可以在许多可能的目标上运行，从而有效地对许多不同的系统进行探测，以查看是否存在任何过渡并公开一些有用的漏洞。 这种攻击的自动化性质意味着对我们来说，审查架构中每个部分的设置非常重要。 即使单个部分看起来并不重要，它也可能提供一个漏洞，攻击者可以利用该漏洞将其用作我们更大的应用程序的网关。

尤其要检查架构组件的无人值守区域，例如：

• 保留默认帐户，尤其是具有默认密码的帐户；
• 示例网页，教程应用程序或应用程序中剩余的示例数据；
• 不必要的端口仍在服务中，或端口仍可打开到Internet；
• 不受限制的允许的HTTP方法；
• 敏感信息存储在自动日志中；
• 托管服务中的默认配置权限； 和，
• 目录列表或敏感文件类型，默认情况下仍可访问。

此列表并不详尽，并且特定的体系结构组件（例如云存储或Web服务器）将具有可配置的其他功能，因此应进行检查。 一般而言，在架构组件方面，我们应尽量简化，以减少应用程序的攻击面。 如果我们使用更少的组件或不安装我们真正不需要的模块，我们将可以配置和保护的攻击入口点也更少了。

3.受控访问和用户范围

在应用程序中要测试的最困难的安全问题之一是访问控制配置不当。 自动化测试工具在查找一个用户不应该访问的应用程序区域方面的能力有限。 因此，这通常留给手动测试或源代码审查来发现。 通过在制定体系结构决策的软件开发生命周期中尽早考虑此漏洞，我们降低了该漏洞成为以后很难修复的问题的风险。 毕竟，我们不会只是简单地将万能钥匙放在遥不可及的地方，并希望没有人会随梯而来。

OWASP Top 10中列出了损坏的访问控制 ，其中详细介绍了各种形式。 举一个简单的例子，考虑一个具有两个访问级别的应用程序：管理员和用户。 我们可能会为我们的应用程序构建功能，例如审核或禁止用户的功能，目的是仅允许管理员使用该功能。 如果我们意识到访问控制配置错误或利用的可能性，我们可以决定在与用户可访问空间完全不同的区域（例如，在不同域中）或作为用户模型的一部分来构建审核功能不分享。 这极大地降低了访问控制配置错误或特权提升漏洞可能使用户以后无法正确访问审核功能的风险。

当然，在我们的应用程序中，强大的访问控制需要有效的进一步支持。 因此，我们应该考虑诸如URL传递的敏感令牌或密钥之类的因素，或者控件是否安全失败。 但是，通过在架构阶段考虑授权，我们可以进行自我设置，以使进一步的增强功能更易于实施。

最大收益的安全基础

类似于通过选择经过良好审查的框架来避免增加技术债务，开发人员可以通过了解常见漏洞和我们可以帮助缓解这些漏洞的简单体系结构决策来避免安全债务。

有关如何从一开始就将安全性应用到我们的应用程序中的详细信息， OWASP应用程序安全验证标准是一个可靠的指南。

翻译自: https://hackernoon.com/secure-application-architecture-basics-separation-configuration-and-access-nc1fo2884

web应用程序体系结构