在我们的系统中,我们使用 ASP.Net WebForms 页面。
我们的系统中有一个自助注册网页,用户可以在其中注册并开始使用我们的系统。
我们最近发现我们的一位客户将表单数据从他们的网站发布到该页面,该页面又提交了该页面上的表单。
我们想阻止这种情况发生。我们不介意他们是否将页面嵌入到 IFrame 中,因为它无论如何都无法正常工作。但我们需要阻止他们将表单数据从他们的系统/网站发布到该页面。
是否有我们可以设置的属性或阻止外部发布到该页面的东西?或者可能是其他选择,Ajax 似乎跳入脑海?
不确定要搜索什么,在线快速搜索但找不到任何内容。
想要阻止这种情况的原因:
当该页面出现问题时,尝试注册的用户不会从我们的系统收到任何错误消息,因此我们得到了大量的支持。我们当然可以添加功能来支持,但我们宁愿不这样做。还想防止对该页面的机器人攻击,因为如果用户不存在,每次提交都会创建一个用户。
请您参考如下方法:
从 Visual Studio 2012 开始,Microsoft 为新的 Web 表单应用程序项目添加了内置的 CSRF 保护。要利用此代码,请将新的 ASP .NET Web 窗体应用程序添加到您的解决方案并查看页面后面的 Site.Master 代码。该解决方案将对所有继承自 Site.Master 页面的内容页面应用 CSRF 保护。
要使该解决方案起作用,必须满足以下要求:
所有进行数据修改的网络表单都必须使用 Site.Master 页面。所有进行数据修改的请求都必须使用 ViewState。该网站必须没有所有跨站点脚本 (XSS) 漏洞。有关详细信息,请参阅如何使用 Microsoft .Net Web 保护库修复跨站点脚本 (XSS)。另见 it
public partial class SiteMaster : MasterPage
{
private const string AntiXsrfTokenKey = "__AntiXsrfToken";
private const string AntiXsrfUserNameKey = "__AntiXsrfUserName";
private string _antiXsrfTokenValue;
protected void Page_Init(object sender, EventArgs e)
{
//First, check for the existence of the Anti-XSS cookie
var requestCookie = Request.Cookies[AntiXsrfTokenKey];
Guid requestCookieGuidValue;
//If the CSRF cookie is found, parse the token from the cookie.
//Then, set the global page variable and view state user
//key. The global variable will be used to validate that it matches in the view state form field in the Page.PreLoad
//method.
if (requestCookie != null
&& Guid.TryParse(requestCookie.Value, out requestCookieGuidValue))
{
//Set the global token variable so the cookie value can be
//validated against the value in the view state form field in
//the Page.PreLoad method.
_antiXsrfTokenValue = requestCookie.Value;
//Set the view state user key, which will be validated by the
//framework during each request
Page.ViewStateUserKey = _antiXsrfTokenValue;
}
//If the CSRF cookie is not found, then this is a new session.
else
{
//Generate a new Anti-XSRF token
_antiXsrfTokenValue = Guid.NewGuid().ToString("N");
//Set the view state user key, which will be validated by the
//framework during each request
Page.ViewStateUserKey = _antiXsrfTokenValue;
//Create the non-persistent CSRF cookie
var responseCookie = new HttpCookie(AntiXsrfTokenKey)
{
//Set the HttpOnly property to prevent the cookie from
//being accessed by client side script
HttpOnly = true,
//Add the Anti-XSRF token to the cookie value
Value = _antiXsrfTokenValue
};
//If we are using SSL, the cookie should be set to secure to
//prevent it from being sent over HTTP connections
if (FormsAuthentication.RequireSSL &&
Request.IsSecureConnection)
responseCookie.Secure = true;
//Add the CSRF cookie to the response
Response.Cookies.Set(responseCookie);
}
Page.PreLoad += master_Page_PreLoad;
}
protected void master_Page_PreLoad(object sender, EventArgs e)
{
//During the initial page load, add the Anti-XSRF token and user
//name to the ViewState
if (!IsPostBack)
{
//Set Anti-XSRF token
ViewState[AntiXsrfTokenKey] = Page.ViewStateUserKey;
//If a user name is assigned, set the user name
ViewState[AntiXsrfUserNameKey] =
Context.User.Identity.Name ?? String.Empty;
}
//During all subsequent post backs to the page, the token value from
//the cookie should be validated against the token in the view state
//form field. Additionally user name should be compared to the
//authenticated users name
else
{
//Validate the Anti-XSRF token
if ((string)ViewState[AntiXsrfTokenKey] != _antiXsrfTokenValue
|| (string)ViewState[AntiXsrfUserNameKey] !=
(Context.User.Identity.Name ?? String.Empty))
{
throw new InvalidOperationException("Validation of
Anti-XSRF token failed.");
}
}
}
}
