Asp. The security of forms authentication in net virtual hosts

Asp.net| Security | security | Virtual Host
Original by FANCYF (Fancyray) http://blog.csdn.net/fancyf/
After writing the security of the cookies generated by the ASP.net forms authentication, I felt that I could breathe a sigh of relief for the security of forms, and the result of the original question was that the owner raised the question: how did machinekey achieve it? Is the same machinekey used by different Web application on the same virtual host? Last time I did not think of this as a question, and then do a test.
Test idea: Create a new webapplication on the same computer, the domain name of the binding is different, also not in the same application pool. Create a cookie in the new WebApplication, take the value to the original WebApplication and see if you can pass the validation.
Test process: In order to bind different domain names, the DNS service is started on this computer and the DNS server in the network connection is directed to the IP of this computer. Based on the prototype of the FormsAuthenticationTicket constructor:
public FormsAuthenticationTicket (int version, string name, DateTime issuedate, datetime expiration, bool ispersistent, St Ring UserData, String cookiepath)
As well as in Getauthcookie (...) The calling method in:
FormsAuthenticationTicket Ticket1 = new FormsAuthenticationTicket (1, UserName, DateTime.Now, createPersistentCookie? DateTime.Now.AddYears (): DateTime.Now.AddMinutes (Double) formsauthentication._timeout), createPersistentCookie , "", strCookiePath);
Decide to put two text boxes on the test page, one for the username txtUsername2, one for the time txtgendate (instead of DateTime.Now), and then in the Generation button's Click event:
DateTime gendate = DateTime.Parse (This.txtGenDate.Text);
FormsAuthenticationTicket Ticket1 = new FormsAuthenticationTicket (1, This.txtUsername2.Text, Gendate, Gendate.addyears (M), True, "", "/");
This.lblEncryptedCookie.Text = Formsauthentication.encrypt (TICKET1);
The runtime found that the results of Formsauthentication.encrypt (TICKET1) for the same username and generation time are different each time, but each result is valid.
Now take this page to the newly established webapplication and put the resulting set of results on the Login.aspx page of the original webapplication:
<script language=javascript>
Document.cookie= "mylab= 5623de03be6ee52298f721b181c83f77a97688bb5268602de80c1a3db07b7a1ffb828080bd0785b18bb8072996c2e241fd9a54f0addd8500c2c510db5 4C31A40C8614541A9CF9C1A ";
</script>
In the original WebApplication program to start a non-login page (upload.aspx), the result is normal jump to the Login.aspx page. The above JS program should have been executed at this point, which means that the cookie generated in another program is already in effect. Enter the URL of upload.aspx directly again, the result passed the verification! At this point, it is clear from the iehttpheaders that the request in the browser sends the value "mylab= 5623de03be6ee52298f721b181c83f77a97688bb5268602de80c1a3db07b7a1ffb828080bd0785b18bb8072996c2e241fd9a54f0addd8500c2c510db5 4c31a40c8614541a9cf9c1a ".

This shows that machinekey is really only related to the machine, and WebApplication Independent. A application-generated cookie can also be validated by other application forms! The things that are worth worrying about finally come up. A and B two webapplication are in two different virtual hosts on the same computer, and forms validation is used in a. b Just execute:
DateTime gendate = DateTime.Parse (This.txtGenDate.Text);
FormsAuthenticationTicket Ticket1 = new FormsAuthenticationTicket (1, This.txtUsername2.Text, Gendate, Gendate.addyears (M), True, "", "/");
This.lblEncryptedCookie.Text = Formsauthentication.encrypt (TICKET1);
Such a piece of code can generate a legitimate user name in a cookie,b to a request through the fake cookie to a, you can pass a verification, so that any one user's permissions! It's all too simple, and it doesn't require any advanced technology, as long as a and B are!!! on the same computer. And, based on the security of cookies generated by the ASP.net Forms authentication, it is not possible to prevent B's behavior either by modifying the user's password in B or by logging the user on a, unless the user name is disabled. And don't let B get any valid username to avoid being copied again.
I was afraid to use forms only to authenticate on the virtual host. If you have other users on your asp.net mainframe, tighten the security measures as soon as possible. Forms validation is not for users of the virtual host at all, nor does it consider the security of the virtual host at all.


Disclaimer: This article only from the technical point of view to discuss the security of the system, anyone to the use of this article is limited to strengthen their own web site security, not to use the content of this article to engage in illegal activities. And the author does not assume any person to use this article to the third party's loss.