前后端分离架构中的接口安全_如何立即确保您的应用架构安全：分离，配置和访问
前后端分离架构中的接口安全
如果您是忙碌的开发人员，那么本文将是构建安全应用程序体系结构的一个很好的起点。 (If you're a busy developer, this article will be a good starting point for building secure application architecture.)
Developers today get to focus more on building software than they were able to in the past, and that’s a great thing.
与过去相比，今天的开发人员现在更加专注于构建软件，这是一件了不起的事情。
We’re benefitting from maker culture, an attitude of “always be shipping,” open source collaboration, and a lots of apps that help us prioritize and execute with maximum efficiency.
我们从制造商文化，“永远待出货”的态度，开源协作以及许多应用程序中受益，这些应用程序可帮助我们以最高效率确定优先级并执行。
We’re in an environment of constant creation, where both teams and solo entrepreneurs can be maximally productive.
我们处于不断创造的环境中，团队和独资企业家都可以最大限度地提高生产力。
But sometimes this breakneck-speed productivity shows its downsides.
但是有时，这种惊人的速度生产率却显示出其缺点。
As I learn more about security best practices, I can’t help but see more and more applications that don’t have a clue. Their developers seem to have a a general lack of awareness of security. This leads to a lack of prioritization of tasks that don’t directly support bringing the product to launch.
当我了解有关安全性最佳做法的更多信息时，我不禁会看到越来越多的毫无头绪的应用程序。 他们的开发人员似乎普遍缺乏安全意识。 这导致缺少不能直接支持将产品发布的任务的优先级。
The market seems to have made it more important to launch a usable product than a secure one. The prevailing attitude is: “we can do the security stuff later.”
市场似乎使得发布可用产品比购买安全产品更为重要。 普遍的态度是：“我们以后可以做一些安全工作。”
Building a foundation based on expediency rather than longevity is a bad way to build applications. It's a great way to build security debt.
基于权宜之计而非长寿建立基础是构建应用程序的一种糟糕方法。 这是建立担保债务的好方法。
Security debt, like technical debt, amasses when developers make (usually hasty) decisions that can make it more difficult to secure the application later on.
安全债务(例如技术债务)会在开发人员做出(通常是仓促的)决策时造成麻烦，从而使以后更难保护应用程序。
If you’re familiar with the concept of “pushing left” (or if you read my article about sensitive data exposure), you’ll know that when it comes to security, sometimes there isn’t a version of “later” that isn’t too late.
如果您熟悉“向左推”的概念(或者阅读了有关敏感数据公开的文章 )，那么您会知道，在安全性方面，有时没有“后推”的版本还不算太晚。
It’s a shame, since following some basic security practices with high benefit yield early in the development process doesn’t take significantly more time than not following them. Often, it comes down to having some basic but important knowledge that helps you to make the more secure decision.
很遗憾，因为在开发过程的早期就遵循一些具有高收益的基本安全实践并不会比不遵循它们花费更多的时间。 通常，归结为拥有一些基本但重要的知识，可以帮助您做出更安全的决策。
While application architecture varies greatly, there are a few basic principles you can apply. This article will give you a high-level overview of these areas and point you in the right direction.
尽管应用程序体系结构差异很大，但是您可以应用一些基本原则。 本文将为您提供这些领域的高级概述，并为您指明正确的方向。
There must be a reason we call it application “architecture.” I like to think it’s because the architecture of software is similar in some basic ways to the architecture of a building. (Or at least, in my absolute zero building-creation expertise, how I imagine a pretty utilitarian building to be.)
我们称其为应用程序“架构”肯定是有原因的。 我喜欢认为这是因为软件的体系结构在某些基本方面与建筑物的体系结构相似。 (或者至少，以我的绝对零建筑专业知识，我如何想象一个相当实用的建筑。)
Here’s how I like to summarize three basic points of building secure application architecture:
我喜欢这样总结构建安全应用程序体系结构的三个基本点：
- Separated storage 分开存放
- Customized configuration 定制配置
- Controlled access and user scope 受控访问和用户范围
This is only a jumping-off point meant to get us started on the right foot. A complete picture of a fully-realized application’s security posture includes areas outside the scope of this post, including authentication, logging and monitoring, integration, and sometimes compliance.
这只是一个起点，旨在使我们从右脚开始。 完整实现的应用程序的安全状态的完整图片包括本文范围之外的领域，包括身份验证，日志记录和监视，集成，有时还包括合规性。
1.分开存放 (1. Separated storage)
From a security standpoint, the concept of separation refers to storing files that serve different purposes in different places.
从安全的角度来看，分离的概念是指在不同位置存储服务于不同目的的文件。
When you’re constructing a building and deciding where all the rooms go, you create the lobby on the ground floor. Administrative offices go on higher floors, usually off the main path. While both a lobby and offices are rooms, you understand that they serve different purposes. They also have different functional needs, and very different security requirements.
当您建造建筑物并确定所有房间的位置时，您将在底层创建大厅。 行政办公室位于较高楼层，通常不在主要路径上。 大厅和办公室都是房间，但您知道它们有不同的用途。 它们还具有不同的功能需求和非常不同的安全性要求。
When it comes to your files, the benefit is perhaps easiest to understand if you consider a simple file structure:
对于文件，如果考虑简单的文件结构，则可能最容易理解好处：
application/
├───html/
│ └───index.html
├───assets/
│ ├───images/
│ │ ├───rainbows.jpg
│ │ └───unicorns.jpg
│ └───style.css
└───super-secret-configurations/
└───master-keys.txtIn this simplified example, let’s say that all your application’s images are stored in the application/assets/images/ directory. When one of your users creates a profile and uploads their picture to it, this picture is also stored in this folder. Makes sense, right? It’s an image, and that’s where the images go. What’s the issue?
在此简化示例中，假设您的所有应用程序映像都存储在application/assets/images/目录中。 当您的一个用户创建配置文件并将其图片上传到该配置文件时，该图片也存储在此文件夹中。 有道理吧？ 这是一幅图像，这就是图像的来源。 怎么了
If you’re familiar with navigating a file structure in a terminal, you may have seen this syntax before: ../../. The two dots are a handy way of saying, “go up one directory.” If you execute the command cd ../../ in the images/ directory of the simple file structure above, you’d go up into assets/, then up again to the root directory, application/. This is a problem because of a wee little vulnerability dubbed path traversal.
如果您熟悉在终端中导航文件结构，则可能在以下位置看到过这种语法： ../../ 。 这两个点是一种方便的说法，即“进入一个目录”。 如果您在上面的简单文件结构的images/目录中执行命令cd ../../ ，您将进入assets/ ，然后再次进入根目录application/ 。 这是一个问题，因为很少有被称为路径遍历的漏洞。
While the dot syntax saves some typing, it also introduces the interesting advantage of not actually needing to know what the parent directory is called in order to go to it.
尽管点语法节省了一些键入操作，但它还引入了有趣的优点，即实际上不需要知道要转到父目录的名称。
Consider an attack payload script, delivered into the images/ folder of this insecure application, that went up one directory using cd ../ and then sent everything it found to the attacker, on repeat. Eventually, it would reach the root application directory and access the super-secret-configurations/ folder. Not good.
考虑一个攻击有效载荷脚本，该脚本传递到此不安全应用程序的images/文件夹中，该脚本使用cd ../进入一个目录，然后将发现的所有内容重复发送给攻击者。 最终，它将到达根应用程序目录并访问super-secret-configurations/文件夹。 不好。
While other measures should be in place to prevent path traversal and related user upload vulnerabilities, the simplest prevention by far is a separation of storage. Core application files and assets should not mix with other data, and especially not with user input. It’s best to keep user-uploaded files and activity logs (which may contain juicy data and can be vulnerable to injection attacks) separate from the main application.
尽管应该采取其他措施来防止路径穿越和相关的用户上载漏洞，但到目前为止，最简单的预防措施是隔离存储。 核心应用程序文件和资产不应与其他数据混合，尤其不能与用户输入混合 。 最好将用户上传的文件和活动日志(可能包含多汁的数据，并且容易受到注入攻击)与主应用程序分开。
You can achieve separation by using a different server, different instance, separate IP range, or separate domain.
您可以通过使用不同的服务器，不同的实例，单独的IP范围或单独的域来实现分离。
2.定制配置 (2. Customized configuration)
While wasting time on customization can hinder productivity, one area that you want to customize is configuration settings.
尽管浪费时间进行自定义会影响生产率，但是要自定义的一个方面是配置设置。
Security misconfiguration is listed in the OWASP Top 10. A significant number of security incidents occur because a server, firewall, or administrative account is running in production with default settings. Upon the opening of your new building, you’d hopefully be more careful to ensure you haven’t left any keys in the locks.
OWASP Top 10中列出了安全性配置错误 。发生大量安全事件是因为服务器，防火墙或管理帐户正在使用默认设置在生产环境中运行。 希望在新建筑开放时，您将更加小心以确保您没有在锁中留下任何钥匙。
Usually, the victims of attacks related to default settings aren’t specifically targeted. They are instead found by automated scanning tools that attackers run over many possible targets. These attackers are testing many different systems to see if any roll over and expose a useful exploit.
通常，与默认设置有关的攻击的受害者并不是专门针对的。 相反，它们是由自动扫描工具发现的，攻击者可以在许多可能的目标上运行它们。 这些攻击者正在测试许多不同的系统，以查看是否有任何翻转并暴露出有用的漏洞。
The automated nature of this attack means that it’s important to review settings for every piece of the architecture. Even if an individual piece doesn’t seem significant, it may provide a vulnerability that gives an attacker a gateway to the application.
这种攻击的自动性质意味着，必须检查架构中每个部分的设置，这一点很重要。 即使单个部分看起来并不重要，它也可能提供一个漏洞，使攻击者可以访问应用程序。
In particular, examine architecture components for unattended areas such as:
特别是，检查架构组件的无人值守区域，例如：
- Default accounts, especially with default passwords, left in service; 保留默认帐户，尤其是具有默认密码的帐户；
- Example web pages, tutorial applications, or sample data left in the application; 示例网页，教程应用程序或应用程序中剩余的示例数据；
- Unnecessary ports left in service, or ports left open to the Internet; 不必要的端口保留在服务中，或端口保留给Internet开放；
- Unrestricted permitted HTTP methods; 不受限制的允许的HTTP方法；
- Sensitive information stored in automated logs; 敏感信息存储在自动日志中；
- Default configured permissions in managed services; and, 托管服务中的默认配置权限； 和，
- Directory listings, or sensitive file types, left accessible by default. 默认情况下，目录列表或敏感文件类型不可访问。
This list isn’t exhaustive. Specific architecture components, such as cloud storage or web servers, will have other configurable features to review. In general, reduce the application’s attack surface by using minimal architecture components. If you use fewer components or don’t install modules you don’t need, you’ll have fewer possible attack entry points to configure and safeguard.
此列表并不详尽。 特定的体系结构组件(例如云存储或Web服务器)将具有其他可配置的功能以供查看。 通常，通过使用最少的体系结构组件来减少应用程序的攻击面。 如果使用较少的组件或不安装不需要的模块，则可以配置和保护的攻击入口点将更少。
3.受控的访问和用户范围 (3. Controlled access and user scope)
One of the more difficult security problems to test in an application is misconfigured access control. Automated testing tools have limited capability to find areas of an application that one user shouldn’t be able to access. This is often thus left to manual testing or source code review to discover.
应用程序中最难以测试的安全问题之一是访问控制配置错误。 自动化测试工具在查找一个用户不应该访问的应用程序区域的能力有限。 因此，通常将其留给手动测试或检查源代码来发现。
Developers can reduce the risk that this becomes are hard problem to fix later. Consider this vulnerability early on in the software development lifecycle, when architectural decisions are being made. After all, you wouldn’t simply leave your master keys out of reach on a high ledge and hope no one comes along with a ladder.
开发人员可以减少这种风险，以后再很难解决。 在制定体系结构决策时，请尽早在软件开发生命周期中考虑此漏洞。 毕竟，您不会简单地将万能钥匙放在遥不可及的高架上，并希望没有人会随梯而行。
Broken access control is in the OWASP Top 10, which goes into more detail on its various forms. As a simple example, consider an application with two levels of access: administrators, and users. Developers want to build a new feature - the ability to moderate or ban users - with the intention that only administrators would be allowed to use it.
OWASP Top 10中有损坏的访问控制 ，其中详细介绍了其各种形式。 举一个简单的例子，考虑一个具有两个访问级别的应用程序：管理员和用户。 开发人员希望构建新功能-审核或禁止用户的功能-旨在仅允许管理员使用该功能。
If you’re aware of possible access control vulnerabilities, you may decide to build the moderation feature in a separate area from the user-accessible space. This may be on a different domain, or as part of a model that users don’t share. This reduces the risk that an access control misconfiguration or elevation of privilege vulnerability might allow a user to improperly access the moderation feature later on.
如果您知道可能的访问控制漏洞，则可以决定在与用户可访问空间不同的区域中构建审核功能。 这可能在不同的域上，或者作为用户不共享的模型的一部分。 这降低了访问控制配置错误或特权提升漏洞可能使用户以后无法正确访问审核功能的风险。
Of course, robust access control in your application needs more support to be effective. Consider factors such as sensitive tokens, or keys passed as URL parameters, or whether a control fails securely or insecurely. Even so, by considering authorization at the architectural stage, you will set yourself up to make further reinforcements easier.
当然，应用程序中强大的访问控制需要更多支持才能有效。 考虑诸如敏感令牌或作为URL参数传递的密钥之类的因素，或者控件是安全还是不安全地失败。 即使如此，通过在架构阶段考虑授权，您仍可以进行设置以使进一步的增强变得容易。
安全基础知识，带来最大收益 (Security basics for maximum benefit)
Developers avoid racking up technical debt by choosing a well-vetted framework. Similarly, developers avoid security debt by becoming aware of common vulnerabilities and the architectural decisions that can help mitigate them. For a much more detailed resource on how to bake security into applications from the start, the OWASP Application Security Verification Standard is a robust guide.
通过选择经过严格审查的框架，开发人员可以避免增加技术负担。 同样，开发人员可以通过意识到常见漏洞和有助于缓解这些漏洞的体系结构决策来避免安全隐患。 有关如何从一开始就将安全性纳入应用程序的更详细的资源， OWASP应用程序安全验证标准是一本可靠的指南。
翻译自: https://www.freecodecamp.org/news/secure-application-basics/
前后端分离架构中的接口安全