在访问控制层之前先具有验证层是否可以

我正在创建一个API组合式Web应用程序，在此应用程序中，我们有不同的层，各自在工作。

第一层是验证用户输入的验证层，如果通过验证，则将其移至第二层（即访问控制层），否则返回错误消息

第二层是访问控制，它检查用户是否具有执行其想要执行的任务的权限，如果用户具有权限，则将请求移至下一层，否则返回错误消息

第三层是控制器层，我们具有应用逻辑

我的问题是在访问控制之前可以具有验证层吗？如果用户尝试执行用户没有权限的任务并且我们正在发回验证错误消息怎么办？用户将向端点发送请求并与验证层进行对话，并且仅在通过验证之后，他才会看到消息You can't access this!

我觉得很奇怪，所以这样还好吗？或者在基础设施方面我还有其他选择吗？

这取决于是否知道不允许您执行某项任务的某些输入的有效性是否存在安全漏洞。如果是这样，您确实应该反过来做。

对未授权用户的唯一安全响应是“拒绝访问”。如果有时响应是“错误请求”，而有时是“拒绝访问”，则说明您正在向未经授权的用户发送信息。

例如，您可以检查是否存在命名文件存在的“删除文件”任务。没有权限的人可以通过尝试删除某事物并比较它们收到的错误来辨别某事物是否存在。特别确定的攻击者可以枚举所有文档名称（一定长度以下），以查看存在的名称。

好吧，验证有多种类型：

1. 廉价的基本健全性检查，可以验证请求是否显然没有格式错误。

   这通常是至少部分重复的客户端，以避免徒劳的往返。

   无论如何，应该在访问控制之前完成它，以使事情变得更容易且更不易出错，因为它不会冒任何信息泄漏的风险。

2. 验证更昂贵，仍然不依赖于任何受保护的应用程序数据。

   如果有这样的额外验证，则可能是在访问控制之后才避免泄漏数据，而是阻止DOS攻击。
   有时，仅执行请求就可以以减少的成本或无成本的方式隐式地执行某些验证，因此此处可能将其省略。

   如果第一步的所有验证都重复了，那么也应该重复此客户端的某些部分。

3. 其他验证取决于受保护的应用程序数据。

   在访问控制之前执行此操作显然会导致信息泄漏。因此，首先要进行访问控制。

访问控制之前必须进行一些验证。假设SO的API有一个端点“编辑答案”，那么用户是否可以编辑特定的答案取决于答案（在一定信誉以下，用户只能编辑自己的答案）。因此，格式正确的“答案ID”参数必须在访问控制层生效之前进行验证；答案也可能存在。

正如Caleth和Greg所提到的，OTOH在访问控制之前进行了更广泛的验证，这是潜在的安全风险。

所以硬规则是

1. 您不得通过验证泄露用户不应该发现的任何信息。
2. 您必须先验证数据，然后访问控制才能在访问控制需要的范围内使用它。

遵循这两个规则可能意味着您必须在访问控制之前和之后进行一些验证。

验证输入后，除了可能收到“拒绝访问”之外，还可能感到沮丧；还请记住，除非非常简单，否则Validation层始终可以需要Controller的信息。牢记这一点，我认为将Validation定位在Access Control之后，更靠近Controller更为有意义。

这取决于验证层的含义-如果仅是检查请求的语法，那是安全的，无论如何您都必须做。如果您的“验证”使用了非特权用户无法访问的任何信息，则它不再安全。

在尝试进行访问控制之前，您绝对应该具有健全性检查器，但您应注意与所有维护人员（当前和将来）非常清楚地交流该部分一定不能使用特权信息；验证后，应在单独的验证步骤中进行任何此类检查。

作为健全性检查程序的健全性检查，它实际上不应该对代码的任何部分都具有任何代码依赖关系，而且应将其分离到自己的程序包中，该程序包应公开发布而不会出现任何问题（可能的法律问题除外）。 。如果您不能这样做，那么您的“验证层”做得太多（或者您的代码库很混乱）。

不，这不行。

如果验证层中有错误，则可能会绕过安全层。

将安全性视为业务需求的一部分是一个常见的错误。“只有具有销售角色的用户才能看到季度数字”似乎是一项业务规则。

但是，如果您想确保安全，则必须阅读以下规则：“只有销售角色的用户才能在此端点上运行代码”。确保服务器始终返回“访问被拒绝”您在服务器上编写的任何类型的代码或文件。