ASP.NET Web API安全筛选器，如何应对攻击？

原文：https://msdn.microsoft.com/zh-cn/magazine/dn781361.aspx 身份验证和授权是应用程序安全的基础。身份验证通过验证提供的凭据来确定用户身份，而授权则决定是否允许用户执行请求的操作。安全的 Web API 身份验证基于确定的身份请求和授权用户请求的资源访问。 您可以在 ASP.NET Web API 中使用 ASP.NET Web API 管道中提供的扩展点，以及使用由主机提供的选项来实现身份验证。对于 ASP.NET Web API 的第一个版本，常见的做法是使用授权筛选器或操作筛选器来实现身份验证。ASP.NET Web API 2 引入了一个专门用于此过程的新的身份验证筛选器。这种新的扩展点使身份验证和授权问题被清晰地划分开。在本文中，我会向您介绍这两种安全筛选器，并将身份验证和授权作为 ASP.NET Web API 中独立的两个方面，向您演示如何使用它们来实现将身份验证和授权。 实现安全性方面的选项 通过使用由主机提供的扩展点以及由 ASP.NET Web API 管道自己提供的扩展点能够实现 ASP.NET Web API 中的身份验证和授权。基于主机的选项包括 HTTP 模块和 OWIN 中间件组件，而 ASP.NET Web API 的扩展选项包括消息处理程序、操作筛选器、授权筛选器以及身份验证筛选器。 基于主机的选项很好地集成到主机管道中，并能较早拒绝管道中的无效请求。另一方面，ASP.NET Web API 的扩展选项对身份验证过程提供更精细的控制水平。也就是说，您可以对不同的控制器甚至不同的操作方法设置不同的身份验证机制。权衡与主机更好地集成在一起，并较早对不佳的身份验证粒度请求予以拒绝。除了这些常规特性，每个选项都有自己的优缺点，我将在后面的章节中进行介绍。 HTTP 模块这是在 IIS 上运行的一个 Web API 选项。作为 IIS 管道的一部分，HTTP 模块允许较早地执行安全代码。从 HTTP 模块中建立的主体适用于所有的组件，包括管道中稍后运行的 IIS 组件。例如，如果主体是由响应 AuthenticateRequest 事件的 HTTP 模块构建的，则主体的用户名将被正确地记录在 IIS 日志的 cs-username 字段中。HTTP 模块的最大缺点是缺乏粒度。HTTP 模块对进入应用程序的所有请求做出运行反应。对于具有不同功能（如 HTML 标记生成，Web API 等等）的 Web 应用程序，让一个 HTTP 模块以某种方式强制执行身份验证通常不是一个很灵活的方法。在这种情况下，另一个使用 HTTP 模块的缺点就显现出来了，即依赖主机—IIS。 OWIN 中间件这是另一个与主机相关的选项，适用于 OWIN 主机。ASP.NET Web API 2 完全支持 OWIN。使用 OWIN 中间件确保安全的可能最有说服力的理由是同一中间件可以在不同的框架中工作。这意味着您可以将多个框架（如 ASP.NET Web API、SignalR 等）用在您的应用程序中，却可以使用共同的安全中间件。然而，OWIN 中间件的最小粒度却可能是一个缺点，因为 OWIN 中间件在 OWIN 管道中运行并且通常在处理各个请求时被调用。此外，OWIN 中间件只能用于与 OWIN 兼容的主机，虽然这种依赖比起依赖特定的主机/服务器（如 IIS）相对要好些，但这是 HTTP 模块的实际情况。值得注意的一点是，正是由于 Microsoft.Owin.Host.SystemWeb 包，OWIN 中间件才可以在（集成了 IIS 的）ASP.NET 管道中运行。 消息处理程序由 ASP.NET Web API 提供的扩展选项，将使用消息处理程序确保安全的最大好处就是它作为 ASP.NET Web API 框架的概念可以不依赖底层的主机或服务器。此外，消息处理程序仅对 Web API 请求运行。使用消息处理程序的不足之处在于缺乏更精细的控制。可将消息处理程序配置为对所有请求或对特定路由以全局处理程序来运行。对于给定的路由，您可以有多个控制器。所有这些控制器和它们所包含的操作方法都必须共享相同的由为此路由配置的消息处理程序强制执行的身份验证。换句话说，由消息处理程序执行的身份验证的最低粒度是在路由级别。 操作筛选器由 ASP.NET Web API 提供的另一个扩展选项是操作筛选器。然而，从执行身份验证的角度来看，它不是一个可行的选择，仅仅是因为它在授权筛选器在 ASP.NET Web API 管道运行之后才开始运行。为了让身份验证和授权能正常工作，身份验证必须先于授权而运行。