asp.net|cookie| Safety | safety
Original by FANCYF (Fancyray)
I did this experiment because of http://community.csdn.net/Expert/topic/3927/3927012.xml?temp=.3752405.
At first I thought,. NET verification should be relatively safe, the generated cookies should also be related to this computer's unique parameters, to get another computer on the should be ineffective. So is a username corresponding to a cookie value? Is it possible to cheat form validation by falsifying cookie values? Do some experiments.
Web.config modified as follows:
<authentication mode= "Forms" >
<forms name= "Mylab" loginurl= "/login.aspx" >
<credentials passwordformat= "Clear" >
<user name= "Fancyray" password= "Fancyray"/>
</credentials>
</forms>
</authentication>
<authorization>
<deny users= "?"/>
</authorization>
Login.aspx only a username input box txtusername, a password input box txtpassword and a Submit button, click the event as follows:
if (FormsAuthentication.Authenticate (This.txtUsername.Text, This.txtPassword.Text))
{
FormsAuthentication.RedirectFromLoginPage (This.txtUsername.Text, true);
}
Else
{
Response.Write ("Login denied");
}
With the help of Iehttpheaders (http://www.blunck.info/), you can see that a cookie like this has been added after validation:
mylab= 3ff83247c29eb5d14d61f389d453eee0586b94e27609c321b017be7b88d1a94d249996428a7a18f5c2d69f3c4dd2b88c00172cafb0b4b4ed8784db62d 1d61bcc0c786b4ea7868fc6
It seems that this is the encryption of the cookie later. To change the computer below, set this value directly to a cookie to see if forms validation is required.
Add the following sentence to the Login.aspx page:
<script language=javascript>
Document.cookie= "mylab= 3ff83247c29eb5d14d61f389d453eee0586b94e27609c321b017be7b88d1a94d249996428a7a18f5c2d69f3c4dd2b88c00172cafb0b4b4ed8784db62d 1d61bcc0c786b4ea7868fc6 ";
</script>
This will automatically add this cookie as soon as you open the Login.aspx page.
Another computer: Enter the same webapplication under the other page (should automatically jump to the Login.aspx page) http://10.0.0.7/upload.aspx, when the successful jump to the http://10.0.0.7/ Login.aspx? Returnurl=%2fupload.aspx, Normal. The value of the cookie should already be in effect. Then we enter the URL of the page just now http://10.0.0.7/upload.aspx!
In my guess, I'll definitely jump to the Login.aspx page because that cookie was generated on another computer. Actually, no jump! Full display of the content of the upload.aspx! And we did not login on this computer, even we do not know the user names!
I went back to 10.0.0.7 this computer on the Upload.aspx page of the Page_Load () the first line added: Response.Write (User.Identity.Name); On another computer to refresh the display of the upload.aspx, the result also appeared fancyray, is my username.
This means that the encryption of cookies does not depend on the computer that is logged on. That is, once your cookie is received by someone else, it is possible for him to gain your privileges on this server.
So how does this value for cookies come from? Is it possible for a hacker to get this value without a poor lift?
Let's take a look at what exactly is stored in the cookie and how it is encrypted. Reflactor (http://www.aisto.com/roeder/dotnet) play!
public static void SetAuthCookie (string userName, bool createPersistentCookie, string strCookiePath)
{
Formsauthentication.initialize ();
HTTPCONTEXT.CURRENT.RESPONSE.COOKIES.ADD (Formsauthentication.getauthcookie (UserName, createPersistentCookie, strCookiePath));
}
public static HttpCookie Getauthcookie (string userName, bool createPersistentCookie, string strCookiePath)
{
Formsauthentication.initialize ();
if (userName = null)
{
UserName = "";
}
if ((strCookiePath = null) | | (Strcookiepath.length < 1))
{
strCookiePath = Formsauthentication.formscookiepath;
}
FormsAuthenticationTicket Ticket1 = new FormsAuthenticationTicket (1, UserName, DateTime.Now, createPersistentCookie? DateTime.Now.AddYears (): DateTime.Now.AddMinutes (Double) formsauthentication._timeout), createPersistentCookie , "", strCookiePath);
String Text1 = Formsauthentication.encrypt (TICKET1);
Formsauthentication.trace ("Ticket is" + Text1);
if ((Text1 = null) | | (Text1. Length < 1))
{
throw New HttpException (httpruntime.formatresourcestring ("Unable_to_encrypt_cookie_ticket"));
}
HttpCookie cookie1 = new HttpCookie (Formsauthentication.formscookiename, Text1);
Cookie1. Path = strCookiePath;
Cookie1. Secure = Formsauthentication._requiressl;
if (Ticket1. Ispersistent)
{
Cookie1. Expires = Ticket1. expiration;
}
return cookie1;
}
The value stored in the cookie is that the text1,text1 inside is a string Text1 = Formsauthentication.encrypt (TICKET1); generated, so the information in the Text1 is Ticket1. The FormsAuthenticationTicket constructor is:
public FormsAuthenticationTicket (int version, string name, DateTime issuedate, datetime expiration, bool ispersistent, St Ring UserData, String cookiepath)
It has a username, a time to generate TICKET1, and an expiration date.
I could not help but see the cold shiver. Ticket1 actually only use the user name a key information, even the password is useless! Is this not the ticket1 of any user can be easily manufactured? Just pass Formsauthentication.encrypt (TICKET1) and get the value of the cookie to disguise as any user? It's terrible. We can only hope to encrypt this function now. See how it's implemented:
public static string Encrypt (FormsAuthenticationTicket ticket)
{
if (ticket = null)
{
throw new ArgumentNullException ("Ticket");
}
Formsauthentication.initialize ();
byte[] Buffer1 = Formsauthentication.maketicketintobinaryblob (ticket);
if (Buffer1 = null)
{
return null;
}
if (formsauthentication._protection = = Formsprotectionenum.none)
{
Return machinekey.bytearraytohexstring (buffer1, 0);
}
if ((formsauthentication._protection = = Formsprotectionenum.all) | | (formsauthentication._protection = = formsprotectionenum.validation))
{
byte[] Buffer2 = machinekey.hashdata (buffer1, NULL, 0, Buffer1. Length);
if (buffer2 = null)
{
return null;
}
Formsauthentication.trace ("Encrypt:mac length is:" + buffer2.) Length);
byte[] Buffer3 = new Byte[buffer2. Length + buffer1. Length];
Buffer.blockcopy (buffer1, 0, Buffer3, 0, Buffer1. Length);
Buffer.blockcopy (buffer2, 0, Buffer3, Buffer1. Length, Buffer2. Length);
if (formsauthentication._protection = = formsprotectionenum.validation)
{
Return machinekey.bytearraytohexstring (buffer3, 0);
}
Buffer1 = Buffer3;
}
Buffer1 = Machinekey.encryptordecryptdata (true, buffer1, NULL, 0, Buffer1. Length);
Return machinekey.bytearraytohexstring (Buffer1, Buffer1. Length);
}
Seeing the word machinekey, I finally breathed a sigh of relief. It seems that the encryption and decryption process is related to the server's parameters. In other words, the server has its own key, and only this key can be used to decrypt the cookie. If you do not know this key, others will not be able to counterfeit cookies.
It seems that cookies are still safe, in the absence of intrusion on your computer. As with any other information, the only thing you need to be aware of is security in the network transport.
This value of cookies, like SessionID, is a security issue that can be triggered once guessed. But there is a difference with SessionID, because the SessionID is always short, and the value of the cookie may be forever valid. The length of the cookie value also gives us a little bit of heart.
There is one more issue that cannot be overlooked. Although the generation of the value of the cookie is related to the specific time, that is, the cookie generated by me logging on again is not the same, but a valid cookie value is permanently valid, unaffected by the change in password and time. In other words, the last cookie I generated was still available on another computer after I logged off, as long as the server's machinekey remained unchanged. It's really a security risk. We can only say: "Cookies are very long, to be poor to a valid cookie in the lifetime is impossible" to find some comfort. Passwords can further reduce the likelihood of poor lifting by frequent changes, but legitimate cookies cannot be changed. Passwords are unique, but legitimate cookie values are not unique. It's always a little reassuring.
Perhaps worry is superfluous, because the electronic signature, the certificate is based on "the poor to pay a great price" on the basis of, if the consideration of "happen to be poor to lift", the security will no longer exist. It is believed that the security level of forms generated cookies is sufficient in the general security domain.
Use it with ease! (Another piece of worthless article, when you haven't seen it.)
