2

我有以下 Spring Security 设置，默认全部拒绝（参见下面的示例）。我不想更改默认的deny all，因为它是安全配置的防御方式，也被认为是一种好的做法。显然，如果用户想要访问一些不存在的页面，他会得到 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。

4

2 回答 2

2

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

当用户请求 /something-that-not-exists 时，他应该得到 404（不是 403）

这与以下内容直接冲突：

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

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

假设这个 url 存在：

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

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

现在假设这个 url不存在：

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

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

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

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

于 2013-10-18T22:58:58.620 回答
0

我不确定这种配置是否可行，因为安全过滤器会在您的 web 应用程序的 URL 映射逻辑甚至有机会确定是否有任何资源可以响应该特定请求之前拦截并处理请求要求。
如果安全过滤器决定通过匹配请求 URL 来拒绝访问，那么它永远不会证明该 URL 后面是否存在页面。

编辑（回应米哈尔的评论）：

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

如果你可以为你的webapp 实现这样的逻辑（例如通过知道它的整个 url 空间），你可以很容易地创建你建议的过滤器。如果您碰巧使用 Spring MVC，调用应用程序中部署的getHandler()每一个都可以帮助实现这样的过滤器。HandlerMapping

无论如何，我猜想提供这种设施不可能在一个安全库的范围内，因为它是独立的并且能够与各种不同的 Web 框架一起工作。

于 2013-05-05T07:57:57.833 回答