ViewStateUserKey is not a completely effective mitigation against Cross-Site Request Forgery. It doesn't work for non post-backs (I.e. GET requests), and it doesn't work if the ViewState MAC is turned off.
In several <http://msdn.microsoft.com/en-us/library/ms972969.aspx> different <http://www.guidanceshare.com/wiki/ASP.NET_2.0_Security_Guidelines_-_Paramet er_Manipulation> places <http://channel9.msdn.com/wiki/default.aspx/Channel9.ASPNETSecurityGuideline s> , we see a piece of advice repeated - use the ViewStateUserKey property to prevent One-Click Attacks. Often, this piece of advice is accompanied by the following code: void Page_Init(object sender, EventArgs e) { ViewStateUserKey = Session.SessionID; } What exactly does this code do? To understand it, we first need to look at the ViewState mechanism itself. The ViewState is an ASP.NET mechanism used to persist the value of web controls between post-backs. This allows a lot of the drag and drop, UI-driven ASP.NET architecture to function "auto-magically" by serializing and de-serializing data automatically on the fly. The ViewState is encoded and stored as a hidden field. This introduces security issues, because the value is under the control of the client. There may be a value stored in a field that you do not want someone to see and modify, like an admin-only control with the visible property set to false. ASP.NET helps us out by introducing two mechanisms to help protect the ViewState. ViewState MAC prevents tampering with the ViewState by introducing a separate Message Authentication Code that is verified when the ViewState is submitted. ViewState Encryption protects the ViewState confidentially by encrypting the ViewState value. By default, the ViewState MAC is enabled, and ViewState Encryption is not. The ViewStateUserKey property is an optional addition to the data used in ViewState MAC calculation. If that value changes between post-backs, the ViewState MAC calculation will fail and the page will cause an error. When we set the value of ViewStateUserKey to something associated with a particular user (like a Session ID or a Username), we are making sure that the ViewState is valid only for that user. Back to One-Click Attacks. One-Click Attack is sometimes incorrectly referred to as Microsoft's name for Cross-Site Request Forgery. However, this is not entirely correct. One-Click Attacks refer to CSRF attacks that use a malicious ViewState to perform the request. Because web forms developed with ASP.NET use ViewState for post-backs, the attacker can perform the post-back they want the user to perform unknowingly, and record the ViewState. Due to the way that ASP.NET ignores HTTP verbs when using Request.Params versus Request.Form, and in web controls, this request can often be made via GET. Example: http://site/Default.aspx?__VIEWSTATE=%2FwEPDwULLTExOTcyMDExODNkZAShpi32DKvqC d4uvHuQ%2FmmnBcdY&TextBox1=<MALICIOUS_CONTROL_DATA_GOES_HERE>&Button1=Button &__EVENTVALIDATION=%2FwEWAwKEyYGZBwLs0bLrBgKM54rG3sCHijug9ibUUfHX808cCvcppg1 i This link can be used in a CSRF attack. It is then known as a one-click attack, because it uses the ViewState. This, however, is not: http://site/DeleteUser.aspx?user_id=123456789 If the page is not a post-back (as in the case of a direct link), the ViewState MAC is never checked. Several ASP.NET applications allow you to modify data without submitting a form. Consider ASP.NET MVC <http://www.asp. net/mvc/> - it doesn't even use post-backs. Furthermore, the ViewState MAC can be disabled at the page level: <%@ Page Language="C#" EnableViewStateMac="false"%> or in web.config.: <pages enableViewStateMac="false"> </pages> ViewState MAC is often disabled for (perceived) performance reason, or (more likely) if there is some functionality in the application that causes the ViewState MAC to cause error. This reminds of problems <http://keepitlocked.net/archive/2007/10/30/asp-net-validaterequest-and-the- html-attribute-based-cross-site-scripting.aspx> with Request Validation is ASP.NET - the mechanism works, sometimes. This can be dangerous, because people rely on it and can get burned. The solution is to write something similar to <http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project> CSRFGuard from OWASP <http://www.owasp.org/index.php/Main_Page> in .NET. I have a feeling that the newly resurgent OWASP .NET <http://www.owasp.org/index.php/Category:OWASP_.NET_Project> project will add this to their to-do list. [Ph4nt0m] <http://www.ph4nt0m.org/> [Ph4nt0m Security Team] <http://blog.ph4nt0m.org/> [EMAIL PROTECTED] Email: [EMAIL PROTECTED] PingMe: <http://cn.pingme.messenger.yahoo.com/webchat/ajax_webchat.php?yid=hanqin_wu hq&sig=9ae1bbb1ae99009d8859e88e899ab2d1c2a17724> === V3ry G00d, V3ry Str0ng === === Ultim4te H4cking === === XPLOITZ ! === === #_# === #If you brave,there is nothing you cannot achieve.# --~--~---------~--~----~------------~-------~--~----~ 要向邮件组发送邮件，请发到 [email protected] 要退订此邮件，请发邮件至 [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
<<inline: image001.gif>>
