网站建设的基本步骤有哪些,网站备案 的类型,西安 网站 制作,中国建筑集团什么是反伪造攻击?
跨站点请求伪造#xff08;也称为XSRF或CSRF#xff0c;发音为see-surf#xff09;是对Web托管应用程序的攻击#xff0c;因为恶意网站可能会影响客户端浏览器和浏览器信任网站之间的交互。这种攻击是完全有可能的#xff0c;因为Web浏览器会自动在每…什么是反伪造攻击?
跨站点请求伪造也称为XSRF或CSRF发音为see-surf是对Web托管应用程序的攻击因为恶意网站可能会影响客户端浏览器和浏览器信任网站之间的交互。这种攻击是完全有可能的因为Web浏览器会自动在每一个请求中发送某些身份验证令牌到请求网站。这种攻击形式也被称为 一键式攻击 或 会话控制 因为攻击利用了用户以前认证的会话。
CSRF攻击的示例
用户登录 www.example.com使用表单身份验证。服务器对用户进行身份验证并作出包含身份验证Cookie的响应。用户访问恶意网站。恶意网站包含类似于以下内容的HTML表单 h1You Are a Winner!/h1form actionhttp://example.com/api/account methodpostinput typehidden nameTransaction valuewithdraw /input typehidden nameAmount value1000000 /input typesubmit valueClick Me//form请注意表单的Action属性将请求发送到易受攻击的网站而不是恶意网站。这是CSRF的“跨站点”部分。用户点击提交按钮浏览器会自动包含请求站点在这种情况下为易受攻击的站点的认证Cookie。请求在拥有用户身份验证上下文的服务端运行并且可以执行允许经过身份验证用户执行的任何操作。
此示例需要用户单击表单按钮恶意页面也可以通过以下方式
自动运行提交表单的脚本。通过AJAX请求发送表单提交。通过CSS隐藏的表单。
使用SSL不能阻止CSRF攻击恶意网站可以发送https://请求。
针对GET请求站点的攻击可以使用Image元素来执行这种形式的攻击在允许图片的论坛网站上很常见。使用GET请求更改应用程序状态更容易受到恶意攻击。
因为浏览器将所有相关的Cookie发送到目标网站所以可以针对使用Cookie进行身份验证的网站进行CSRF攻击。然而CSRF攻击并不仅限于利用Cookie例如Basic和Digest身份验证也很脆弱。用户使用Basic或Digest身份验证登录后浏览器将自动发送凭据直到会话Session结束。
注意在这本文中Session是指用户进行身份验证的客户端会话。它与服务器端会话或Session中间件无关。
用户可以通过以下方式防范CSRF漏洞
网站使用完毕后注销会话。定期清理浏览器的Cookie。
然而CSRF漏洞根本上是Web应用程序的问题而不是依靠用户来解决。
ASP.NET Core MVC是如何处理CSRF的 警告ASP.NET Core使用 ASP.NET Core data protection stack 来实现防请求伪造。如果在服务器集群中必配置 ASP.NET Core Data Protection有关详细信息请参阅 Configuring data protection。 在ASP.NET Core MVC 2.0中FormTagHelper为HTML表单元素注入防伪造令牌。例如Razor文件中的以下标记将自动生成防伪令牌 form methodpost!-- form markup --/form
在以下情况为HTML格式元素自动生成防伪令牌
该form标签包含methodpost属性action属性为空( action) 或者未提供action属性(form methodpost)。 您可以通过以下方式禁用自动生成HTML表单元素的防伪令牌
明确禁止asp-antiforgery例如 form methodpost asp-antiforgeryfalse/form通过使用标签帮助器! 禁用语法从标签帮助器转化为表单元素。 !form methodpost/!form在视图中移除FormTagHelper您可以在Razor视图中添加以下指令移除FormTagHelperhtml removeTagHelper Microsoft.AspNetCore.Mvc.TagHelpers.FormTagHelper, Microsoft.AspNetCore.Mvc.TagHelpers 提示Razor页面会自动受到XSRF/CSRF的保护。您不必编写任何其他代码有关详细信息请参阅XSRF/CSRF和Razor页面。 防御CSRF攻击的最常见方法是令牌同步模式STP。STP是当用户请求表单数据页面时使用的技术。服务器将与当前用户的标识相关联的令牌发送给客户端。客户端将令牌发回服务器进行验证。如果服务器接收到与验证用户身份不匹配的令牌则该请求将被拒绝。令牌是唯一的并且是不可预测的。令牌也可用于确保一系列请求的正确顺序确保页面1在第2页之前页面2在第3页之前。ASP.NET Core MVC模板中的所有表单都会生成防伪令牌以下两个示例演示在视图逻辑中生成防伪令牌 form asp-controllerManage asp-actionChangePassword methodpost/formusing (Html.BeginForm(ChangePassword, Manage)){}
您可以在不使用HTML标签助手的情况下向form元素显式添加防伪令牌Html.AntiForgeryToken form action/ methodpostHtml.AntiForgeryToken() /form
在前面的例子中ASP.NET Core将添加一个隐藏的表单字段类似于以下内容 input name__RequestVerificationToken typehidden valueCfDJ8NrAkSldwD9CpLRyOtm6FiJB1Jr_F3FQJQDvhlHoLNJJrLA6zaMUmhjMsisu2D2tFkAiYgyWQawJk9vNm36sYP1esHOtamBEPvSk1_x--Sg8Ey2a-d9CV2zHVWIN9MVhvKHOSyKqdZFlYDVd69XYx-rOWPw3ilHGLN6K0Km-1p83jZzF0E4WU5OGg5ns2-m9Yw /
ASP.NET Core 包括三个过滤器用于防伪令牌的运行ValidateAntiForgeryToken、AutoValidateAntiforgeryToken和 IgnoreAntiforgeryToken。
ValidateAntiForgeryToken
ValidateAntiForgeryToken是一个可应用于单个Action、控制器或全局的操作过滤器。请求必须包含一个有效的令牌否则对具有该过滤器Action的请求将被阻止。 [HttpPost][ValidateAntiForgeryToken] public async TaskIActionResult RemoveLogin(RemoveLoginViewModel account) {ManageMessageId? message ManageMessageId.Error; var user await GetCurrentUserAsync(); if (user ! null){ var result await _userManager.RemoveLoginAsync(user, account.LoginProvider, account.ProviderKey); if (result.Succeeded){ await _signInManager.SignInAsync(user, isPersistent: false);message ManageMessageId.RemoveLoginSuccess;}} return RedirectToAction(nameof(ManageLogins), new { Message message });}
ValidateAntiForgeryToken特性标记的Action方法需要一个令牌包括HTTP GET请求。如果您全局使用您可以使用IgnoreAntiforgeryToken特性来覆盖它。
AutoValidateAntiforgeryToken
ASP.NET Core应用程序通常不会为HTTP安全方式GETHEADOPTIONS和TRACE生成防伪令牌而不是在全局范围内使用ValidateAntiForgeryToken特性然后用IgnoreAntiforgeryToken特性覆盖它您可以使用AutoValidateAntiforgeryToken特性。该特性与ValidateAntiForgeryToken特性相似但对以下HTTP请求方式不需要请求令牌
GETHEADOPTIONSTRACE
我们建议您在非API场景中广泛使用AutoValidateAntiforgeryToken。这确保您的POST Action 默认受保护。另一种方式是在默认情况下忽略反伪造令牌除非在个别Action方法标记了ValidateAntiForgeryToken特性不过在这种情况下POST Action方法有可能不受保护使您的应用程序容易受到CSRF攻击。即使匿名的POST请求也应该发送防伪令牌。
注意API没有自动机制来发送非Cookie的令牌您的实现可能取决于您的客户端代码的实现。
一些例子如下所示。
示例控制器级别 [Authorize][AutoValidateAntiforgeryToken] public class ManageController : Controller {
示例全局 services.AddMvc(options options.Filters.Add(new AutoValidateAntiforgeryTokenAttribute()));
IgnoreAntiforgeryToken
IgnoreAntiforgeryToken过滤器用于取消已经使用防伪标记的Action或控制器的需求。应用时此过滤器将覆盖在更高级别全局或控制器上指定的过滤器ValidateAntiForgeryToken和/或AutoValidateAntiforgeryToken过滤器。 [Authorize][AutoValidateAntiforgeryToken] public class ManageController : Controller{[HttpPost][IgnoreAntiforgeryToken] public async TaskIActionResult DoSomethingSafe(SomeViewModel model) { // no antiforgery token required }}
JavaScriptAJAX和SPA(单页应用程序)
在传统基于HTML的应用程序中使用隐藏的表单字段将防伪令牌发送到服务器。在当前基于JavaScript的应用程序和单页应用程序SPA中许多请求以编程方式进行。这些AJAX请求可能会使用其它技术如请求头或Cookie来发送令牌。如果使用Cookie来存储身份验证令牌并在服务器上验证API请求那么CSRF将是一个潜在的问题但是如果使用本地存储来存储令牌那么CSRF漏洞可能会被减轻因为本地存储的值不会在每个请求时自动发送到服务器。因此使用本地存储将反伪造令牌存储在客户机上并将令牌作为请求头发送这是一种推荐的方式。
AngularJS
AngularJS通过约定来解决CSRF。如果服务器发送带有名称为XSRF-TOKEN的Cookie 则Angular的$http服务将向该服务器发送的请求将该Cookie的值添加到请求头。这个过程是自动的您不需要明确设置请求头。请求头的名称是X-XSRF-TOKEN服务器会检测该请求头并验证其内容。
对于ASP.NET Core API使用此约定
配置您的应用程序在一个Cookie中提供一个称为XSRF-TOKEN的令牌配置防伪服务查找名为X-XSRF-TOKEN的请求头。 services.AddAntiforgery(options options.HeaderName X-XSRF-TOKEN);
查看示例。
JavaScript
在视图中使用JavaScript您可以在视图中使用服务创建令牌您将Microsoft.AspNetCore.Antiforgery.IAntiforgery服务注入视图并调用GetAndStoreTokens如下所示
{ViewData[Title] AJAX Demo;
}
inject Microsoft.AspNetCore.Antiforgery.IAntiforgery Xsrf
functions{public string GetAntiXsrfRequestToken(){return Xsrf.GetAndStoreTokens(Context).RequestToken;}
}h2ViewData[Title]./h2h3ViewData[Message]/h3div classrowinput typebutton idantiforgery valueAntiforgery /script srchttps://ajax.aspnetcdn.com/ajax/jquery/jquery-2.1.4.min.js/scriptscript $(#antiforgery).click(function () { $.ajax({ type: post, dataType: html, headers: { RequestVerificationToken: GetAntiXsrfRequestToken() }, url: Url.Action(Antiforgery, Home), success: function (result) { alert(result); }, error: function (err, scnd) { alert(err.statusText); } }); }); /script/div
这种方法无需在服务器设置Cookie或从客户端读取Cookie。
JavaScript还可以访问Cookie中提供的令牌然后使用Cookie的内容创建带有令牌值的请求头如下所示。 context.Response.Cookies.Append(CSRF-TOKEN, tokens.RequestToken, new Microsoft.AspNetCore.Http.CookieOptions { HttpOnly false });
然后假设您构建的脚本发送的请求将令牌发送为一个名为X-CSRF-TOKEN的请求头中请配置防伪服务以查找X-CSRF-TOKEN请求头 services.AddAntiforgery(options options.HeaderName X-CSRF-TOKEN);
以下示例使用jQuery来创建一个包含相应请求头AJAX请求
var csrfToken $.cookie(CSRF-TOKEN);$.ajax({url: /api/password/changepassword,contentType: application/json,data: JSON.stringify({ newPassword: ReallySecurePassword999$$$ }),type: POST,headers: {X-CSRF-TOKEN: csrfToken }});
配置防伪
IAntiforgery提供API来配置防伪系统。它可以在Startup类的Configure方法中使用。以下示例在应用程序的主页生成防伪令牌并将其作为Cookie发送到响应中使用上述默认命名约定 public void Configure(IApplicationBuilder app, IAntiforgery antiforgery) {app.Use(next context { string path context.Request.Path.Value; if ( string.Equals(path, /, StringComparison.OrdinalIgnoreCase) || string.Equals(path, /index.html, StringComparison.OrdinalIgnoreCase)){ // We can send the request token as a JavaScript-readable cookie, // and Angular will use it by default.var tokens antiforgery.GetAndStoreTokens(context);context.Response.Cookies.Append(XSRF-TOKEN, tokens.RequestToken, new CookieOptions() { HttpOnly false });} return next(context);});}
选项
您可以在ConfigureServices方法中定制防伪选项 services.AddAntiforgery(options {options.CookieDomain mydomain.com;options.CookieName X-CSRF-TOKEN-COOKIENAME;options.CookiePath Path;options.FormFieldName AntiforgeryFieldname;options.HeaderName X-CSRF-TOKEN-HEADERNAME;options.RequireSsl false;options.SuppressXFrameOptionsHeader false;});
选项描述CookieDomainCookie的域名。默认为null。CookieNameCookie的名称。如果未设置系统将生成一个以DefaultCookiePrefix.AspNetCore.Antiforgery开头的唯一名称。CookiePathCookie设置的路径。FormFieldName在视图中隐藏表单字段的名称。HeaderName防伪系统使用的请求头的名称。如果null系统将仅使用表单数据。RequireSsl指定防伪系统是否需要SSL。默认为false。如果为true非SSL请求会失败。SuppressXFrameOptionsHeader指定是否禁止X-Frame-Options响应头的生成。默认情况下响应头生成的值为“SAMEORIGIN”。默认为false。
有关详细信息请参阅 https://docs.microsoft.com/aspnet/core/api/microsoft.aspnetcore.builder.cookieauthenticationoptions。
扩展防伪
IAntiForgeryAdditionalDataProvider类型允许开发者扩展anti-XSRF系统的行为在每个令牌中的增加额外数据。每次创建令牌时会调用GetAdditionalData方法并且返回的值被嵌入生成的令牌内。实现者可以返回时间戳、随机数或任何其它值然后在验证令牌时调用ValidateAdditionalData来验证此数据。客户的用户名已经嵌入到生成的令牌中因此不需要包含此信息。如果令牌包含补充数据但没有配置IAntiForgeryAdditionalDataProvider则补充数据不被验证。
常用场景
CSRF攻击依赖于浏览器默认行为向站点发出请求同时会发送与站点相关联的Cookie。这些Cookies存储在浏览器中它们经常用于经过身份验证的用户提供会话Cookie。基于Cookie的身份验证是一种非常流行的身份验证模式。基于令牌的认证系统越来越受欢迎特别是对于SPA和其它“智能客户端”场景。
基于Cookie的身份验证
一旦用户使用他们的用户名和密码进行身份验证就会发出一个令牌用于标识它们并验证它们是否经过身份验证。令牌存储为Cookie客户端所做的每个请求都会附带令牌。生成和验证此Cookie是由Cookie身份验证中间件完成的。ASP.NET Core提供了将用户主体序列化为加密Cookie的Cookie 中间件然后在随后的请求中验证Cookie重新创建主体并将其分配给HttpContext的User属性。
当使用Cookie时身份验证Cookie只是表单身份验证凭证的一个容器。在每个请求中票据作为的表单认证Cookie的值传递并通过表单身份验证在服务端以标识经过身份验证的用户。
当用户登录到系统时会在服务器端创建用户会话并将其存储在数据库或其他持久存储中系统生成指向数据存储中的会话密钥并将其作为客户端Cookie发送。每当用户请求需要授权的资源时Web服务器将检查此会话密钥系统检查关联的用户会话是否具有访问请求的资源的权限。如果是请求继续否则请求返回为未授权。在这种方法下Cookie的使用使应用程序看起来是有状态的因为它能够“记住”用户以前已经在服务端完成了身份验证。
用户令牌
基于令牌的身份验证不会在服务器上存储会话。相反当用户登录时将颁发令牌不是防伪令牌。该令牌保存验证令牌所需的所有数据它还包含用户信息以claims的形式。当用户想要访问需要身份验证的服务器资源时会使用 Bearer {token} 形式的附加授权头发送令牌给服务器。这使得应用程序无状态因为在每个后续请求中令牌在请求中传递给服务器端验证。该令牌未 加密 而是 编码 。在服务器端令牌可以被解码以访问令牌内的原始信息。要在随后的请求中发送令牌您可以将其存储在浏览器的本地存储或Cookie中。如果您的令牌存储在本地存储中则不必担心XSRF漏洞但如果令牌存储在Cookie中则会出现问题。
多个应用程序托管在一个域中
即使example1.cloudapp.net和example2.cloudapp.net是不同的主机在.cloudapp.net域内的所有主机之间存在一种隐式信任关系。这种隐式信任关系允许潜在的不受信任的主机影响彼此的Cookie(管理AJAX请求的同源策略不一定适用于HTTP Cookie)。ASP.NET Core运行时提供了一些缓解用户名被嵌入到字段令牌中因此即使恶意子域能够覆盖会话令牌它将无法为用户生成有效的字段令牌。然而当托管在这样的环境中内置的反XSRF例程仍然无法防止会话劫持或登录CSRF攻击。共享主机环境对会话劫持、登录CSRF和其它攻击都是不可控制的。
其他资源
XSRF on Open Web Application Security Project (OWASP)。
原文《Preventing Cross-Site Request Forgery (XSRF/CSRF) Attacks in ASP.NET Core》https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery翻译Sweet Tang
相关文章
.NET Core 2.0 正式发布信息汇总.NET Standard 2.0 特性介绍和使用指南.NET Core 2.0 的dll实时更新、https、依赖包变更问题及解决.NET Core 2.0 特性介绍和使用指南Entity Framework Core 2.0 新特性体验 PHP under .NET Core.NET Core 2.0使用NLog升级项目到.NET Core 2.0在Linux上安装Docker并成功部署解决Visual Studio For Mac Restore失败的问题ASP.NET Core 2.0 特性介绍和使用指南Entity Framework Core 2.0 全局查询过滤器Entity Framework Core 2.0 特性介绍和使用指南ASP.NET Core Razor页面 vs MVCRazor Page–Asp.Net Core 2.0新功能 Razor Page介绍MySql 使用 EF Core 2.0 CodeFirst、DbFirst、数据库迁移Migration介绍及示例.NET Core 2.0迁移技巧之web.config配置文件
本文地址http://www.cnblogs.com/tdfblog/p/aspnet-core-security-anti-request-forgery.html .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
