Question

我有以下设置Spring Security并默认拒绝全部（参见下面的示例）。我不想改变默认拒绝所有，因为它是安全配置的防御方式，它也被认为是一种很好的做法。显然，如果用户想要访问一些不存在的页面，他会获得403，因为默认拒绝所有策略。当页面不存在时我想要结果404而当用户有限制访问时我想要403。有没有办法为此行为配置Spring Security？

示例：

    <intercept-url pattern="/posts/remove" access="hasRole('ADMIN')" />
    <intercept-url pattern="/posts/add" access="hasRole('EDITOR')" />
    <intercept-url pattern="/posts" access="permitAll" />
    <intercept-url pattern="/" access="permitAll" />

    <!-- Default is access denied -->
    <intercept-url pattern="/**" access="denyAll" />
</http>

当用户请求/something-that-not-exists时，他应该获得404（非403）。当EDITOR用户请求/posts/remove时，他应该获得403。

Answer 1

我认为你所做的一个假设是不正确的。你说：

当用户请求/不存在的东西时，他应该得到404（非403）

这与以下内容直接冲突：

<intercept-url pattern="/**" access="denyAll" />

因为/something-that-not-exists是受保护资源是否存在。作为未经身份验证的用户，您不应该问“问题/something-that-not-exists是否包含有效资源？”这样做违反了安全模型。想象一下这些假设的网址：

假设此网址存在：

/admin/accounts/email/miles@example.com

经过身份验证的用户应获得200 OK响应。未经身份验证的用户应重定向到登录页面。

现在假设此网址不存在：

/admin/accounts/email/coltrane@example.com

经过身份验证的用户应获得404 NOT FOUND响应。未经身份验证的用户应重定向到登录页面。

如果我们将404返回给未经身份验证的用户，我们会泄露安全漏洞，攻击者可以通过电子邮件地址查询系统中是否存在用户。

因此，您需要重新考虑上述假设或denyAll规则，因为它们是互斥的。

Answer 2

我不确定这样的配置是否可行，因为安全过滤器在您的webapp的URL映射逻辑甚至有机会确定是否有任何资源要响应之前，在早期阶段拦截并处理请求对那个特殊的要求如果安全过滤器决定通过匹配请求URL来拒绝访问，那么如果该URL后面有一个页面，它将永远不会被证明。

编辑（对Michal评论的回应）：

由于url到资源/处理程序的映射在每个应用程序中几乎是任意的，因此没有框架可能提供通常适用于每个webapp的算法，并且可以提前确定映射过程的结果。

如果您可以为 webapp实现此类逻辑（例如，通过了解其整个网址空间），您可以非常轻松地创建您建议的过滤器。如果您碰巧使用Spring MVC，则在应用程序中部署的每个HandlerMapping上调用getHandler()可以帮助实现此类过滤器。

无论如何，我认为提供这种设施不可能是一个独立的安全库，并且能够与各种不同的Web框架协同工作。

页面不存在时，在未经授权的URL上找不到404页面

2 个答案:

编辑（对Michal评论的回应）：