Question

我有一个asp.net应用程序。有MVC控制器和WebAPI控制器。对于cookie身份验证，我使用app.UseCookieAuthentication(...中间件和DefaultAuthenticationTypes.ApplicationCookie身份验证类型，对于oauth我使用app.UseOAuthBearerTokens(...中间件。对于MVC部分，我将AuthorizeAttribute添加为全局以防止匿名访问。有趣的是，我可以从MVC控制器获取数据，也可以通过oauth获取访问令牌。我知道oauth中间件在处理请求时使用令牌设置当前用户。现在我为MVC部件添加了额外的属性来拒绝具有身份验证类型的用户！= DefaultAuthenticationTypes.ApplicationCookie。因此，使用令牌的请求仅适用于WebAPI。这是一个好方法还是我做错了什么？

Answer 1

这是一个好方法吗？

不是真的，它不是您要阻止的身份验证机制，您可能想限制对MVC前端（剃刀模板）的访问。您可以使用自定义过滤器，类似于对ASP.NET MVC preventing users from direct URL的响应中所说明的方法，只是您的过滤器应检查Request.Url.Host是否在已知端点列表中。

using System;
using System.Web.Mvc;
using System.Web.Routing;

namespace Customer.Filters
{
    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]
    public class PreventFromUrl : ActionFilterAttribute
    {
        public override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            // MVC requests will originate from the same host as the server
            // external apps may not have a referrer or it will be from a different domain
            // If you have your own non-mvc code, in the same domain, we trust you know what you're doing :)
            if (filterContext.HttpContext.Request.UrlReferrer == null 
                || filterContext.HttpContext.Request.Url.Host != filterContext.HttpContext.Request.UrlReferrer.Host)
            {
                return new HttpStatusCodeResult(HttpStatusCode.Forbidden);
            }
        }
    }
}

如果过滤器不起作用，请考虑将您的Web API移至单独的项目，但是请注意，这实际上只是出于安全性的考虑，因此仍可以使用基于cookie的身份验证来访问您的MVC端点呼叫者通过身份验证之后。

仅使用身份验证类型并不能带来任何其他的安全优势，您只是说每条路由都需要特定的身份验证方法，您并未做任何拒绝访问本身的事情。

您希望所有非MVC流量都使用OAuth，但是由于您的站点支持cookie，因此外部应用仍然可以通过编程方式合法地使用基于cookie的身份验证，并可以访问您的MVC控制器端点。

拒绝访问MVC控制器重要吗？

在编写应用程序逻辑时，应始终牢记安全性，服务器端控制器不应依赖于前端来验证和清除用户输入，在用户界面中表达的任何业务规则和验证也应在控制器逻辑。

首先在后端，在控制器中执行和设计验证以及业务规则。
  由于前端脚本是在客户端上执行的，因此它们处于更加脆弱的状态。捕获和监视前端发送回客户端的流量非常简单，因此您可以通过在将数据发送回服务器之前处理数据来解决客户端验证。


更糟糕的是，不断发展的客户端技术可能会导致客户端脚本和逻辑无法评估您最初期望的方式的情况，从而意外地使未经验证或无效的数据流过。

当控制器执行所有业务规则验证时（如我们在Web API中所限制的那样），那么通常来说，最终客户端是您期望的MVC客户端还是自定义编写的内容，都没有关系。即使有人编写了用于自动化或模拟有效用户的应用程序，如果调用者已通过合法身份验证，也可以让他们进入，因为否则他们可以直接通过MVC网站手动或通过API登录。

在这种情况下，或者当您的MVC应用程序公开的数据量超过允许外部客户端的数据量时，在MVC应用程序中将验证置于用户界面级别并跳过在服务器端执行相同的检查非常容易。要访问它，对于非mvc调用者拒绝访问这些MVC路由就变得很重要。

通常，支持多种身份验证机制是API的一种好方法，因为它扩展了客户端可用于与API交互的选项。因此，支持多种类型的auth访问WebAPI路由 IS 是一个好方法。

这种情况使您的前端很容易通过MVC控制器和WebAPI访问数据。我遇到的一个常见情况是使用API保护对外部文件和图像的访问。我们可以将资源端点的URL直接放入并使用用户浏览器中已经存在的auth cookie来通过API进行访问。

支持多重身份验证机制或提供程序将增加API的攻击面。这不一定是一件坏事，但这是需要注意和审核的事情。

攻击面的增加并不意味着服务会更容易受到攻击，而是意味着您的身份验证中存在更多潜在的故障点。

针对同一应用程序中的WebAPI的MVC和OAuth的Cookie身份验证

1 个答案:

这是一个好方法吗？